Introduction
Kubernetes provides powerful infrastructure capabilities, but its default configuration prioritizes functionality over security. A default Kubernetes cluster has several security vulnerabilities that attackers can exploit. Hardening your cluster requires deliberate configuration across multiple layers — from the API server to Pod security to network policies. This guide covers the most important Kubernetes security practices for 2025.
API Server Security
The Kubernetes API server is the central control plane component and the primary target for attackers. Enable authentication and authorization for all API server requests. Use role-based access control, or RBAC, to grant the minimum permissions necessary for each user, service account, and application. Enable audit logging to record all API server requests for security review and incident investigation. Restrict anonymous access and ensure the API server is not publicly accessible from the internet.
Pod Security Standards
Kubernetes Pod Security Standards provide a framework for restricting what Pods can do within a cluster. The baseline profile prevents known privilege escalation attacks. The restricted profile enforces a strict set of security requirements aligned with Pod hardening best practices. Enable Pod Security Admission at the namespace level to enforce these standards, and use the restricted profile for production workloads wherever possible.
Network Policies
By default, all Pods in a Kubernetes cluster can communicate with all other Pods. Network policies allow you to define fine-grained rules that restrict which Pods can communicate with each other. Implementing a default-deny network policy and then explicitly allowing required communication paths follows the principle of least privilege and significantly reduces the blast radius of a compromised Pod. Network policies require a CNI plugin that supports them, such as Calico or Cilium.
Secrets Management
Kubernetes Secrets are base64-encoded by default, not encrypted. Enable encryption at rest for Secrets in the etcd database. Use external secrets management solutions like HashiCorp Vault or the cloud provider’s secrets service, integrated with Kubernetes through tools like the External Secrets Operator. Avoid mounting secrets as environment variables where possible — mount them as files instead, which is harder for application code to accidentally log.
Container Image Security
Only pull container images from trusted registries. Use image pull policies that prevent running unverified images. Implement image signing and verify signatures before deploying images using tools like Cosign and the Sigstore project. Scan images for vulnerabilities using tools like Trivy or Grype in your CI/CD pipeline and as a cluster-level admission webhook. Regularly update base images to incorporate security patches.
Conclusion
Kubernetes security requires a defense-in-depth approach that addresses every layer of the stack. No single control is sufficient; security comes from the combination of all controls working together. Our Kubernetes security hardening and assessment services provide the expertise your team needs. Read more on our Kubernetes security and compliance blog.
