Kubernetes Security Best Practices: A Practical Checklist

Securing Kubernetes is not a single control you switch on — it is a set of Kubernetes security best practices applied consistently across every layer of the stack. The community frames those layers as the 4C's: Cloud, Cluster, Container, and Code. A weakness in any one of them can undermine the others, which is why hardening has to run from the cloud account that hosts your nodes all the way down to the application code in your pods, and across the full lifecycle from build to deploy to runtime.

This article is the practical checklist. Rather than re-explaining every concept in depth, it groups the concrete actions you should take to harden a Kubernetes cluster and links out to focused deep dives when you want the full picture. Work through each section, tick the boxes that apply to your environment, and revisit them on a regular cadence — Kubernetes moves fast, and a secure cluster last quarter is not automatically a secure cluster today. If you want the strategic overview behind these tactics, start with our Kubernetes security pillar.

A quick note on how to use this list. No two clusters are identical, so treat these items as a baseline to adapt rather than a rigid mandate. Prioritize the controls that shrink blast radius — least privilege, network segmentation, and control-plane hardening — because they limit the damage of the incidents you cannot prevent. And wherever a manual step appears below, ask whether it can be enforced automatically instead. Checklists that live only in a wiki decay quickly; checklists encoded as policy and CI gates keep working while your team focuses on shipping.

Cluster and control plane

The control plane is the brain of your cluster. If an attacker reaches the API server or etcd, they effectively own everything running on it, so this is where hardening pays off most. Managed Kubernetes services handle some of this for you, but the responsibility is shared — you still own authentication, audit configuration, and how exposed the endpoint is.

• Upgrade Kubernetes regularly and stay on a supported release that still receives security patches.
• Restrict network access to the API server — never expose it to the public internet without tight controls, and prefer private endpoints or an allowlist.
• Disable anonymous authentication (--anonymous-auth=false) so every request is tied to an identity.
• Enable and centralize audit logging so you have a tamper-resistant record of who did what.
• Protect etcd: enable mutual TLS, restrict access to control-plane nodes only, and turn on encryption at rest for its data.
• Measure your cluster against the CIS Kubernetes Benchmark and remediate the findings that matter for your threat model.
• Rotate control-plane certificates and credentials on a defined schedule.

Access control

Most real-world Kubernetes incidents escalate because a compromised identity had far more power than it needed. Least privilege is the antidote: the goal is that a stolen token or a hijacked workload can reach only the narrow slice of the cluster it legitimately uses, and nothing more.

• Enforce RBAC least privilege — grant the narrowest set of verbs and resources a subject actually needs.
• Avoid binding cluster-admin to users, groups, or workloads except for genuine break-glass scenarios.
• Practice ServiceAccount hygiene: give each workload its own ServiceAccount and disable token automounting where it is not required.
• Audit ClusterRoleBindings and RoleBindings periodically to catch privilege creep.
• Integrate cluster authentication with your identity provider rather than relying on long-lived static credentials.

For the full walkthrough of roles, bindings, and common pitfalls, see Kubernetes RBAC best practices.

Workload and pod hardening

A pod that runs as root, mounts the host filesystem, or can escalate privileges turns a single application bug into a node compromise. Constrain what your workloads are allowed to do, and make the secure configuration the default that developers inherit rather than something each team has to remember.

• Enforce Pod Security Admission at the restricted level for production namespaces.
• Set a securityContext on every workload: runAsNonRoot, drop all Linux capabilities, disallow privilege escalation, and use a read-only root filesystem where possible.
• Never run privileged containers or mount the host network, PID, or IPC namespaces unless there is a hard requirement.
• Define resource requests and limits so a single workload cannot starve neighbors or enable a denial-of-service.
• Use a seccomp profile (start with RuntimeDefault) to limit the syscalls containers can make.

Dig into the details in Kubernetes pod security.

Network

By default, every pod in a cluster can talk to every other pod. That flat network is convenient and dangerous — it lets an attacker move laterally the moment they land in one workload. NetworkPolicies are how you turn that open floor plan into a set of locked rooms, so a foothold in a frontend service does not hand over the database tier as well.

• Apply a default-deny NetworkPolicy in each namespace, then explicitly allow only the traffic that is needed.
• Restrict egress so compromised pods cannot freely reach the internet or internal services.
• Segment sensitive workloads (databases, secrets managers) into their own namespaces with tighter policies.
• Confirm your CNI plugin actually enforces NetworkPolicies — not all of them do.
• Encrypt pod-to-pod traffic for sensitive paths, using mTLS or a service mesh where appropriate.

See Kubernetes network policies for patterns and examples.

Secrets

Secrets are high-value targets. Kubernetes Secrets are only base64-encoded by default, not encrypted, so they need deliberate protection.

• Enable encryption at rest for Secrets in etcd, ideally backed by a KMS provider.
• Lock down Secret access with RBAC so only the workloads and people that need a given secret can read it.
• Never hardcode secrets in manifests, container images, environment variables in source control, or CI logs.
• Prefer an external secrets manager and inject values at runtime rather than storing them long-term in the cluster.
• Rotate secrets regularly and revoke them immediately when exposure is suspected.

Full guidance lives in Kubernetes secrets management.

Images and supply chain

Everything you run starts as a container image. If that image is bloated, unpatched, or unverified, no amount of runtime hardening fully makes up for it. The supply chain behind that image — base layers, third-party dependencies, and the pipeline that builds it — is just as much a part of your attack surface as the cluster itself.

• Scan images for known vulnerabilities before deployment and continuously in your registry.
• Use minimal base images (distroless or slim) to shrink the attack surface and patch load.
• Sign images and verify signatures so only trusted artifacts run in your cluster.
• Enforce policy with an admission controller — reject unsigned images, images from untrusted registries, or images with critical unfixed vulnerabilities.
• Pin images by digest rather than mutable tags like latest.

More on this in Kubernetes image security and on our container security platform page.

Observability and runtime

Prevention is never perfect, so you also need to see what is happening in a running cluster and respond fast when something looks wrong. Runtime is where a misconfiguration you missed, a zero-day in a dependency, or a stolen credential actually plays out — and the difference between a contained incident and a breach is usually how quickly you notice and act.

• Collect and centralize logs and metrics from the control plane, nodes, and workloads.
• Deploy runtime threat detection to catch anomalous process, file, and network activity inside containers.
• Alert on suspicious events — new privileged pods, unexpected exec into containers, or changes to RBAC.
• Maintain and rehearse an incident response plan specific to Kubernetes, including how to isolate a compromised pod or node.
• Keep audit logs and runtime data long enough to support forensic investigation.

Shift-left and automation

The cheapest place to fix a Kubernetes misconfiguration is before it is ever applied. Automate your checks so security travels with every change instead of being bolted on at the end. A finding caught in a pull request is a quick edit; the same finding caught in production is an incident review, a change window, and a redeploy. Shifting left is what makes every other section of this checklist sustainable at scale.

• Scan Kubernetes manifests and Helm charts for misconfigurations in CI, and fail the build on high-severity findings.
• Scan your infrastructure-as-code (Terraform and similar) that provisions clusters and cloud resources.
• Gate merges and deployments on passing security checks so nothing insecure reaches production silently.
• Track findings over time and drive down the backlog rather than rubber-stamping exceptions.

This is the heart of moving from DevOps to DevSecOps. Our IaC security tooling helps you catch these issues at the source.

How Rainforest helps

Working through a checklist like this by hand across dozens of clusters and hundreds of repositories does not scale. Rainforest brings these controls together in one platform: scanning container images for vulnerabilities, checking Kubernetes manifests and infrastructure-as-code for misconfigurations before they ship, and surfacing findings directly in the developer workflow so issues get fixed early. Instead of chasing problems across disconnected tools, your teams get a consistent, prioritized view of where a cluster drifts from these best practices — and clear guidance on how to close the gap. Because the same platform covers code, images, and infrastructure-as-code, you can trace a runtime risk back to the manifest or dependency that introduced it, and fix it once at the source rather than patching the same class of issue cluster by cluster.

If you would like to see how this works against your own environment, explore our application security testing platform or book a demo.