DevSecOps in Practice

Common Kubernetes Manifests Security Issues

Securing Kubernetes manifests is essential to ensuring the resilience and integrity of containerized applications. Misconfigurations in manifests can introduce vulnerabilities that expose workloads to security risks, privilege escalation, or data breaches. This is why it is important to analyze Kubernetes manifests in a static way before deploying them to a cluster. In the next section, we will use Kube-linter to analyze the Kubernetes manifests for our RestQR application. However, before we do that, let's discuss some common security issues in Kubernetes manifests and how to mitigate them.

Running Containers as Root

By default, containers in Kubernetes may run as the root user, which can be exploited if an attacker gains access to the pod. This can be prevented by enforcing a non-root user policy.

Issue:

securityContext:
  runAsUser: 0

Fix:

securityContext:
  runAsUser: 1000  # Use a non-root user
  runAsNonRoot: true

Privileged Containers

Privileged containers have full access to the host, which increases the attack surface. Unless explicitly required, privileged mode should be disabled.

Issue:

securityContext:
  privileged: true

Fix:

securityContext:
  privileged: false

Missing Read-Only Root Filesystem

Allowing a writable root filesystem makes it easier for attackers to modify application files and binaries.

Issue:

securityContext:
  readOnlyRootFilesystem: false

Fix:

securityContext:
  readOnlyRootFilesystem: true

Allowing Host Network and Host PID/IPC Access

Using the host network, process ID, or inter-process communication namespaces can expose sensitive host information and enable lateral movement within the cluster.

Issue:

hostNetwork: true
hostPID: true
hostIPC: true

Fix:

hostNetwork: false
hostPID: false
hostIPC: false

Insecure Capabilities

Containers should run with the minimum necessary Linux capabilities to prevent privilege escalation.

Issue:

securityContext:
  capabilities:
    add:
      - NET_ADMIN

Fix:

securityContext:
  capabilities:
    drop:
      # Remove all unnecessary capabilities
      - ALL  

Using Default Service Accounts

Pods should not use the default Kubernetes service account, as it may have excessive permissions.

Issue:

serviceAccountName: default

Fix:

# Use a dedicated service account with minimal permissions
serviceAccountName: custom-sa  

Missing Resource Requests and Limits

Defining resource limits prevents resource exhaustion attacks and improves workload stability.

Issue:

resources:
  requests:
    cpu