Authentication Policy#

AAA → APAuthentication Policies

An AuthenticationPolicy defines parameters that apply to logged-in users and to the way authentication is performed on the node. It covers password complexity rules, lockout behavior after failed login attempts, idle timeout, and the order in which authentication methods are attempted (including remote AAA via ServerGroup resources and local authentication).

Multiple authentication methods#

Using external authentication servers enables robust integration with existing permission management systems. Two well-known external authentication protocols are TACACS+ and RADIUS: instead of configuring individual user accounts on each network element, these authentication methods allow centralized user and permission management, as well as logging what a user does for auditing purposes.

While this has obvious benefits, some network designs may require multiple authentication methods to be attempted. One of the most common use-cases for multiple authentication methods is the so-called "emergency access account".

Emergency access accounts

If the centralized authentication servers become unreachable or compromised, users can no longer log into the network elements. An emergency access account is a locally configured user account that is not used during regular operation, but is a last resort for gaining access to the network elements.

The authenticationOrder property of the AuthenticationPolicy determines which authentication methods are attempted, and in what order. For example:

First try RADIUS server A
Then try TACACS servers B and C
Finally, try local user authentication

The exitOnReject boolean controls whether to continue to the next method after a rejection. When exitOnReject is True, a rejection from one authentication method stops the chain and no further methods are tried.

exitOnReject should be set to True when subsequent authentication methods must be used only if the servers in the current ServerGroup are unreachable. When it is False, methods are tried in order until one accepts the authentication request or the list is exhausted. The following diagram illustrates the behavior when a local user 'admin' tries to log in:

flowchart LR
    A[RADIUS servers] -->|exitOnReject=True| X
    A -->|exitOnReject=False| B
    B[TACACS servers] -->|exitOnReject=True| Y
    B -->|exitOnReject=False| C
    C[Local authentication]
    X[Deny access]
    Y[Deny access]

Referenced resources#

`ServerGroup`#

An AuthenticationPolicy refers to ServerGroup resources via authenticationOrder.serverGroupOrder. That field lists ServerGroup names in the order they are used for authentication.

Examples#

YAMLkubectl

apiVersion: aaa.eda.nokia.com/v1
kind: AuthenticationPolicy
metadata:
  name: my-auth-policy
  namespace: eda
spec:
  authenticationOrder:
    exitOnReject: false
    localAuthentication: First
    serverGroupOrder:
      - my-radius-servers
  nodes:
    - leaf-2
    - leaf-1

cat << 'EOF' | kubectl apply -f -
apiVersion: aaa.eda.nokia.com/v1
kind: AuthenticationPolicy
metadata:
  name: my-auth-policy
  namespace: eda
spec:
  authenticationOrder:
    exitOnReject: false
    localAuthentication: First
    serverGroupOrder:
      - my-radius-servers
  nodes:
    - leaf-2
    - leaf-1
EOF

Custom Resource Definition#

To browse the Custom Resource Definition go to crd.eda.dev.

SPEC

An AuthenticationPolicy defines parameters that relate to node users, such as password complexity, lockout timers, and the order in which authentication methods are attempted on the node.

#
Authentication order.
- #
- #
- #
#
#
Lockout policy.
- #
- #
- #
#
#
#
Password complexity rules.
- #
- #
- #
- #
- #
- #
- #
- #

STATUS

AuthenticationPolicyStatus defines the observed state of AuthenticationPolicy.

#