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

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

A Kubernetes API server sends instructions to Kubelets to create workload, queries status of Kubelet-managed resources, and provides optional port-forwarding services to Kubelets. By default, the API server does not verify a Kubelet's serving certificate before establishing connection. This connection is therefore susceptible to a man-in-the-middle attack.

Example 1: The following command starts a Kubernetes API server without specifying a root certificate bundle to verify the Kubelet's serving certificate with the --kubelet-certificate-authority flag.

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

A Kubernetes API server can authorize a request using one of several authorization modes. The Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by Kubelets. This ensures that Kubelets have the minimal set of permissions required to operate correctly.

Example 1: The following configuration starts a Kubernetes API server without the Node authorization mode.

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

Always enable the NodeRestriction admission controller for a Kubernetes API server. The NodeRestriction admission controller limits every Kubelet to modify its Node and Pod objects as well as deny access to sensitive system objects. This prevents any compromised node from gaining privileges on other nodes of a Kubernetes cluster.

Example 1: The following Pod definition starts a Kubernetes API server without enabling the NodeRestriction admission controller.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=PodSecurityPolicy
    ...

The lack of a PodSecurityPolicy admission controller is indicative of weak security controls unless there is an alternative policy enforcement tool for Kubernetes such as K-Rail, Kyverno, OPA/Gatekeeper. The PodSecurityPolicy admission controller enforces Pod security policies that specify permissible security-related Pod attributes in a cluster. For instance, using PodSecurityPolicy, you can forbid privileged containers and disallow privilege escalation by default whenever a Pod is created.

Example 1: The following Pod definition starts a Kubernetes API server without enabling the PodSecurityPolicy admission controller.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=NodeRestriction
    ...

A Kubernetes API server can authorize a request using one of several authorization modes. The role-based access control (RBAC) controls access to computer or network resources based on the roles of individual users within an organization. RBAC is the most secure authorization mode.

Example 1: The following configuration starts a Kubernetes API server without the RBAC authorization mode.

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

It is good practice to define permissions on a granular basis that adhere to the Least Privilege Principle. A Kubernetes security context defines privileges and access control settings for a Container or Pod. A Container lacks security context if there is no such setting at both the Pod and Container level.

Example 1: The following configuration defines a Pod without any security context because there is no securityContext field.

apiVersion: v1
kind: Pod
...
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP

The SecurityContextDeny admission controller prevents Pods from setting certain SecurityContext fields that allow for privilege escalation in a Kubernetes cluster. Unless there is an alternative policy enforcement tool for Kubernetes, such as appropriate Pod security policies, the SecurityContextDeny admission controller should be enabled.

Example 1: The following Pod definition starts a Kubernetes API server without enabling the SecurityContextDeny admission controller.

apiVersion: v1
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --enable-admission-plugins=NodeRestriction
    ...

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