Kubernetes Security Checklist for Production (2026)

Securing a Kubernetes cluster in production requires a layered, defense-in-depth approach. Misconfigurations remain the leading cause of container breaches, and the attack surface of a default Kubernetes installation is far broader than most teams realize. This checklist distills the most critical security controls into ten actionable areas — use it as a baseline audit for any cluster running production workloads.

1. API Server Access Control

The Kubernetes API server is the front door to your cluster. Every request — from kubectl commands to controller reconciliation loops — passes through it. Weak access controls here compromise everything downstream.

• Enforce least-privilege RBAC. Audit every ClusterRoleBinding and RoleBinding. Remove default bindings that grant broad access. Use namespace-scoped Role objects instead of ClusterRole wherever possible, and never bind cluster-admin to application service accounts.
• Enable audit logging. Configure the API server with an audit policy that captures at least Metadata-level events for all resources and RequestResponse-level events for secrets, RBAC objects, and authentication endpoints. Ship logs to an immutable store.
• Disable anonymous authentication. Set --anonymous-auth=false on the API server. Use short-lived bound service account tokens rather than long-lived static tokens or client certificates with multi-year expiry.

2. Network Policies

By default, every pod in a Kubernetes cluster can communicate with every other pod — across namespaces, without restriction. Network Policies are the primary mechanism for implementing microsegmentation.

• Apply default-deny ingress and egress in every namespace. Start with a blanket deny rule, then selectively allow required traffic. This inverts the model from “everything allowed unless blocked” to “everything blocked unless permitted.”
• Restrict pod-to-pod communication by label selector. Define policies allowing frontend pods to reach backend pods, backend to databases, and nothing else. Be explicit about port numbers — do not allow all TCP traffic when only port 5432 is needed.
• Use a CNI plugin that enforces policies reliably. Verify your chosen plugin (Calico, Cilium, Antrea) actively enforces both ingress and egress rules. Test enforcement by attempting blocked connections in a staging cluster.

3. Pod Security Standards

Pod Security Standards (PSS) replace the deprecated PodSecurityPolicy API. They define three profiles — Privileged, Baseline, and Restricted — that control what security-sensitive fields a pod spec may contain.

• Enforce the Restricted profile for application workloads. The Restricted profile requires pods to drop all capabilities, run as non-root, use a read-only root filesystem, and disallow privilege escalation. Apply it via the pod-security.kubernetes.io/enforce: restricted namespace label.
• Use Baseline for system namespaces that need flexibility. Some infrastructure components (log collectors, CNI agents) legitimately need host networking or elevated capabilities. Apply Baseline to these namespaces but audit each exception individually.
• Run in warn and audit mode before enforcing. Before switching to enforce, use warn and audit modes first. This surfaces violations without breaking deployments, giving teams time to remediate.

4. Image Security

Container images are the software supply chain’s last mile. A compromised or outdated image introduces vulnerabilities directly into your runtime environment.

• Scan every image in your CI/CD pipeline. Integrate Trivy, Grype, or Snyk into your build pipeline. Fail builds that contain critical or high-severity CVEs. Scan on a schedule — new vulnerabilities are discovered against existing images constantly.
• Require signed images and verify at admission. Use cosign (Sigstore) to sign images at build time, and deploy an admission controller (Kyverno or OPA Gatekeeper) that rejects any image without a valid signature.
• Pin images by digest, never use :latest. The :latest tag is mutable. Pin image references to immutable SHA256 digests (e.g., myapp@sha256:abc123...) so deployments are reproducible and auditable.

5. Secrets Management

Kubernetes Secrets are base64-encoded by default — not encrypted. Anyone with read access to the API server or etcd can trivially decode them. Mature secret management requires layers beyond the built-in primitives.