7 Kubernetes Container Security Controls That Matter

Kubernetes container security hardening comes down to four layers that reinforce each other: enforce the Pod Security Standards at the namespace level, strip privileges from every security context, encrypt secrets at rest, and codify the rules as policy that admission rejects automatically. Get these right and the most common container attack paths — privileged pods, exposed host namespaces and readable credentials — close at deployment time instead of at incident time. The foundation is the Pod Security Standards, which define three cumulative policy levels, privileged, baseline and restricted, that move from highly permissive to heavily restrictive isolation.

Where Containers Get Compromised

Most container compromises in Kubernetes clusters follow a predictable script. An attacker obtains a foothold through an exposed workload, then looks for a pod configured with privileged: true, shared host network or PID namespaces, or a writable hostPath volume. Any one of those turns an application-level compromise into node-level access, and node-level access is often a short walk to cluster-admin. Credential sprawl widens the blast radius: tokens and passwords pasted into pod specs, ConfigMaps and images are trivial to read once a namespace is reachable. Tight egress rules matter here too, because they cut the outbound connections used to exfiltrate data and pull in attack tooling — the same logic behind tight egress traffic control in the cloud.

Enforce Pod Security Standards

The Pod Security Standards give you a shared vocabulary for what pods may do, and the built-in controller that enforces the Pod Security Standards has been stable since Kubernetes v1.25. Enforcement is driven by namespace labels, so each team or environment can carry a different posture without installing anything.

Each namespace can run three modes at once: enforce rejects violating pods, audit records violations to the audit log, and warn returns a user-facing warning without blocking. A safe rollout looks like this:

1. Label namespaces with warn and audit at baseline, leaving enforce unset.
2. Fix the violations surfaced in warnings and audit annotations over one or two release cycles.
3. Turn on enforce at baseline for the namespace.
4. Repeat the cycle, moving security-critical namespaces to enforce at restricted.

Because the levels are cumulative, restricted includes everything baseline blocks, so following the ladder in order never leaves a control behind.

Lock Down Every Security Context

Policy sets the floor; the security context sets the ceiling for each workload. Three settings deliver most of the value: run containers as a non-root user, drop all Linux capabilities and re-add only the ones the service demonstrably needs, and set allowPrivilegeEscalation: false so a setuid binary inside the image cannot resurrect root. The escalation field defaults to allowing it when left undefined, which is exactly why policy should require it explicitly rather than trusting developers to remember. Mounting a read-only root filesystem and writing state to emptyDir volumes closes another common path, since dropped tooling and fileless payloads then have nowhere to persist inside the container between restarts.

Protect Secrets at Rest

Kubernetes Secrets are convenient and dangerous in equal measure. By default they are stored unencrypted in the API server’s underlying data store and anyone with API access can retrieve or modify a Secret — which makes etcd encryption and tight RBAC non-negotiable. The project’s own minimum bar is explicit: enable encryption at rest for Secrets, apply least-privilege RBAC rules, restrict which containers can mount each Secret, and consider an external secret store for high-value credentials. Treating secret lifecycle as its own discipline, rather than an afterthought of deployment, is the core of a durable cloud secrets management strategy.

Add Policy as Code

Namespace labels cover the standards, but real clusters need rules the standards do not express: required labels, banned image registries, resource limits and network policy defaults. A policy engine closes that gap. Kyverno, for example, can enforce policies as a Kubernetes admission controller and also runs as a CLI-based scanner, so identical rules gate review, admission and audit. For a measurable baseline, align the rule set with the CIS Kubernetes Benchmark, which is the product of a community consensus process and consists of secure configuration guidelines developed for Kubernetes. Map each control to a policy, score the cluster continuously, and treat regressions as build failures rather than quarterly findings.

Hardening Checklist

• Every namespace carries pod-security labels, with enforce active at baseline or above.
• No pod runs privileged, shares host namespaces or mounts hostPath volumes.
• Security contexts set non-root users, dropped capabilities and no privilege escalation.
• Encryption at rest is enabled for Secrets and RBAC scopes each one to its consumers.
• Policy-as-code rules are versioned with the application and fail the pipeline on drift.
• Egress from pods flows only through explicitly allowed destinations.

Sources

• Kubernetes — Pod Security Standards
• Kubernetes — Pod Security Admission
• Kubernetes — Secrets
• Kyverno — Introduction
• CIS — Kubernetes Benchmarks