You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
11
+
Selecting the appropriate authentication mechanism(s) is a crucial aspect of securing your cluster.
12
+
Kubernetes provides several built-in mechanisms, each with its own strengths and weaknesses that
13
+
should be carefully considered when choosing the best authentication mechanism for your cluster.
12
14
13
-
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.
15
+
In general, it is recommended to enable as few authentication mechanisms as possible to simplify
16
+
user management and prevent cases where users retain access to a cluster that is no longer required.
14
17
15
-
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.
18
+
It is important to note that Kubernetes does not have an in-built user database within the cluster.
19
+
Instead, it takes user information from the configured authentication system and uses that to make
20
+
authorization decisions. Therefore, to audit user access, you need to review credentials from every
21
+
configured authentication source.
16
22
17
-
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.
23
+
For production clusters with multiple users directly accessing the Kubernetes API, it is
24
+
recommended to use external authentication sources such as OIDC. The internal authentication
25
+
mechanisms, such as client certificates and service account tokens, described below, are not
Kubernetes leverages [X509 client certificate](/docs/reference/access-authn-authz/authentication/#x509-client-certs) 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:
24
-
25
-
- 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.
26
-
- If a certificate needs to be invalidated, the certificate authority must be re-keyed, which can introduce availability risks to the cluster.
27
-
- 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.
28
-
- 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.
29
-
- 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.
30
-
- 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.
31
-
32
-
## Static Token File {#static-token-file}
33
-
34
-
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:
authentication for system components, such as when the Kubelet authenticates to the API Server.
34
+
While this mechanism can also be used for user authentication, it might not be suitable for
35
+
production use due to several restrictions:
36
+
37
+
- Client certificates cannot be individually revoked. Once compromised, a certificate can be used
38
+
by an attacker until it expires. To mitigate this risk, it is recommended to configure short
39
+
lifetimes for user authentication credentials created using client certificates.
40
+
- If a certificate needs to be invalidated, the certificate authority must be re-keyed, which
41
+
can introduce availability risks to the cluster.
42
+
- There is no permanent record of client certificates created in the cluster. Therefore, all
43
+
issued certificates must be recorded if you need to keep track of them.
44
+
- Private keys used for client certificate authentication cannot be password-protected. Anyone
45
+
who can read the file containing the key will be able to make use of it.
46
+
- Using client certificate authentication requires a direct connection from the client to the
47
+
API server with no intervening TLS termination points, which can complicate network architectures.
48
+
- Group data is embedded in the `O` value of the client certificate, which means the user's group
49
+
memberships cannot be changed for the lifetime of the certificate.
50
+
51
+
## Static token file {#static-token-file}
52
+
53
+
Although Kubernetes allows you to load credentials from a
54
+
[static token file](/docs/reference/access-authn-authz/authentication/#static-token-file) located
55
+
on the control plane node disks, this approach is not recommended for production servers due to
56
+
several reasons:
35
57
36
58
- Credentials are stored in clear text on control plane node disks, which can be a security risk.
37
-
- Changing any credential requires a restart of the API server process to take effect, which can impact availability.
38
-
- 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.
59
+
- Changing any credential requires a restart of the API server process to take effect, which can
60
+
impact availability.
61
+
- There is no mechanism available to allow users to rotate their credentials. To rotate a
62
+
credential, a cluster administrator must modify the token on disk and distribute it to the users.
39
63
- There is no lockout mechanism available to prevent brute-force attacks.
40
64
41
-
## Bootstrap Tokens {#bootstrap-tokens}
65
+
## Bootstrap tokens {#bootstrap-tokens}
42
66
43
-
[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:
67
+
[Bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) are used for joining
68
+
nodes to clusters and are not recommended for user authentication due to several reasons:
44
69
45
-
- They have hard-coded group memberships that are not suitable for general use, making them unsuitable for authentication purposes.
46
-
- Manually generating bootstrap tokens can lead to weak tokens that can be guessed by an attacker, which can be a security risk.
47
-
- There is no lockout mechanism available to prevent brute-force attacks, making it easier for attackers to guess or crack the token.
70
+
- They have hard-coded group memberships that are not suitable for general use, making them
71
+
unsuitable for authentication purposes.
72
+
- Manually generating bootstrap tokens can lead to weak tokens that can be guessed by an attacker,
73
+
which can be a security risk.
74
+
- There is no lockout mechanism available to prevent brute-force attacks, making it easier for
75
+
attackers to guess or crack the token.
48
76
49
-
## Service Account Secret Tokens {#service-account-secret-tokens}
77
+
## Service account secret tokens {#service-account-secret-tokens}
50
78
51
-
[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:
are available as an option to allow workloads running in the cluster to authenticate to the
81
+
API server. In Kubernetes < 1.23, these were the default option, however, they are being replaced
82
+
with TokenRequest API tokens. While these secrets could be used for user authentication, they are
83
+
generally unsuitable for a number of reasons:
52
84
53
85
- They cannot be set with an expiry and will remain valid until the associated service account is deleted.
54
-
- The authentication tokens are visible to any cluster user who can read secrets in the namespace that they are defined in.
86
+
- The authentication tokens are visible to any cluster user who can read secrets in the namespace
87
+
that they are defined in.
55
88
- Service accounts cannot be added to arbitrary groups complicating RBAC management where they are used.
56
89
57
-
## TokenRequest API Tokens {#tokenrequest-api-tokens}
90
+
## TokenRequest API tokens {#tokenrequest-api-tokens}
58
91
59
-
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.
92
+
The TokenRequest API is a useful tool for generating short-lived credentials for service
93
+
authentication to the API server or third-party systems. However, it is not generally recommended
94
+
for user authentication as there is no revocation method available, and distributing credentials
95
+
to users in a secure manner can be challenging.
60
96
61
-
When using TokenRequest tokens for service authentication, it is recommended to implement a short lifespan to reduce the impact of compromised tokens.
97
+
When using TokenRequest tokens for service authentication, it is recommended to implement a short
98
+
lifespan to reduce the impact of compromised tokens.
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 following hardening measures:
102
+
Kubernetes supports integrating external authentication services with the Kubernetes API using
[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.
74
-
75
-
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.
76
-
77
-
## Authenticating Proxy {#authenticating-proxy}
78
-
79
-
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.
80
-
81
-
Firstly, 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.
82
-
83
-
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.
111
+
- As with TokenRequest tokens, OIDC tokens should have a short lifespan to reduce the impact of
0 commit comments