Kubernetes namespaces divide a cluster into manageable chunks. Namespaces provide a scope for names and facilitate the specification of various policies to a subsection of a cluster. By default, Kubernetes allocates a resource to a default namespace. Using a different namespace than the default reduces the impact of mistakes or malicious activities.

Example 1: The following configuration sets the namespace of a resource to default.

...
kind: ...
metadata:
...
namespace: default
spec:
...

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

A Kubernetes API server, the central management entity of a cluster, accepts HTTP Basic Authentication to authenticate users. HTTP Basic Authentication is deprecated and susceptible to brute force attacks and leaks user credentials to attackers in a misconfigured environment.

Example 1: The following configuration starts a Kubernetes API server and sets the --basic-auth-file=<filename>> flag to use HTTP basic authentication.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-apiserver
      - --basic-auth-file=<filename>
    image: example.domain/kube-apiserver-amd64:v1.6.0
    livenessProbe:
...

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

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.