The container ecosystem has been on an interesting trajectory lately. On one hand, Kubernetes continues its march toward maturity with each release hardening security defaults and graduating long-pending features. On the other hand, CISA and other security bodies have been publishing increasingly specific guidance about container security, reflecting both the widespread adoption and the persistent gaps in how organizations secure their containerized workloads.
This convergence — better tooling meeting higher expectations — is worth examining for anyone running production Kubernetes clusters, which at this point is most of us in the infrastructure space.
The State of Kubernetes Security in 2025#
Kubernetes has come a long way from the early days when the default configuration was essentially “trust everything.” Recent releases have been systematically addressing security concerns that practitioners have been working around for years.
Pod Security Standards, which replaced the deprecated Pod Security Policies, have been stable since 1.25 and are now widely adopted. The three levels — Privileged, Baseline, and Restricted — provide a clear framework for what pods should and shouldn’t be allowed to do. In practice, I’m seeing more organizations enforce the Restricted profile by default, with explicit exceptions for workloads that genuinely need elevated privileges.
User namespaces for pods, which allow mapping container root to an unprivileged user on the host, have been progressing through the beta stages. This is one of those features that sounds obscure but has significant security implications — it means that even if an attacker escapes the container, they land as an unprivileged user on the host rather than as root.
The ongoing work on Structured Authentication Configuration is also worth noting. Moving authentication configuration out of command-line flags and into structured, auditable configuration files is the kind of operational improvement that makes security teams sleep better at night.
CISA’s Container Hardening Guidance#
CISA has been updating its guidance on securing containerized environments, and the latest recommendations reflect a more sophisticated understanding of the container threat model than earlier versions. Key areas they’re emphasizing:
Image supply chain security: Signing container images and verifying signatures before deployment. Tools like Sigstore’s Cosign have made this significantly easier, and the integration with Kubernetes admission controllers means you can enforce signature verification at the cluster level. If you’re not signing your images yet, this should be near the top of your priority list.
Runtime security monitoring: Static analysis and scanning at build time catches known vulnerabilities, but runtime monitoring catches actual exploitation. Tools like Falco, Tetragon, and the commercial offerings from the likes of Sysdig and Aqua Security have matured considerably. The common pattern is using eBPF-based monitoring to detect anomalous system calls, network connections, and file access patterns without the performance overhead of traditional approaches.
Network policy enforcement: The default Kubernetes networking model allows any pod to communicate with any other pod in the cluster. Network policies exist to restrict this, but adoption remains patchy. CISA’s guidance specifically calls out the importance of implementing least-privilege network policies — every pod should only be able to reach the services it actually needs.
Secrets management: Kubernetes Secrets, stored as base64-encoded values in etcd, have always been a known weak point. The guidance pushes organizations toward external secrets management solutions — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — with the Kubernetes Secrets Store CSI driver providing a clean integration path. Encrypting Secrets at rest in etcd using KMS providers is the minimum bar.
What Platform Teams Should Be Doing#
Based on the current state of tooling and threat landscape, here’s what I’d recommend for platform teams managing Kubernetes in production:
Enforce Pod Security Standards at the namespace level. Start with the Baseline profile and work toward Restricted. Use audit mode first to understand the impact before enforcing.
Implement image signing and verification. The Sigstore ecosystem has made this accessible. Integrate Cosign into your CI/CD pipeline and use a policy engine like Kyverno or OPA Gatekeeper to enforce signature verification on admission.
Deploy runtime security monitoring. At minimum, use Falco with a curated rule set. Monitor for unexpected process execution, network connections, and file modifications in your containers. Alert on anomalies, don’t just log them.
Audit your network policies. Use tools like kubectl plugins or commercial solutions to visualize actual network traffic patterns, then write policies that match. Start with critical namespaces and expand outward.
Rotate credentials and review RBAC regularly. Service account tokens, kubeconfig files, and RBAC bindings tend to accumulate over time. Implement automated rotation and periodic reviews. The principle of least privilege is easy to state and hard to maintain without tooling.
The Supply Chain Angle#
Container security doesn’t start at deployment — it starts at the Dockerfile. The recent focus on software supply chain security, driven by incidents like SolarWinds and the xz utils backdoor, has put container build pipelines under increased scrutiny.
Using minimal base images (distroless, Alpine, or scratch), pinning dependencies to specific versions and hashes, scanning for vulnerabilities at build time, and generating SBOMs (Software Bills of Materials) are all practices that should be standard by now. The tooling is there — Trivy, Grype, Syft for SBOM generation — but consistent adoption remains a challenge in many organizations.
One pattern I’ve been advocating for is “golden image” pipelines — centrally maintained, pre-hardened base images that application teams build upon. This gives the security team a single place to enforce standards while giving developers a fast, compliant starting point. It’s not a new idea, but the tooling to implement it well has improved significantly.
My Take#
The container security story in 2025 is fundamentally different from where it was even two years ago. The tools are better, the defaults are more secure, and the guidance from security organizations is more practical and specific. The gap isn’t in tooling anymore — it’s in adoption and operational discipline.
What I find encouraging is the shift from “security as a gate” to “security as a platform feature.” When your Kubernetes cluster enforces pod security standards, verifies image signatures, and monitors runtime behavior by default, security becomes something the platform provides rather than something each team has to implement independently.
We’re not there yet — most clusters I encounter in the wild still have significant gaps — but the trajectory is clearly positive. The investment in getting this right is worth it. A compromised container in a well-hardened cluster is a contained incident. A compromised container in an unhardened cluster is a potential catastrophe.
If your platform team hasn’t done a security review of your Kubernetes setup recently, now’s a good time. The threat landscape hasn’t gotten friendlier, but at least the tools to defend against it have gotten better.