Private keys used for encryption or signing should be considered sensitive data and should be encrypted with a strong passphrase prior to storage. This prevents unauthorized access by both attackers in the event of theft or a leak, as well as by users with insufficient permissions.

Example 1: The following code exports an RSA private key using an unencrypted PEM format:

from Crypto.PublicKey import RSA

key = RSA.generate(2048)
f = open('mykey.pem','w')
f.write(key.exportKey(format='PEM'))
f.close()

If profiling is enabled, a component provides performance metrics through a web interface. The performance metrics reveal system data that help an adversary form a plan of attack. Either the --profiling flag is not present in the command to start the component or the flag is set to true.

By default, Kubelets automatically make the required changes to iptables based on the networking options in Pod configurations. Setting makeIPTablesUtilChains to enabled:false in a Kubelet configuration prevents the Kubelet from managing network traffic between containers and the rest of the world. This prevents the Kubelet from enforcing the necessary network security requirements and setting up the connectivity requested by containers.

Example 1: The following Kubelet configuration prevents a Kubelet from making the required changes to iptables because of the setting makeIPTablesUtilChains: false.

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

If profiling is enabled, a component provides performance metrics through a web interface. The performance metrics reveal system data that help an adversary form a plan of attack. Either the --profiling flag is not present in the command to start the component or the flag is set to true.

By default, a Kubernetes container runtime prevents applications from writing to the root file system of the container. The readOnlyRootFilesystem: false setting disables this restriction, which allows an attacker to tamper with the local file system or write malicious executable to disk.

Example 1: The following manifest sets the readOnlyRootFilesystem field to false, which permits applications inside a container to write data to the local disk.

...
kind: Pod
...
spec:
  containers:
  - name: ...
    ...
    securityContext:
    readOnlyRootFilesystem: false
    ...

Pulling a container image from a registry typically requires authorization. Kubernetes nodes, however, cache all images of previously started containers. An attacker can bypass the required authorization by starting a container with a cached image. The AlwaysPullImages admission controller can prevent this bypass.

Example 1: The following configuration starts a Kubernetes API server without the AlwaysPullImages admission controller in the --enable-admission-plugins flag.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=PodNodeSelector,LimitRanger
    ...

Admission controllers validate and customize requests to a Kubernetes API Server. They can implement security controls such as rejecting unauthorized privileged requests, enforcing namespace isolation, limiting excessive resource requests, and many more. The API Server does not validate requests because there is no admission controller or the deprecated AlwaysAdmit admission controller is enabled.

Example 1: The following configuration starts a Kubernetes API server with the AlwaysAdmit admission controller.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=AlwaysAdmit,PodSecurityPolicy
    ...

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
  ...

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
    ...

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

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

Kubelets can authenticate clients but the Certificate Authority (CA) bundle used to verify the client certificate is not defined in the Kubelet Configuration. Because Kubelets are the Kubernetes principal agents used 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 Kubelet configuration does not contain the clientCAFile field that specifies the CA bundle used to verify client certificates.

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

By default, a Kubernetes API server does not authenticate itself to Kubelets when submitting requests. Kubelets, that provide access to a wide variety of resources, cannot verify the authenticity of these requests.

Example 1: The following command starts a Kubernetes API server without specifying a client certificate and the corresponding private key with the --kubelet-client-certificate flag and the --kubelet-client-key flag respectively to enable certificate-based authentication to Kubelets.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
    image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...