Hardening Guide - Authentication Mechanisms [page]deterministic

Selecting the appropriate authentication mechanism(s) is a crucial aspect of securing your cluster. Kubernetes provides several built-in mechanisms, each with its own strengths and weaknesses that should be carefully considered when choosing the best authentication mechanism for your cluster.

In general, it is recommended to enable as few authentication mechanisms as possible to simplify user management and prevent cases where users retain access to a cluster that is no longer required.

It is important to note that Kubernetes does not have an in-built user database within the cluster. Instead, it takes user information from the configured authentication system and uses that to make authorization decisions. Therefore, to audit user access, you need to review credentials from every configured authentication source.

For production clusters with multiple users directly accessing the Kubernetes API, it is recommended to use external authentication sources such as OIDC. The internal authentication mechanisms, such as client certificates and service account tokens, described below, are not suitable for this use case.

## X.509 client certificate authentication {#x509-client-certificate-authentication}

Kubernetes leverages [X.509 client certificate](/docs/reference/access-authn-authz/authentication/#x509-client-certificates) authentication for system components, such as when the kubelet authenticates to the API Server. While this mechanism can also be used for user authentication, it might not be suitable for production use due to several restrictions:

• Client certificates cannot be individually revoked. Once compromised, a certificate can be used by an attacker until it expires. To mitigate this risk, it is recommended to configure short lifetimes for user authentication credentials created using client certificates.
• If a certificate needs to be invalidated, the certificate authority must be re-keyed, which can introduce availability risks to the cluster.
• There is no permanent record of client certificates created in the cluster. Therefore, all issued certificates must be recorded if you need to keep track of them.
• Private keys used for client certificate authentication cannot be password-protected. Anyone who can read the file containing the key will be able to make use of it.
• Using client certificate authentication requires a direct connection from the client to the API server without any intervening TLS termination points, which can complicate network architectures.
• Group data is embedded in the `O` value of the client certificate, which means the user's group memberships cannot be changed for the lifetime of the certificate.

## Static token file {#static-token-file}

Although Kubernetes allows you to load credentials from a [static token file](/docs/reference/access-authn-authz/authentication/#static-token-file) located on the control plane node disks, this approach is not recommended for production servers due to several reasons:

• Credentials are stored in clear text on control plane node disks, which can be a security risk.
• Changing any credential requires a restart of the API server process to take effect, which can impact availability.
• There is no mechanism available to allow users to rotate their credentials. To rotate a credential, a cluster administrator must modify the token on disk and distribute it to the users.
• There is no lockout mechanism available to prevent brute-force attacks.

## Bootstrap tokens {#bootstrap-tokens}

[Bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) are used for joining nodes to clusters and are not recommended for user authentication due to several reasons:

• They have hard-coded group memberships that are not suitable for general use, making them unsuitable for authentication purposes.
• Manually generating bootstrap tokens can lead to weak tokens that can be guessed by an attacker, which can be a security risk.
• There …(trimmed)