diff --git a/content/en/docs/concepts/security/hardening-guide/authentication-mechanisms.md b/content/en/docs/concepts/security/hardening-guide/authentication-mechanisms.md index 1ac867fc28..acd4726d1a 100644 --- a/content/en/docs/concepts/security/hardening-guide/authentication-mechanisms.md +++ b/content/en/docs/concepts/security/hardening-guide/authentication-mechanisms.md @@ -9,135 +9,142 @@ weight: 90 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 +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 +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 +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. +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 +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 +- 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 with no 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. +- 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 +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. +- 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 +[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 is no lockout mechanism available to prevent brute-force attacks, making it easier for -attackers to guess or crack the token. +- 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 is no lockout mechanism available to prevent brute-force attacks, making it easier for + attackers to guess or crack the token. ## ServiceAccount secret tokens {#serviceaccount-secret-tokens} -[Service account secrets](/docs/reference/access-authn-authz/service-accounts-admin/#manual-secret-management-for-serviceaccounts) -are available as an option to allow workloads running in the cluster to authenticate to the -API server. In Kubernetes < 1.23, these were the default option, however, they are being replaced -with TokenRequest API tokens. While these secrets could be used for user authentication, they are +[Service account secrets](/docs/reference/access-authn-authz/service-accounts-admin/#manual-secret-management-for-serviceaccounts) +are available as an option to allow workloads running in the cluster to authenticate to the +API server. In Kubernetes < 1.23, these were the default option, however, they are being replaced +with TokenRequest API tokens. While these secrets could be used for user authentication, they are generally unsuitable for a number of reasons: - They cannot be set with an expiry and will remain valid until the associated service account is deleted. -- The authentication tokens are visible to any cluster user who can read secrets in the namespace -that they are defined in. +- The authentication tokens are visible to any cluster user who can read secrets in the namespace + that they are defined in. - Service accounts cannot be added to arbitrary groups complicating RBAC management where they are used. ## TokenRequest API tokens {#tokenrequest-api-tokens} -The TokenRequest API is a useful tool for generating short-lived credentials for service -authentication to the API server or third-party systems. However, it is not generally recommended -for user authentication as there is no revocation method available, and distributing credentials +The TokenRequest API is a useful tool for generating short-lived credentials for service +authentication to the API server or third-party systems. However, it is not generally recommended +for user authentication as there is no revocation method available, and distributing credentials to users in a secure manner can be challenging. -When using TokenRequest tokens for service authentication, it is recommended to implement a short +When using TokenRequest tokens for service authentication, it is recommended to implement a short lifespan to reduce the impact of compromised tokens. ## OpenID Connect token authentication {#openid-connect-token-authentication} -Kubernetes supports integrating external authentication services with the Kubernetes API using -[OpenID Connect (OIDC)](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens). -There is a wide variety of software that can be used to integrate Kubernetes with an identity -provider. However, when using OIDC authentication for Kubernetes, it is important to consider the +Kubernetes supports integrating external authentication services with the Kubernetes API using +[OpenID Connect (OIDC)](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens). +There is a wide variety of software that can be used to integrate Kubernetes with an identity +provider. However, when using OIDC authentication in Kubernetes, it is important to consider the following hardening measures: -- The software installed in the cluster to support OIDC authentication should be isolated from -general workloads as it will run with high privileges. +- The software installed in the cluster to support OIDC authentication should be isolated from + general workloads as it will run with high privileges. - Some Kubernetes managed services are limited in the OIDC providers that can be used. -- As with TokenRequest tokens, OIDC tokens should have a short lifespan to reduce the impact of -compromised tokens. +- As with TokenRequest tokens, OIDC tokens should have a short lifespan to reduce the impact of + compromised tokens. ## Webhook token authentication {#webhook-token-authentication} -[Webhook token authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) -is another option for integrating external authentication providers into Kubernetes. This mechanism -allows for an authentication service, either running inside the cluster or externally, to be -contacted for an authentication decision over a webhook. It is important to note that the suitability -of this mechanism will likely depend on the software used for the authentication service, and there +[Webhook token authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +is another option for integrating external authentication providers into Kubernetes. This mechanism +allows for an authentication service, either running inside the cluster or externally, to be +contacted for an authentication decision over a webhook. It is important to note that the suitability +of this mechanism will likely depend on the software used for the authentication service, and there are some Kubernetes-specific considerations to take into account. -To configure Webhook authentication, access to control plane server filesystems is required. This -means that it will not be possible with Managed Kubernetes unless the provider specifically makes it -available. Additionally, any software installed in the cluster to support this access should be +To configure Webhook authentication, access to control plane server filesystems is required. This +means that it will not be possible with Managed Kubernetes unless the provider specifically makes it +available. Additionally, any software installed in the cluster to support this access should be isolated from general workloads, as it will run with high privileges. ## Authenticating proxy {#authenticating-proxy} -Another option for integrating external authentication systems into Kubernetes is to use an -[authenticating proxy](/docs/reference/access-authn-authz/authentication/#authenticating-proxy). -With this mechanism, Kubernetes expects to receive requests from the proxy with specific header -values set, indicating the username and group memberships to assign for authorization purposes. -It is important to note that there are specific considerations to take into account when using +Another option for integrating external authentication systems into Kubernetes is to use an +[authenticating proxy](/docs/reference/access-authn-authz/authentication/#authenticating-proxy). +With this mechanism, Kubernetes expects to receive requests from the proxy with specific header +values set, indicating the username and group memberships to assign for authorization purposes. +It is important to note that there are specific considerations to take into account when using this mechanism. -Firstly, securely configured TLS must be used between the proxy and Kubernetes API server to -mitigate the risk of traffic interception or sniffing attacks. This ensures that the communication +Firstly, securely configured TLS must be used between the proxy and Kubernetes API server to +mitigate the risk of traffic interception or sniffing attacks. This ensures that the communication between the proxy and Kubernetes API server is secure. -Secondly, it is important to be aware that an attacker who is able to modify the headers of the -request may be able to gain unauthorized access to Kubernetes resources. As such, it is important -to ensure that the headers are properly secured and cannot be tampered with. \ No newline at end of file +Secondly, it is important to be aware that an attacker who is able to modify the headers of the +request may be able to gain unauthorized access to Kubernetes resources. As such, it is important +to ensure that the headers are properly secured and cannot be tampered with. + +## {{% heading "whatsnext" %}} + +- [User Authentication](/docs/reference/access-authn-authz/authentication/) +- [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [kubelet Authentication](/docs/reference/access-authn-authz/kubelet-authn-authz/#kubelet-authentication) +- [Authenticating with Service Account Tokens](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens)