Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

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.

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.

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