Kubernetes Security Concepts
- 1 Internal
- 2 Overview
- 3 API Server Authentication - Identity while Accessing the Cluster
- 3.1 Identities
- 3.1.1 User
- 3.1.2 Group
- 3.1.3 Service Account
- 3.1.4 Anonymous Request
- 3.2 API Authentication Strategies
- 3.1 Identities
- 4 Controlling Access to the Kubernetes API
- 5 Pod and Container Security
- 6 Transport Security
Kubernetes security covers several areas:
- The Kubernetes cluster must provide infrastructure and configuration capabilities that ensure the API sever is only accessible to authenticated identities. Once the identity of the caller is established through authentication, the Kubernetes cluster must ensure that access is limited only to resources that are supposed to be accessible to the authenticated identity and the access is denied for all other resources.
- Kubernetes clusters runs arbitrary applications in pods, and they must provide mechanisms that prevent a possibly malicious application from accessing node and network resources it is not supposed to access. This subject is covered by Pod and Container Security section.
- Kubernetes expects that all API communication in the cluster is encrypted. This subject is covered in Transport Security section.
API Server Authentication - Identity while Accessing the Cluster
The identity while accessing the Kubernetes cluster is associated with a (usually human) user, authenticated as part of the request handling, that uses an external CLI tool such as
kubectl, or with a service account, which provides identity to pods and containers running inside the pods that make API requests as part of their logic. If an API request is not associated with any of these identities, it is treaded as an anonymous request. The available API request authentication strategies are described below.
Users are sometimes referred to as "users accounts" or "normal users". There is no "User" Kubernetes API resource, and users cannot be added through an API call. It is assumed that a cluster-independent service manages users. That service can be implemented as a username/password file, a user store like Google Accounts, or an administrator that distributes private keys. When the authentication credentials are presented to the API server, the API server extracts the user name from the credentials (e.g. from the common name field in the "subject" of the certificate, "/CN=alice"). Explain how the Kubernetes authentication token is associated with such a request.
- Create a Normal User
- Add a Normal User via a Certificate
- Define a user in EKS:
Processes in containers inside pods can contact the API server, and they need an identity when doing so. A service account provides the identity for processes that run in a the pod. Processes will authenticate using the identity provided by the service account. By default, in absence of specific configuration, the pods will authenticate as the default service account in the namespace they are running in. A specific service account name can be specified in the pod manifest - also see Non-Default Service Accounts below.
Unlike users, the service accounts are resources managed by Kubernetes - there is a
ServiceAccount Kubernetes API resource. Service accounts can be created via API calls, or automatically by the server. The service accounts are bound to specific namespaces. A service account is tied to a set of credentials stored as Secrets, which are mounted into the pod allowing the in-cluster processes to talk to the Kubernetes API. For more details on associating service account with secrets, see Service Accounts and Credentials below. Service accounts can be bound to specific roles. For more details on associating service account with roles, see Service Accounts and Roles below.
⚠️ A service account token is a long-lived, static credential. If it is compromised, lost, or stolen, an attacker may be able to perform all the actions associated with that token until the service account is deleted, so use them sparingly.
Service accounts are rendered in logs using their full name (e.g. "system:serviceaccount:blue:default)
kubectl operations can be conducted under the identity of a specific service account using kubectl --as option:
kubectl --as=system:serviceaccount:<namespace>:<service-account-name> -n <namespace> ...
Service Accounts Credentials (service-account-token)
The credentials (the token) for a service account are projected into the filesystem of each container of the pod as a
kubernetes.io/service-account-token-type secret. The secret content is available to the container processes as
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt and by default is auto-mounted. In Kubernetes 1.6+ it can be opted out of auto-mounting by setting automountServiceAccountToken in the service account manifest.
Clarify the following:
- The default namespace to be used for namespaced API operations is placed on the filesystem of each container of the pod at
- What are the default credentials associated with the default service account.
- How can this be association displayed.
- What happens with a newly created service account - does it need to be explicitly associated with those credentials or the association is done automatically upon creation.
Service Account Full Name
Service accounts can be referred to using their full name
Default Service Account
Each namespace comes with a default service account:
apiVersion: v1 kind: ServiceAccount metadata: name: default namespace: default secrets: - name: default-token-dddkl
A pod whose service account was not explicitly configured will run with the default service account for its namespace, its configuration is equivalent with:
apiVersion: v1 kind: Pod spec: containers: - name: [...] [...] serviceAccountName: default [...]
The a specific service account can be configured as such:
apiVersion: v1 kind: Pod spec: containers: - name: [...] [...] serviceAccountName: something [...]
Non-Default Service Accounts
To use a non-default service account, set
spec.serviceAccountName field of the pod manifest. The service account has to exist at the time the pod is created, or it will be rejected. If the pod was already created, the service account cannot be updated.
Service Accounts and RolesThe recommended way to ensure that an application operates within a specific security scope is to bind a role or a set of roles to an application-specific service account. For more details, see:
Service Account Operations
- Details about the Namespace's Default Service Account
- Deploy a Service Account, a Role and a Role Binding with a Helm Chart
- Assigning a Cluster Role to a Service Account
When the API server handles a request, it first attempts to authenticate the identity making the request with one of the available authentication methods. If all authentication methods fail, and if anonymous request support is enabled, the identity is treated as anonymous requests, and given a username of
system:anonymous and a group of
API Authentication Strategies
Kubernetes provides various authentication strategies to be used by the clients that send API requests into the Kubernetes API server. These authentication strategies are implemented by the server's authentication plugins.
Client X.509 Certificates
kubectl allows specifying a bearer token in-line with
kubectl --token aHR0c...NiYg get pods
Webhook Token Authentication
EKS Webhook Token AuthenticationEKS has native support for webhook token authentication. See:
Service Account Tokens
TODO: reconcile Service Account Tokens and
Static Token File
HTTP Basic Auth
OpenID Connect Tokens
Controlling Access to the Kubernetes API
Role Based Access Control (RBAC)
Pod and Container Security
For more details on pod and container security concepts, including pod and container security contexts and pod security policies, see:
Kubernetes expects that all API communication in the cluster is encrypted by default with TLS, and the majority of installation methods will allow the necessary certificates to be created and distributed to the cluster components.