A Kubernetes API server can authenticate API requests by service account tokens. Such tokens are generated and signed by the Kubernetes token controller. Use the --service-account-private-key-file flag to specify the token signing key.

Example 1: The following configuration starts a Kubernetes controller manager without the --service-account-private-key-file flag.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
        - kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
...

Kubernetes distinguishes between the concept of a user account and a service account, which is for a process to run in a Pod. The ServiceAccount admission controller automates the service account management. Some benefits of the ServiceAccount admission controller are to mitigate access token exfiltration with automated credential rotation and eliminate the need to persist secrets in storage. The ServiceAccount admission controller is enabled by default but has been deliberately disabled.

Example 1: The following Pod definition starts a Kubernetes API server and disables the ServiceAccount admission controller.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=ServiceAccount,PodNodeSelector
    ...

The deletion of Kubernetes namespace removes all objects in that namespace, including Pods and services. The NamespaceLifecycle admission controller maintains the integrity of Kubernetes systems in two ways. First, it prevents objects from being created in non-existent namespaces or in namespaces undergoing termination. Second, it prevents system reserved namespaces, which contain Kubernetes critical services, from being deleted.

The NamespaceLifecycle admission controller is enabled by default but the command to start the Kubernetes API server has disabled it with the --disable-admission-plugin flag.

Example 1: The following configuration starts a Kubernetes API server. The presence of the NamespaceLifecycle included in the --disable-admission-plugins flag disables the NamespaceLifecycle admission controller.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --disable-admission-plugins=...,NamespaceLifecycle,...
    ...

Kubernetes keeps sensitive data in an etcd cluster. Therefore, every etcd instance should only accept connections from authenticated and authorized peers and reject any peers that use self-signed certificates for TLS connections.

Example 1: The following configuration starts an etcd instance and sets the --peer-auto-tls flag to true. As a result, the etcd instance uses self-signed certificates for TLS connections with peers.

	...
	spec:
	containers:
	- command:
	...
	- etcd
	...
	- --peer-auto-tls=true
	...

A Kubernetes capability permits a Pod to perform named root actions without giving full root access. The CAP_SYS_ADMIN capability grants the permission to perform the widest possible range of system administration operations to a Pod.

Example 1: The following Kubernetes manifest adds the CAP_SYS_ADMIN capability to a container in a Pod.

...
kind: Pod
...
spec:
  containers:
...
    securityContext:
      capabilities:
        add:
        - CAP_SYS_ADMIN
        - SYS_TIME
        ...

By default, a Kubernetes container is denied access to all devices on the host. The privileged field allows the container almost all the same privileges as other processes running on the host. This expands the attack surface and violates the principle of running images with least privileges.

Example 1: The Pod runs in a privileged mode by setting privileged: true.

...
kind: Pod
...
spec:
  containers:
    - name: ...
      image: ...
      securityContext:
         privileged: true
...

To maintain backward compatibility, a Kubelet can serve a subset of its APIs at a read-only port without requiring authentication or authorization. Return values of those APIs contain very detailed specifications and performance metrics of the node that the Kubelet serves as well as metadata of Pods deployed to the node.

Example 1: The following configuration sets the Kubelet read-only port to 12345.

...
kind: KubeletConfiguration
...
readOnlyPort: 12345
...

An information leak occurs when system data or debug information leaves the program through an output stream, logging function, debugger, or profiler. Access to system data can help an adversary form a plan of attack.

Unless otherwise specified, any newly created Pod is automatically assigned a default service account. For each service account, an API access token is automatically generated and made available in a mounted directory. Attackers can use the access token in any compromised Container to gain access to insufficiently protected and security-sensitive service APIs.

The automounting of API credentials for the default service account of a Pod is not disabled because automountServiceAccountToken is not defined or the configuration of the default service account contains the automountServiceAccountToken: true setting.

Example 1: API credentials for the default service account of a Pod are automounted if the automountServiceAccountToken is not defined or is set to true, as in this example.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: demo-namespace
automountServiceAccountToken: true
...

Example 2: API credentials are automounted for a Pod because there is an automountServiceAccountToken: true setting in the default service account as in this example.

apiVersion: v1
kind: Pod
  ...
spec:
  automountServiceAccountToken: true
  ...

Service account credentials are shared among controllers because the command to start the Kubernetes controller manager does not contain the --use-service-account-credentials=true flag. This flag instructs the controller manager to start each controller using a separate service account. When used in combination with role-based access control (RBAC), this ensures that each controller runs with the minimum permissions needed to perform its tasks.

Example 1: The following configuration starts a Kubernetes controller manager without the --use-service-account-credentials flag.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - command:
        - /usr/local/bin/kube-controller-manager
    image: k8s.gcr.io/kube-controller-manager:v1.9.7
...

A Kubernetes API server authenticates requests by comparing bearer tokens to a list kept in a static token file. The token file stores secrets in plaintext and is static in nature. Static token-based authentication is susceptible to brute force attacks and can leak access credentials to attackers in a misconfigured environment. To add, replace, or revoke a token, you must restart the API server.

Example 1: Using the --token-auth-file flag, the following configuration starts a Kubernetes API server that authenticates requests by static tokens.

...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --token-auth-file=<filename>
    ...

The Kubernetes controller manager monitors the state of a cluster and if required, can make changes in any resources the cluster manages. By default, a controller manager accepts requests from external connections. From an external connection, an attacker can gain access to security sensitive but insufficiently protected APIs.

Example 1: The following configuration starts a Kubernetes controller manager without a bind address.

...
spec:
  containers:
  - command:
    - kube-controller-manager
    - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    image: example.domain/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
    ...

Kubernetes Scheduler determines where Pods run. By default, a scheduler accepts requests from external connections. From an external connection, an attacker can access insufficiently protected and security sensitive APIs.

Example 1: The following configuration starts a Kubernetes Scheduler without a bind address.

...
spec:
  containers:
    - command:
      - kube-scheduler
    image: example.domain/kube-scheduler:v1.5.2
    imagePullPolicy: IfNotPresent
    ...

A Kubernetes API server does not log events if there is no audit policy file specified. The event logs contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-policy-file flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-path=<the log file path>
  image: example.domain/kube-apiserver-amd64:v1.6.0
  ...

Billable computational resources include but are not limited to CPU usage, memory, persistent storage, and network connections. In the absence of resource usage limits, attackers could cause a denial of service that consumes all available resources or incur exorbitant bills.

Kubernetes keeps sensitive data in an etcd cluster. Therefore, every etcd instance should only accept connections from authenticated and authorized clients and reject any client that uses a self-signed certificate for TLS connections.

Example 1: The following configuration starts an etcd instance and sets the --auto-tls flag to true. As a result, the etcd instance uses self-signed certificates for TLS connections with clients.

...
spec:
  containers:
  - command:
...
    - etcd
    ...
    - --auto-tls=true
    ...

The tlsCertFile and tlsPrivateKeyFile fields in a Kubelet configuration define the x509 certificate used to serve HTTPS. By failing to provide both of them, a self-signed certificate and key are generated for the public address, which is susceptible to a man-in-the-middle attack.

Example 1: The following Kubelet configuration does not specify the tlsCertFile and tlsPrivateKeyFile fields so the Kubelet automatically generates a self-signed certificate for TLS connections.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.

Uncontrolled access to critical or sensitive resources can significantly impact an organization in various ways, including disclosure of or tampering with critical data.