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.

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

Kubernetes keeps sensitive data in an etcd cluster. An etcd instance accepts connections from clients without certificates signed by trusted certificate authorities because the command to start the etcd with the --client-cert-auth flag is set to false.

Example 1: The following configuration starts an etcd instance and sets the --client-cert-auth flag to false.

...
spec:
  containers:
    - command:
  ...
      - etcd
  ...
      --client-cert-auth=false
  ...

Kubernetes keeps sensitive data in an etcd cluster. Every etcd instance must serve clients over TLS connections but the command-line flags for setting up the TLS connections are missing.

Example 1: The following configuration starts an etcd instance without specifying both the --cert-file and --key-file flags for setting up TLS connections.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
  ...

Kubernetes keeps sensitive data in an etcd cluster. Every etcd instance in a cluster should always communicate with peers over a TLS connection but the command-line flags for setting up the TLS connection are missing.

Example 1: The following configuration starts an etcd instance without specifying both the --peer-cert-file and --peer-key-file flags for setting up a TLS connection.

apiVersion: v1
spec:
  containers:
    - command:
      - etcd
      - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
...

Insufficiently protected data communication channels can put critical organizational data at risk of theft, tampering, or disclosure.

Insufficiently protected data communication channels can put critical organizational data at risk of theft, tampering, or disclosure.

Log files should be kept long enough to facilitate post-incident analysis and threat detection, as well as to meet compliance requirements. The --audit-log-maxage flag defines the maximum number of days to retain old audit log files. Either the flag is not present in the command to start a Kubernetes API server or the retention period is set to less than 30 days.

Example 1: The following command starts a Kubernetes API server and sets --audit-log-maxage flag to 2 (2 days), which is too short.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxage=2
    ...

The Kubernetes API server automatically rotates log files. To facilitate post-incident analysis and threat detection, as well as to meet compliance requirements, you must retain a sufficient amount of log data. The --audit-log-maxbackup flag defines the maximum number of log files to retain. Either this flag is not present in the command to start a Kubernetes API server or the maximum number of log files to retain is less than 10.

Example 1: The following command starts a Kubernetes API server and sets the --audit-log-maxbackup flag to 2, which insufficiently retains only two log files.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxbackup=2
    ...

The Kubernetes API server automatically rotates log files. To facilitate post-incident analysis and threat detection, as well as to meet compliance requirements, you must retain a sufficient amount of log data. The --audit-log-maxsize flag sets the maximum size in megabytes (MB) of the audit log file before it's automatically rotated. Either this flag is not present in the command to start a Kubernetes API server or the maximum size of the audit log file is set to less than 100 MB.

Example 1: The following command starts a Kubernetes API server and sets the --audit-log-maxsize flag to 2 (megabytes), which is insufficient.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - ----audit-log-maxsize=2
    ...

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

If the ProtectKernelDefaults setting is left unset or is set to false, a Kubelet can modify kernel parameters at runtime. Kernel parameters should be optimized and hardened before the Kubernetes deployment. Granting a Kubelet the ability to alter kernel parameters expands the attack surface of the host operating system.

Example 1: The following Kubelet configuration permits a Kubelet to configure kernel parameters because of the ProtectKernelDefaults: false setting.

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

There is a configuration that permits Kubelets to serve anonymous requests. Anonymous requests are not rejected by any configured authentication method. Because Kubelets are the Kubernetes principal agents to manage a worker machine workload, attackers can use anonymous requests to gain access to insufficiently protected and security sensitive service APIs.

Example 1: The following configuration file permits a Kubelet to serve anonymous requests because the anonymous field is set to enabled:true.

...
kind: KubeletConfiguration
...
authentication:
  anonymous:
    enabled: true
...

The streamingConnectionIdleTimeout field of a Kubelet configuration specifies the maximum amount of time a streaming connection is idle before the connection is automatically closed. Setting idle timeouts protects against denial-of-service attacks and running out of connections. Setting the field value to 0 disables the idle timeout.

Example 1: The following Kubelet configuration disables the streaming connection timeout by setting the streamingConnectionIdleTimeout field to 0.

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

A Kubernetes API server can authorize a request using one of several authorization modes. The API server does not perform any authorization check in AlwaysAllow mode because it allows all requests.

Example 1: The following configuration starts a Kubernetes API server with AlwaysAllow as one of the authorization modes.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --authorization-mode=...,AlwaysAllow,...
    ...

The Kubernetes controller manager starts without the --root-ca-file flag, which specifies a root Certification Authority (CA) file. As a result, the Kubernetes controller manager does not publish a corresponding root CA certificate to Pods. Without the root CA certificate, the Pods cannot verify the API server's serving certificate before establishing connections. Such connections are susceptible to a man-in-the-middle attack.

Example 1: The following configuration starts a Kubernetes controller manager without the --root-ca-file flag.

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

A Kubernetes controller initiates garbage collection to reclaim resources occupied by terminated Pods when their number exceeds a threshold. Although excessive garbage collection degrades performance, the default threshold of 12500 is too high for a typical cluster. Before any garbage collection occurs, the cluster can run low on resources and become unstable.

Example 1: The following configuration starts a Kubernetes controller manager without specifying a threshold.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-controller-manager
    image: example.domain/kube-controller-manager:v1.9.7
    imagePullPolicy: IfNotPresent
...

A Kubelet authorizes a request using either the AlwaysAllow mode or the Webhook mode. An unspecified authorization mode defaults to AlwaysAllow. The Kubelet does not perform any authorization check in AlwaysAllow mode because it allows all requests. Because Kubelets are the Kubernetes principal agents to manage a worker machine workload, attackers can use uncontrolled requests to gain access to insufficiently protected and security sensitive service APIs.

Example 1: The Kubelet does not perform any authorization check because the authorization mode is set to AlwaysAllow.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authorization:
  mode: AlwaysAllow