Kubernetes Security Hardening Checklist for

This is the checklist I use when auditing enterprise Kubernetes clusters. Fifty checks across seven categories, ordered by impact.

1. Pod Security (10 checks)

# ✅ Enforce Pod Security Standards at namespace level
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

• Pod Security Standards enforced (restricted for production)
• No containers running as root (runAsNonRoot: true)
• No privilege escalation (allowPrivilegeEscalation: false)
• All capabilities dropped (drop: ["ALL"])
• Read-only root filesystem where possible
• Seccomp profile set (RuntimeDefault minimum)
• No hostNetwork, hostPID, or hostIPC
• Resource limits set on all containers (CPU + memory)
• No privileged containers in production namespaces
• AppArmor or SELinux profiles applied

2. RBAC (8 checks)

• No cluster-admin bindings for service accounts
• Principle of least privilege — namespace-scoped roles only
• No wildcard permissions (* in resources or verbs)
• Service accounts have automountServiceAccountToken: false unless needed
• Regular RBAC audit (who has access to what)
• Break-glass procedure documented for emergency access
• No default service account used for workloads
• Aggregated ClusterRoles reviewed for unintended permissions

3. Network Security (8 checks)

# ✅ Default deny all traffic, then allow explicitly
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

• Default deny NetworkPolicy in all production namespaces
• Egress restricted — pods can only reach necessary services
• Ingress restricted to specific sources
• DNS egress allowed only to kube-dns
• No pods with unrestricted internet access
• mTLS between services (Istio/Linkerd/Cilium)
• API server access restricted to known networks
• etcd encrypted and not directly accessible

4. Secrets Management (7 checks)

• etcd encryption at rest enabled
• External secrets manager (Vault, AWS Secrets Manager, Azure Key Vault)
• No secrets in environment variables (use volume mounts)
• No secrets in container images or Git repositories
• Secret rotation policy and automation
• CSI secrets store driver for production workloads
• Sealed Secrets or SOPS for GitOps-managed secrets

5. Image Security (7 checks)

• Images pulled from private registry only (no Docker Hub in production)
• Image vulnerability scanning in CI/CD (Trivy, Grype, Snyk)
• No images with critical/high CVEs deployed
• Image signing and verification (Cosign + Sigstore)
• Admission controller blocks unsigned images (Kyverno/OPA)
• Base images pinned to digest (not latest tag)
• Distroless or minimal base images preferred

6. Runtime Security (5 checks)

• Runtime threat detection deployed (Falco, Kubescape, Tetragon)
• Anomaly detection for unexpected process execution
• File integrity monitoring for critical paths
• Network anomaly detection for data exfiltration attempts
• Incident response runbook for runtime alerts

7. Audit and Compliance (5 checks)

• Kubernetes audit logging enabled and shipped to SIEM
• CIS Kubernetes Benchmark scan passing (kube-bench)
• Regular penetration testing of cluster and workloads
• Compliance report generation automated (SOC 2, PCI-DSS, HIPAA)
• Cluster upgrade policy — no more than 1 minor version behind

Scoring

• 40+/50: Enterprise-ready
• 30-39: Significant gaps — prioritize remediation
• 20-29: High risk — immediate action needed
• Under 20: Not production-ready

Related Resources

• AI Agent Security on Kubernetes
• Kubernetes RBAC Guide
• Kubernetes Network Policies
• Container Security with Trivy
• DevSecOps Pipeline
• Zero Trust Architecture
• Kyverno Policy Engine

About the Author

I am Luca Berton, AI and Cloud Advisor. I audit and harden Kubernetes clusters for regulated enterprises. Book a consultation.