Broken Authentication in Kubernetes
Play Kubernetes Labs on this vulnerability with SecureFlag!
Kubernetes has many components and functionalities that need to be carefully configured in order to maintain the security of the cluster.
API Server
The API server is the pivotal point where the cluster’s security configuration is applied. All of the other components are able to interact directly with the cluster’s state store via its REST API.
For this reason, client access to the Kubernetes API should be authenticated, authorized, and encrypted.
Authentication strategies
Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins. The plugins attempt to associate the following attributes with the request:
- Username: a string which identifies the end user.
- UID: a unique string which identifies the end user.
- Groups: a set of strings which associate users with a set of commonly grouped users.
- Extra fields: a map of strings to list which strings hold additional information.
At a minimum, tokens for service accounts and user authentication methods should be enabled.
The system:authenticated group is included in the list of groups for all authenticated users.
Starting from version 1.6, anonymous access is enabled by default if an authorization mode other than AlwaysAllow is used, and anonymous requests are not rejected but are given a username of system:anonymous and a group of system:unauthenticated.
Kubelet
Kubelet is an agent running on every node that should be configured correctly to prevent unauthorized access from the Pods.
In prior versions of Kubernetes (prior to 1.7), Kubelet had read-write access to the Node and Pod APIs, allowing, if compromised, numerous resources to be taken control of. More recent versions introduced the Node Authorizer, which limits the kubelet to access only resources that are related specifically to the node on which the kubelet runs.
REST APIs are exposed on ports 10250 (read/write) and 10255 (read-only) ports.
Read-write port
Unrestricted access to the read-write port could result in a take over of the cluster, as it’s possible to run commands inside the Pod’s containers or start new resources. This can’t be fully disabled because it is needed for metric collection and other important functions, so the access should be carefully controlled.
Kubelet should be configured to enforce authentication of all clients. The methods that can be enabled are X.509 client certificates, or requests with Authorization headers containing authentication tokens.
In the case of X.509 client certificates, the contents of a CA bundle need to be made available to the kubelet (--client-ca-file, authentication.x509.clientCAFile).
By default, when receiving anonymous requests Kubelet passes them on for authorization, rather than rejecting them.
The authorization setting (authorization.mode, --authorization-mode) can operate in one of two modes; AlwaysAllow (default), or Webhook. The first option disables the authentication, while the Webhook value performs further checks to determine whether the subject is allowed to make the request.
To disable anonymous access and send 401 Unauthorized responses to unauthenticated requests, the anonymous settings (authentication.anonymous.enabled, --anonymous-auth) must be set to false.
Read only port
The read-only access could also be abused to disclose sensitive information regarding the cluster.
For this reason, the read-only port should be disabled by removing the option or by setting the option (readOnlyPort, --read-only-port ) to 0.
Etcd
Kubernetes uses etcd key-value store to store cluster state and configurations. For this reason, getting write access to the etcd backend for the APIs is equivalent to granting cluster-admin access, and read access can be used to escalate fairly quickly. It listens on TCP port 2379 for client and TCP port 2380 for server-to-server communications.
In versions prior to etcd 2.1., authentication did not exist; however, currently etcd supports strong credentials such as mutual authentication via client certificates. This should always be used by creating a new key pair for every entity in the cluster that needs to access etcd API.
References
CWE - CWE-287: Improper Authentication
OWASP - A07:2021 - Identification and Authentication Failures
OWASP - Authentication Cheat Sheet
Kubernetes - Accessing the API