8.17 Kubernetes Pod Security Configuration

Kubernetes Pod Security Configuration is the set of mechanisms, fields, and policies used to define and enforce the security posture of Pods and the containers running inside them within a Kubernetes cluster. It governs how workloads interact with the underlying host, what privileges they are granted, which Linux capabilities they can use, how they access the filesystem, and how the cluster validates that these settings comply with organizational and platform-level security requirements. This configuration spans multiple layers, including the Pod specification itself, admission controllers that validate or mutate Pod definitions, and cluster-wide policies that constrain what is permissible.

Security Context

Pod-Level Security Context

The securityContext field at the Pod level applies settings that affect all containers within that Pod unless overridden at the container level. Common fields include runAsUser, runAsGroup, runAsNonRoot, fsGroup, and supplementalGroups. These fields control the user and group identifiers under which processes run, whether the Pod is permitted to run as the root user, and how ownership of mounted volumes is managed.

Container-Level Security Context

Container-level securityContext settings override Pod-level settings for a specific container. This includes fields such as privileged, allowPrivilegeEscalation, readOnlyRootFilesystem, and capabilities. Setting privileged to true grants the container nearly all the capabilities of the host machine, which significantly increases the attack surface and is generally discouraged except for workloads that explicitly require direct hardware or kernel access, such as certain networking or storage plugins.

Capabilities Management

Linux capabilities divide the privileges traditionally associated with the root user into distinct units. Kubernetes allows administrators to explicitly add or drop capabilities at the container level. A common hardening practice is to drop all capabilities by default using drop: ["ALL"] and then selectively add back only the capabilities a container genuinely requires, such as NET_BIND_SERVICE for binding to privileged ports below 1024.

Pod Security Standards

Privileged, Baseline, and Restricted Profiles

Kubernetes defines three built-in Pod Security Standards that represent increasing levels of restriction. The Privileged profile is unrestricted and allows for known privilege escalations, typically reserved for trusted system-level workloads. The Baseline profile prevents known privilege escalations while remaining broadly compatible with common workloads. The Restricted profile enforces the most stringent hardening, following current best practices for Pod security, including requirements around non-root execution, seccomp profiles, and disallowed capabilities.

Pod Security Admission

Pod Security Admission is the built-in Kubernetes admission controller that enforces the Pod Security Standards at the namespace level. Namespaces are labeled with pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/audit, or pod-security.kubernetes.io/warn, each paired with a profile name and optionally a version. The enforce mode rejects non-compliant Pods, audit records violations without blocking creation, and warn surfaces violations to the user without blocking the request.

Filesystem and Runtime Restrictions

Read-Only Root Filesystem

Setting readOnlyRootFilesystem: true prevents processes inside the container from writing to the container's root filesystem, forcing any required writable paths to be explicitly mounted as volumes such as emptyDir. This significantly reduces the ability of an attacker who gains code execution inside the container to persist malicious files or modify existing binaries.

Privilege Escalation Controls

The allowPrivilegeEscalation field, when set to false, ensures that a process cannot gain more privileges than its parent process, effectively disabling mechanisms such as setuid binaries from elevating privileges during execution. This setting is commonly paired with dropping all capabilities and running as a non-root user to form a hardened baseline configuration.

Seccomp and AppArmor Profiles

Seccomp profiles restrict the system calls a container's processes are permitted to invoke, reducing the kernel attack surface available to a compromised container. Kubernetes supports specifying seccomp profiles through the seccompProfile field, including the RuntimeDefault profile provided by the container runtime or custom profiles referenced by name. AppArmor provides a complementary mechanism on supported Linux distributions, applying mandatory access control profiles to constrain file access, network access, and capabilities on a per-container basis.

Service Accounts and Identity

Pod Service Account Configuration

Each Pod is associated with a Kubernetes service account that determines its identity when interacting with the API server. The automountServiceAccountToken field controls whether the service account token is automatically mounted into the Pod's filesystem. Disabling automatic mounting for Pods that do not require API server access reduces the risk of token exfiltration in the event of container compromise.

Least Privilege Role Bindings

Security configuration extends beyond the Pod specification into the RBAC bindings associated with the Pod's service account. Assigning narrowly scoped roles, rather than cluster-wide administrative permissions, ensures that even if a Pod's credentials are compromised, the resulting access is limited to the specific resources and verbs required for that workload's function.

Network and Resource Isolation

Host Namespace Sharing

Fields such as hostNetwork, hostPID, and hostIPC allow a Pod to share the corresponding namespace with the host node. Enabling these settings breaks the isolation boundary between the container and the host, exposing host-level network interfaces, process trees, or inter-process communication channels. These fields are typically restricted to system-level workloads and disallowed under the Restricted Pod Security Standard.

Resource Limits as a Security Boundary

While primarily a resource management mechanism, defining resources.limits for CPU and memory also serves a security function by preventing a single compromised or misbehaving Pod from exhausting node resources and impacting the availability of other workloads scheduled on the same node.

Policy Enforcement Beyond Built-In Standards

Admission Webhooks and Policy Engines

Beyond the built-in Pod Security Admission controller, clusters often adopt external policy engines such as OPA Gatekeeper or Kyverno to enforce custom validation and mutation rules on Pod specifications. These tools allow organizations to codify security requirements that go beyond the built-in profiles, such as mandating specific image registries, enforcing label conventions, or requiring specific annotations for compliance tracking.

Image Provenance and Admission Controls

Security configuration also encompasses controls over which container images are permitted to run, including restrictions on image sources, requirements for signed images, and vulnerability scanning gates enforced through admission webhooks before a Pod is allowed to be scheduled onto a node.