Kubernetes Security Best Practices
Last reviewed: — verified against Kubernetes 1.36.
Securing Kubernetes environments requires a defense-in-depth strategy that spans cluster setup, host hardening, workload deployment, runtime operations, and software supply chain integrity. This page is the head reference for the six Certified Kubernetes Security Specialist (CKS) exam domains, with practical guidance for production clusters.
Why Kubernetes Security Best Practices Matter
Kubernetes offers powerful orchestration capabilities, but its flexibility introduces complexity. Without strong operational security controls, clusters are vulnerable to:
- Configuration drift across environments
- Privilege escalation via misconfigured RBAC or capabilities
- Insecure container workloads (root, privileged, host namespaces)
- Undetected runtime threats and post-exploitation activity
- Compromised third-party dependencies, registries, and base images
Implementing the practices below mitigates these risks by enforcing security controls at every layer of the stack — from cluster bootstrap through workload runtime.
Mapping to the Six CKS Exam Domains
The CKS exam covers six weighted domains. Each maps to one or more sections on this site:
| # | CKS Domain | Weight | Where it is covered |
|---|---|---|---|
| 1 | Cluster Setup | 15% | Cluster Setup and Hardening |
| 2 | Cluster Hardening | 15% | Cluster Setup and Hardening |
| 3 | System Hardening | 10% | System Hardening |
| 4 | Minimize Microservice Vulnerabilities | 20% | Microservice Security |
| 5 | Supply Chain Security | 20% | Supply Chain Security |
| 6 | Monitoring, Logging & Runtime Security | 20% | Monitoring, Logging, and Runtime Security |
The three highest-weighted domains together account for 60% of the exam — Microservice Vulnerabilities, Supply Chain Security, and Monitoring/Runtime Security. Prioritize study time accordingly.
Topics Covered in This Section
Cluster Setup and Hardening
Secure the Kubernetes control plane, workloads, and networking using CIS benchmarks and validated tooling. Covers API server hardening, etcd encryption, RBAC, network policies, Pod Security Admission, and admission controllers.
System Hardening
Lock down the host operating system and node configurations. Includes Linux capabilities, kernel hardening, sysctl tuning, and minimizing the host attack surface.
Microservice Security
Minimize application-layer vulnerabilities and reduce workload risk. Covers Pod Security Standards, secrets management, and secure container configurations.
Supply Chain Security
Protect workloads from tampering, malware, and untrusted sources during the build and deployment process. Covers image scanning, admission controllers, SBOMs, and artifact signing.
Monitoring, Logging, and Runtime Security
Gain visibility into cluster activity and respond to anomalies in real time. Includes audit logging, runtime threat detection with Falco, eBPF-based observability with Tetragon and Tracee, and incident response.
Try It: Live YAML Security Analyzer
Paste a Kubernetes manifest below to see how it stacks up against these best practices. The analyzer runs entirely in your browser — no data leaves the page.
Tool Comparisons
Choosing the right tool for each layer is one of the harder problems in Kubernetes security. The tables below compare the most common alternatives across three categories.
Runtime Security: Falco vs Tetragon
| Aspect | Falco | Tetragon |
|---|---|---|
| CNCF status | Graduated | Incubating |
| Detection mechanism | eBPF or kernel module driver | eBPF (in-kernel hooks) |
| Primary purpose | Runtime threat detection and alerting | Observability and in-kernel enforcement |
| Rule format | YAML rules with expression DSL | TracingPolicy CRDs (YAML) |
| Ecosystem maturity | Mature; large community ruleset | Newer; smaller but growing |
| Enforcement | Alerts only (out-of-band response) | Can kill processes / send signals in-kernel |
| Best fit | SOC integration, alerting pipelines | Cilium environments, in-kernel response |
Admission Policy: Kyverno vs OPA Gatekeeper
| Aspect | Kyverno | OPA Gatekeeper |
|---|---|---|
| Policy language | Native Kubernetes YAML (CRDs) | Rego |
| Learning curve | Low — YAML is familiar | Higher — Rego is its own paradigm |
| Scope | Kubernetes-only | Kubernetes plus any other system using OPA |
| Mutation support | Built-in | Limited (separate Assign mutators) |
| Image verification | Built-in Cosign / Notary integration | Possible via custom Rego |
| Resource generation | Yes — generates downstream resources from policy | No |
| Best fit | Kubernetes-first teams, policy-as-YAML | Multi-platform policy, unified Rego across stacks |
Read more: Kyverno · OPA Gatekeeper
Vulnerability Scanning: Trivy vs Grype
| Aspect | Trivy | Grype |
|---|---|---|
| Maintainer | Aqua Security | Anchore |
| Scope | Vulnerabilities, secrets, IaC, SBOM, license, K8s configs | Vulnerabilities only |
| Targets | Images, filesystems, Git repos, K8s clusters, cloud accounts | Images, filesystems, SBOMs |
| Speed | Moderate (broader feature set) | Fast (narrow focus) |
| SBOM | Generates SBOMs natively | Pairs with Syft for SBOM generation |
| Continuous in-cluster scanning | Trivy Operator (open source) | Anchore Enterprise (commercial) |
| Best fit | One-tool-fits-all scanning across the SDLC | Lean vuln pipelines, SBOM-first workflows |
Read more: Trivy · Grype · Trivy Operator
Version-Specific Notes (Kubernetes 1.36)
Several controls and features have stabilized in recent Kubernetes versions. The following are GA in Kubernetes 1.36 and should be the default expectation for new clusters:
- Pod Security Admission — GA since 1.25. The built-in replacement for the removed PodSecurityPolicy. Enforce, audit, and warn modes are configured per-namespace via labels.
- KMS v2 encryption providers — GA since 1.29. Replaces KMS v1 for at-rest Secret encryption with improved performance and key rotation.
- AppArmor via
securityContext.appArmorProfile— GA since 1.31. The modern field replaces the oldercontainer.apparmor.security.beta.kubernetes.io/<container>annotation pattern. - Sidecar containers — GA since 1.33. Init containers with
restartPolicy: Alwaysare now the recommended pattern for lifecycle-bound sidecars (proxies, log shippers, secret rotators). - User namespaces (
hostUsers: false) — Beta in 1.30, GA in 1.33. Pods can run with a unique UID/GID range mapped to the host, dramatically reducing the impact of container escape on shared nodes.
Removed APIs to know about:
- PodSecurityPolicy — Removed in 1.25. If you still see PSP manifests in a repo, treat them as deprecated and migrate to Pod Security Admission or a policy engine (Kyverno, Gatekeeper).
extensions/v1beta1Ingress — Removed in 1.22. Usenetworking.k8s.io/v1.policy/v1beta1PodDisruptionBudget — Removed in 1.25. Usepolicy/v1.
Always check the Kubernetes deprecation guide before upgrading; some security-relevant fields move through alpha/beta gates that affect feature-gate flags on the API server.
Security Principles Across the Stack
These best practices align with key cloud-native security principles that apply at every layer.
Secure by Default
Use tools and settings that prioritize safety: restricted Pod Security Standards, default-deny NetworkPolicies, encryption-at-rest enabled at cluster bootstrap, and audit logging on from day one.
Least Privilege
Assign only the minimum permissions required to users, workloads, and ServiceAccounts. Drop all Linux capabilities and re-add only what is needed. Avoid wildcard verbs and resources in RBAC rules. Disable automountServiceAccountToken when a workload does not need API access.
Defense in Depth
Apply layered security from infrastructure (cloud IAM, node OS) to cluster components (API server, etcd, kubelet) to application code (signed images, vulnerability scans). One misconfiguration should not lead to compromise.
Continuous Verification
Monitor workloads and enforce policy throughout the runtime lifecycle, not just at deployment time. Combine admission control (Kyverno/Gatekeeper) with runtime detection (Falco/Tetragon) and continuous scanning (Trivy Operator).
Conclusion
This section provides tactical and strategic guidance for improving Kubernetes security posture across the six CKS domains. Combine the per-domain articles, the comparison tables above, and the embedded YAML analyzer to validate your manifests against these practices before they reach production.