Securing Kubernetes Pod Security

In a distributed orchestration environment, the unit of execution-the Pod-is often treated as an ephemeral, disposable commodity. However, from a security perspective, a Pod is a potential beachhead. If an attacker exploits a vulnerability in a web application running inside a container, their first objective is lateral movement and privilege escalation. Without rigorous Pod security controls, a single compromised container can escalate to host-level access, allowing an adversary to intercept traffic, steal secrets, or compromise the entire cluster.

Securing Kubernetes Pods is not about a single configuration; it is about reducing the attack surface by enforcing strict boundaries between the container, the node, and the Kubernetes API.

The Shift from PSP to PSA

For years, the industry relied on PodSecurityPolicies (PSP) to govern pod creation. However, PSP was notoriously complex, difficult to audit, and prone to misconfiguration. Following its deprecation, Kubernetes introduced Pod Security Admission (PSA).

Unlike its predecessor, PSA is built directly into the Kubernetes admission controller. It operates based on the Pod Security Standards (PSS), which define three distinct implementation levels:

1. Privileged: Unrestricted. This level allows for the most permissive configurations, essentially bypassing most security checks. It is intended only for system-level components (e.g., CNI plugins, storage drivers).
2. Baseline: The "minimum viable security" tier. It prevents known privilege escalation vectors (like host namespace sharing) but allows for a degree of flexibility required by many standard applications.
3. Restricted: The most hardened tier. It implements a strict set of-security best practices, requiring containers to run as non-root, dropping all unnecessary Linux capabilities, and restricting filesystem access.

Anatomy of an Insecure Pod

To understand the risk, we must examine the configuration patterns that facilitate container breakouts. An insecure Pod manifest often relies on "privileged" mode or host-level access to function.

```yaml

WARNING: INSECURE CONFIGURATION

apiVersion: v1

kind: Pod

metadata:

name: vulnerable-pod

spec:

containers:

• name: exploit-target

image: alpine

securityContext:

privileged: true # Grants nearly all capabilities of the host kernel

volumeMounts:

• mountPath: /host-root

name: host-filesystem

volumes:

• name: host-filesystem

hostPath:

path: / # Allows the container to see and modify the entire node filesystem

```

In this example, the `privileged: true` flag combined with a `hostPath` mount of the root directory (`/`) is catastrophic. An attacker gaining shell access to this Pod can modify `/etc/shadow` on the host, inject SSH keys, or manipulate `kubelet` configurations to gain control over the underlying node and, subsequently, the cluster.

Engineering the Hardened Pod

Securing a Pod requires a "Defense in Depth" approach, primarily implemented through the `securityContext`. A hardened Pod should adhere to the Restricted standard.

```yaml

SECURE CONFIGURATION

apiVersion: v1

kind: Pod

metadata:

name: hardened-pod

spec:

securityContext:

runAsNonRoot: true

runAsUser: 1000

fsGroup: 2000

containers:

• name: secure-app

image: alpine

securityContext:

allowPrivilegeEscalation: false

capabilities:

drop:

• ALL

readOnlyRootFilesystem: true

seccompProfile:

type: RuntimeDefault

volumeMounts:

• mountPath: /tmp

name: tmp-volume

volumes:

• name: tmp-volume

emptyDir: {}

```

Key Hardening Mechanisms:

1. `runAsNonRoot: true`: This is the most fundamental check. It ensures the container engine validates that the image is not attempting to start with UID 0.
2. `allowPrivilegeEscalation: false`: This prevents a process from gaining more privileges than its parent process (e.g., via `setuid` binaries).
3. `capabilities: drop: ["ALL"]`: Linux capabilities break down "root" power into smaller pieces (e.g., `CAP_NET_ADMIN`, `CAP_SYS_TIME`). By dropping `ALL`, you strip the container of almost all kernel-level manipulations.
4. `readOnlyRootFilesystem: true`: Most applications do not need to write to their own binaries or system directories. Making the root filesystem read-only prevents attackers from downloading toolsets (like `nmap` or `netcat`) or modifying application code.
5. `seccompProfile: type: RuntimeDefault`: Secure Computing (seccomp) filters the system calls a container can make to the Linux kernel. Using `RuntimeDefault` applies the profile provided by the container runtime (like containerd), significantly reducing the kernel attack surface.

Implementation and Operational Strategy

Implementing PSA at scale requires a phased approach. Moving an entire production namespace from `Privileged` to `Restricted` overnight will inevitably cause service outages.

The Three-Mode Deployment Pattern

The PSA controller supports three modes: `enforce`, `audit`, and `warn`.

• `warn`: This is your primary tool for developer feedback. When a developer applies a manifest that violates the target level, the API server returns a warning. This allows teams to fix manifests before they hit production.
• `audit`: This generates an entry in the Kubernetes audit logs. Use this to monitor

Conclusion

As shown across "The Shift from PSP to PSA", "Anatomy of an Insecure Pod", "Engineering the Hardened Pod", a secure implementation for securing kubernetes pod security depends on execution discipline as much as design.

The practical hardening path is to enforce admission-policy enforcement plus workload isolation and network policy controls, host hardening baselines with tamper-resistant telemetry, and continuous control validation against adversarial test cases. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track mean time to detect and remediate configuration drift and mean time to detect, triage, and contain high-risk events, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.