| Myth | Reality |
|---|---|
| A managed Kubernetes service (EKS, GKE, AKS) is secure out of the box because the cloud provider runs the control plane. | Managed services harden the control plane, not your workloads. RBAC bindings, network policies, pod security standards, secrets handling, and node patching remain entirely the customer’s responsibility under the shared responsibility model. |
| Network policies are optional if you already have a service mesh. | A service mesh adds mTLS and traffic shaping, but without a default-deny NetworkPolicy the underlying CNI still allows any pod to reach any other pod on the pod network, mesh or not. |
| Running containers as non-root is enough to stop container breakout. | Non-root helps, but privilege escalation, hostPath mounts, and excess Linux capabilities can still lead to node compromise even from a non-root process. Pod Security Standards close these gaps together, not individually. |
| Base64-encoded Secrets in etcd are “encrypted.” | Base64 is encoding, not encryption. Anyone with etcd read access or a backup file can decode Secrets instantly unless you explicitly enable encryption at rest. |
Why Kubernetes Hardening Is a Program, Not a Setting
Kubernetes ships with sane defaults for scheduling, networking, and storage, but almost none of those defaults are security defaults. The API server accepts requests from any authenticated identity unless RBAC is scoped tightly. The pod network is flat unless a CNI plugin enforces NetworkPolicy objects. Containers can run as root, mount the host filesystem, and request dangerous Linux capabilities unless admission control blocks them. Secrets sit in etcd as base64 text unless encryption at rest is turned on. None of this is a bug — it is a deliberate design choice that favors flexibility for cluster operators who are expected to apply their own controls.
That means hardening a cluster is not a single afternoon task. It is an ongoing program that touches identity and access management, workload configuration, network segmentation, secrets lifecycle, and a patching cadence that has to survive contact with a release calendar. This checklist orders the work by blast-radius reduction: the earlier items stop the most damage per hour invested, and the later items close residual gaps that matter mostly once the fundamentals are in place.
Step 1: Lock Down RBAC With Least Privilege
Role-Based Access Control is the first line of defense because a compromised credential with cluster-admin rights turns any breach into a full cluster takeover. The most common failure mode in real audits is not a missing RBAC policy — it is an overly broad one copied from a tutorial and never revisited.
Practical RBAC Steps
- Audit every ClusterRoleBinding for cluster-admin and remove any that are not tied to a genuine break-glass or platform-team identity.
- Scope Roles to namespaces wherever possible instead of reaching for ClusterRoles by default.
- Grant verbs explicitly (get, list, watch) rather than using wildcard * permissions on resources.
- Disable auto-mounting of service account tokens on pods that never call the API server, using automountServiceAccountToken: false.
- Create one service account per workload rather than sharing the namespace default service account across every deployment.
- Review aggregated ClusterRoles carefully — a role that aggregates into edit or admin can quietly gain new permissions when Kubernetes adds new resource types.
| RBAC Role Scope | Typical Use Case | Risk If Overused |
|---|---|---|
| cluster-admin | Break-glass platform operations only | Full cluster compromise from a single leaked token |
| Namespace-scoped admin | Team leads managing their own namespace | Cross-team blast radius if namespace boundaries are weak |
| Namespace-scoped edit | CI/CD deployment service accounts | Unauthorized workload modification, secret exfiltration |
| Namespace-scoped view | Read-only dashboards, auditors | Low risk, but still exposes Secret metadata if not filtered |
Step 2: Enforce Default-Deny Network Policies
Kubernetes networking is flat by default: every pod can reach every other pod, including pods in different namespaces, unless a NetworkPolicy says otherwise. That single fact explains why so many container breaches escalate from “one compromised web pod” to “attacker reached the database and the secrets store” in the same afternoon. A default-deny NetworkPolicy per namespace, with explicit allow rules layered on top, converts a flat network into a segmented one.
A Baseline Default-Deny Policy
Figure: Default-deny network policy pattern
A namespace starts with a policy selecting all pods and denying both ingress and egress. Teams then add narrowly scoped allow policies for the specific pod-to-pod, pod-to-database, and pod-to-external-API paths their application actually needs, so anything not explicitly permitted is blocked by default.
- Start every namespace with a policy that selects all pods (empty podSelector) and denies all ingress and egress.
- Layer in allow rules scoped to labels, not IP ranges, since pod IPs churn constantly.
- Explicitly allow DNS egress (typically to kube-system on port 53) or every other policy will appear to break application connectivity.
- Segment ingress controllers, application tiers, and data tiers into separate namespaces with policies between them, not just within them.
- Verify your CNI plugin actually enforces NetworkPolicy — some CNIs still ship without policy enforcement enabled, which makes the policy objects silently inert.
Step 3: Apply Pod Security Standards and Admission Control
Kubernetes replaced the deprecated PodSecurityPolicy with Pod Security Standards (PSS), enforced through the built-in Pod Security Admission controller or a policy engine like Kyverno or OPA Gatekeeper. PSS defines three levels — Privileged, Baseline, and Restricted — and most production namespaces should target Restricted, which blocks root containers, host namespace sharing, privilege escalation, and dangerous capabilities in one pass.
Admission Control Checklist
- Label namespaces with pod-security.kubernetes.io/enforce: restricted once workloads have been validated against the standard.
- Run new namespaces in warn and audit mode first to catch violations before flipping to enforce.
- Block hostPath volumes, host networking, and host PID/IPC namespace sharing outside of tightly justified system daemons.
- Require readOnlyRootFilesystem: true wherever the application does not need to write to its own container filesystem.
- Drop all Linux capabilities by default and add back only the specific ones a workload needs, such as NET_BIND_SERVICE for a process binding to a low port.
- Use a policy engine like Kyverno or OPA Gatekeeper for rules PSS does not cover, such as requiring resource limits or blocking the :latest image tag.
| Pod Security Standard Level | What It Blocks | Recommended Use |
|---|---|---|
| Privileged | Nothing — unrestricted | System namespaces only (CNI, CSI drivers) |
| Baseline | Known privilege escalations, host namespace sharing | Transitional namespaces migrating to stricter policy |
| Restricted | Root containers, added capabilities, host paths, privilege escalation | Default target for all application namespaces |
Step 4: Handle Secrets Like Secrets
Kubernetes Secrets are base64-encoded, not encrypted, by default. Anyone with etcd access, a cluster backup, or sufficient RBAC read permissions can decode them in one command. Hardening secrets handling means addressing storage, transit, and access all at once.
- Enable encryption at rest for etcd using a KMS provider so Secret data is actually encrypted on disk, not just base64-encoded.
- Restrict RBAC read access to Secret objects tightly — “get” on secrets is one of the most sensitive verbs in the entire API.
- Prefer an external secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) synced into the cluster via an operator like External Secrets Operator, rather than storing long-lived credentials directly as Kubernetes Secrets.
- Rotate service account tokens and any long-lived credentials on a defined schedule rather than treating them as set-and-forget.
- Avoid mounting Secrets as environment variables where possible; volume mounts are less likely to leak into logs or crash dumps.
Step 5: Establish an Upgrade and Patching Cadence
Kubernetes releases a new minor version roughly every four months and typically only supports the latest three minor versions with patches. Falling behind means running known-vulnerable API server, kubelet, and container runtime code with no vendor patch path back to a supported version. A hardening checklist that stops at configuration and ignores patch cadence will decay within a year.
Patch Cadence Checklist
- Track the Kubernetes release calendar and plan control plane upgrades before end-of-life for your current minor version.
- Patch node operating systems and container runtimes (containerd, CRI-O) on a monthly cadence at minimum, faster for critical CVEs.
- Subscribe to the Kubernetes security announcements list and your cloud provider’s security bulletins so critical CVEs reach you before attackers act on them.
- Test upgrades in a staging cluster that mirrors production API versions and CRDs before rolling to production.
- Automate node image rebuilds so patched base images roll out through normal deployment pipelines rather than manual node SSH sessions.
| Hardening Layer | Primary Control | Failure Mode If Skipped |
|---|---|---|
| Identity | Least-privilege RBAC | One leaked token becomes cluster-wide compromise |
| Network | Default-deny NetworkPolicy | Lateral movement from any single compromised pod |
| Workload | Pod Security Standards (Restricted) | Container breakout to host node |
| Data | Encrypted Secrets, external secrets manager | Credential theft from etcd or backups |
| Lifecycle | Patch cadence tied to release calendar | Running known-CVE control plane and kubelet versions |
Choosing a Policy Engine: Kyverno vs. OPA Gatekeeper
Pod Security Admission covers the built-in Restricted, Baseline, and Privileged standards, but most platform teams eventually need custom rules that PSS was never designed to express — requiring resource limits on every container, blocking the mutable :latest tag, enforcing label conventions for cost allocation, or requiring images to come from an approved registry. That is where a general-purpose policy engine comes in, and the two dominant open-source options are Kyverno and OPA Gatekeeper.
Kyverno is written specifically for Kubernetes and expresses policies as native Kubernetes YAML manifests, which lowers the learning curve considerably for teams who are comfortable with Kubernetes resources but do not want to learn a new policy language. It also supports mutation, meaning it can automatically inject defaults — such as adding a default resource limit or a missing label — rather than only validating and rejecting. OPA Gatekeeper is built on the more general-purpose Open Policy Agent project and uses Rego, a purpose-built policy language that is more expressive for complex, cross-resource logic but carries a steeper learning curve for teams without prior Rego experience. Organizations already using OPA for API gateways or CI/CD policy gates often standardize on Gatekeeper for consistency; teams starting fresh with Kubernetes-only policy needs frequently find Kyverno faster to adopt and easier for application teams to read and audit themselves.
Whichever engine you choose, treat policies themselves as code: store them in version control, review changes through pull requests, and test new policies in warn mode against real workload manifests before enforcing them, exactly as recommended for Pod Security Standards rollout.
Auditing and Continuous Verification
Hardening is not a one-time project; it needs continuous verification. Enable the Kubernetes audit log and ship it to a SIEM so RBAC changes, Secret access, and exec-into-pod events are all recorded and searchable. Run the CIS Kubernetes Benchmark against your cluster on a schedule using a tool like kube-bench, and run image and configuration scans in CI so misconfigured manifests never reach the cluster in the first place. Treat configuration drift the same way you treat code drift — with automated checks that fail a pipeline rather than a person who has to remember to look.
Verification should also extend outward from the cluster itself into the surrounding supply chain. Scan container images for known vulnerabilities before they are pushed to a registry, sign images and verify signatures at admission time so only artifacts built by your own pipeline can be deployed, and maintain a software bill of materials for the components running inside your cluster so a newly disclosed CVE in a base image or library can be matched against running workloads in minutes rather than days. None of these controls live inside Kubernetes itself, but a hardened cluster running an unverified, unscanned image is still an exposed cluster. Pair cluster-level hardening with pipeline-level controls — restricting who can modify deployment manifests, requiring code review on Helm chart and Kustomize changes, and rotating the credentials your CI/CD system uses to deploy — so the path from source code to running pod is as tightly controlled as the cluster it deploys into.
Finally, revisit the checklist itself on a schedule. Kubernetes hardening guidance shifts as new CVEs are disclosed, as the CIS Benchmark is revised, and as your own cluster footprint grows from a single environment to dozens of clusters across regions and cloud providers. A quarterly review of RBAC bindings, network policies, and admission configuration catches the drift that inevitably creeps in as teams ship features under deadline pressure.
Common mistake
Teams frequently harden the control plane and workloads but leave the default service account in every namespace with its automatically mounted token untouched. Any pod in that namespace, even one with no legitimate reason to call the Kubernetes API, ends up with a working credential mounted at a well-known filesystem path. Attackers who land in an unrelated container check that path first because it so often still works.
What worked
Rolling out namespaces in stages — warn mode for two weeks, audit mode for two more, then enforce — caught misconfigured workloads before they broke in production, and gave application teams a paper trail to justify emergency exceptions without stalling the entire rollout.
Frequently Overlooked Hardening Details
- Kubelet authorizationThe kubelet API can be left in AlwaysAllow mode on unmanaged clusters; switch it to webhook authorization tied to RBAC.
- etcd network exposureetcd should never be reachable outside the control plane network; anyone with direct etcd access bypasses RBAC entirely.
- Admission webhook failure policyA misconfigured webhook set to “Ignore” on failure silently stops enforcing policy exactly when something goes wrong.
- Image provenancePulling images by mutable tag instead of digest lets an upstream registry change what actually runs without any change to your manifests.
- Dashboard exposureThe Kubernetes Dashboard, if deployed, needs its own RBAC scoping — several public breaches trace back to an internet-exposed dashboard with default access.
- Resource limits as a security controlMissing CPU and memory limits let a single compromised or buggy pod starve an entire node, becoming an availability incident on top of a security one.
Glossary
- RBAC (Role-Based Access Control)
- The Kubernetes authorization mechanism that grants permissions to users and service accounts through Roles and RoleBindings scoped to namespaces or the whole cluster.
- NetworkPolicy
- A Kubernetes API object that restricts which pods can communicate with which other pods and external endpoints, enforced by the cluster’s CNI plugin.
- Pod Security Standards (PSS)
- A set of three predefined policy levels — Privileged, Baseline, and Restricted — that constrain pod security context settings such as root access and Linux capabilities.
- Admission Controller
- A piece of code that intercepts requests to the Kubernetes API server before an object is persisted, used to validate or mutate objects against policy.
- etcd
- The distributed key-value store that holds all Kubernetes cluster state, including Secrets, making it one of the most sensitive components to secure.
- CIS Kubernetes Benchmark
- A set of consensus-based configuration recommendations published by the Center for Internet Security for hardening Kubernetes clusters.
Key Takeaways
- Kubernetes has almost no security defaults; hardening is a program covering identity, network, workload, data, and patch cadence together.
- Least-privilege RBAC is the highest-priority control because a single over-privileged credential can compromise the entire cluster.
- Default-deny NetworkPolicies stop lateral movement, which is the difference between a contained incident and a cluster-wide breach.
- Pod Security Standards at the Restricted level close root access, capability, and host-path escape routes in one consistent policy.
- Kubernetes Secrets are base64-encoded, not encrypted; encryption at rest and an external secrets manager close that gap.
- A defined patch cadence matters as much as configuration, since Kubernetes only supports the latest three minor versions with patches.
- Continuous verification through audit logs, CIS benchmark scans, and CI-time manifest checks keeps hardening from decaying after the initial rollout.
FAQs
What is the single highest-priority Kubernetes hardening control to implement first?
Least-privilege RBAC comes first because an over-permissioned credential — especially any binding to cluster-admin — turns a single leaked token or compromised pod into a full cluster takeover, making every other control less effective until access is scoped down.
Are managed Kubernetes services like EKS, GKE, and AKS secure by default?
Managed services harden the control plane infrastructure itself, but RBAC bindings, network policies, pod security configuration, secrets encryption, and workload patching remain the customer’s responsibility under the shared responsibility model, so hardening work is still required.
What replaced PodSecurityPolicy after its removal from Kubernetes?
Pod Security Standards, enforced through the built-in Pod Security Admission controller, replaced PodSecurityPolicy. Many clusters supplement PSS with a policy engine like Kyverno or OPA Gatekeeper for rules the built-in standards do not cover.
Why doesn’t a service mesh make NetworkPolicy unnecessary?
A service mesh adds encryption and traffic management at the application layer, but without a default-deny NetworkPolicy the underlying CNI still permits any pod to reach any other pod at the network layer, regardless of what the mesh enforces above it.
How often should Kubernetes clusters be patched?
Kubernetes typically supports only the latest three minor versions with patches, released roughly every four months, so control planes should be upgraded before end-of-life, and node operating systems and container runtimes patched at least monthly, faster for critical CVEs.
Are base64-encoded Kubernetes Secrets safe to store as-is?
No. Base64 is an encoding format, not encryption, and anyone with etcd access, a cluster backup, or sufficient RBAC read permission on Secret objects can decode them instantly unless encryption at rest and tighter RBAC scoping are both applied.
What is the safest way to roll out Pod Security Standards without breaking production workloads?
Apply the Restricted standard in warn and audit modes first so violations are surfaced in logs without blocking anything, give teams time to fix flagged workloads, and only switch the namespace label to enforce mode once violations have dropped to zero or a documented exception.
What tool can verify a cluster against the CIS Kubernetes Benchmark?
kube-bench is a widely used open-source tool that runs the CIS Kubernetes Benchmark checks against a live cluster and reports pass/fail results across control plane, node, and policy configuration areas, making it a practical way to verify hardening on a recurring schedule.
For related hardening guidance, see our container security best practices, our breakdown of secrets management patterns, our guide to infrastructure as code security scanning, and our API security checklist. If you are building a broader DevSecOps program, our piece on shifting security left without blocking developers and our secure coding practices tutorial are useful next reads.
- SentinelOne, “Kubernetes Security Checklist for 2026” – sentinelone.com
- AppSecSanta, “Kubernetes Security: CIS Hardening Guide (2026)” – appsecsanta.com
- AquilaX, “Kubernetes Security Hardening: A Practical Guide” – aquilax.ai
- Center for Internet Security, CIS Kubernetes Benchmark documentation
- National Security Agency and CISA, “Kubernetes Hardening Guidance” – media.defense.gov
- Kubernetes documentation, “Pod Security Standards” – kubernetes.io
