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

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