Kubernetes Security Best Practices: A Practical Guide

Kubernetes makes it easy to deploy applications at scale, and just as easy to deploy insecure configurations at scale. Many Kubernetes components are permissive by default, and a single over-privileged pod or service account can be enough for an attacker to take over an entire cluster and the cloud account behind it.

This guide covers the Kubernetes security best practices that matter most, organized by layer, with a checklist at the end.

How Kubernetes Clusters Are Attacked

Understanding the typical attack path helps prioritize defenses:
Initial access: a vulnerable application in a container, an exposed dashboard or API server, or leaked credentials such as a kubeconfig file.
Discovery: the attacker reads the service account token mounted in the pod and checks what it can do through the Kubernetes API.
Privilege escalation: using excessive RBAC permissions, creating privileged pods or escaping from a container to the node.
Lateral movement: reading secrets, moving between namespaces and reaching other workloads through an unrestricted network.
Cloud takeover: using node or workload credentials to access the underlying cloud account.
MITRE ATT&CK for Containers documents these techniques in detail.

1. Secure the API Server and Control Plane

Do not expose the Kubernetes API server to the whole internet; restrict access to known networks or use private endpoints
Disable anonymous authentication and use a central identity provider for human access
Enable audit logging and send logs outside the cluster
Encrypt Secrets at rest in etcd and restrict access to etcd itself
Keep Kubernetes up to date within supported versions
Never expose administrative dashboards publicly

Managed services such as EKS, AKS and GKE handle much of the control plane, but API access, authentication settings and logging remain your responsibility.

2. Apply Least Privilege with RBAC

Role-based access control is where many cluster takeovers start.

Avoid granting cluster-admin to users, CI systems or applications
Prefer namespaced Roles over ClusterRoles where possible
Watch for dangerous permissions that allow privilege escalation: creating pods, reading secrets, impersonation, escalate and bind verbs, and wildcards on resources or verbs
Give each workload its own service account with only the permissions it needs
Disable automatic mounting of service account tokens (automountServiceAccountToken: false) for pods that do not call the Kubernetes API
Review RBAC regularly, including permissions granted to third-party tools and operators

3. Harden Workloads with Pod Security Standards

Kubernetes defines three Pod Security Standards: Privileged, Baseline and Restricted. Pod Security Admission, which replaced the removed PodSecurityPolicy, enforces them per namespace. Aim for Restricted for application workloads:

Run containers as a non-root user
Do not run privileged containers or allow privilege escalation
Drop all Linux capabilities and add back only what is required
Do not share the host’s network, process or IPC namespaces
Avoid hostPath volumes, which can expose the node’s file system
Use a read-only root file system where possible
Apply seccomp profiles (at least RuntimeDefault)
Set CPU and memory limits to prevent resource exhaustion

4. Restrict Network Traffic

By default, every pod can talk to every other pod in the cluster.

Use NetworkPolicies to start from a default-deny posture in each namespace and allow only required traffic
Make sure your network plugin actually enforces NetworkPolicies
Restrict egress, including access to the cloud metadata endpoint from pods that do not need it
Separate sensitive workloads into their own namespaces or clusters

5. Protect Secrets

Kubernetes Secrets are only Base64-encoded, not encrypted, unless encryption at rest is configured.

Enable encryption at rest for Secrets
Restrict who and what can read Secrets through RBAC; get and list on secrets are powerful permissions
Consider an external secrets manager integrated through a CSI driver or operator
Never store credentials in container images, ConfigMaps or environment variables in manifests committed to Git. See Hardcoded Secrets.

6. Secure Images and the Supply Chain

Use minimal base images and rebuild them regularly
Scan images for vulnerabilities in CI and in your registry
Pull images only from trusted registries, and pin them by digest rather than mutable tags such as latest
Sign images and verify signatures before deployment
Generate an SBOM for each image

7. Enforce Policy with Admission Control

Admission controllers check every resource before it is created. Beyond Pod Security Admission, policy engines such as OPA Gatekeeper or Kyverno can enforce rules like “only signed images from our registry”, “every deployment needs resource limits” or “no public load balancers in this namespace”. Policies can also be checked earlier, in CI, by scanning manifests and Helm charts, as part of IaC security analysis.

8. Harden Nodes and Managed Clusters

Use hardened, minimal node operating systems and keep them patched
Restrict SSH access to nodes
In managed clusters, give node and workload identities only the cloud permissions they need, and use workload identity features rather than node-wide credentials
Review your cluster against the CIS Kubernetes Benchmark

9. Monitor and Respond

Collect Kubernetes audit logs, container logs and node telemetry centrally
Use runtime security tools to detect suspicious behavior such as shells in containers or unexpected network connections
Alert on high-risk API activity: new cluster role bindings, privileged pods, secret access from unusual identities

Kubernetes Security Checklist

[ ] API server not publicly exposed; anonymous access disabled
[ ] Audit logging enabled and exported
[ ] No unnecessary cluster-admin bindings; RBAC reviewed
[ ] Service account tokens not mounted where not needed
[ ] Restricted Pod Security Standard enforced for application namespaces
[ ] Default-deny NetworkPolicies in place
[ ] Secrets encrypted at rest; access restricted
[ ] Images scanned, pinned by digest and from trusted registries
[ ] Admission policies enforce your rules
[ ] Cloud permissions for nodes and workloads minimized
[ ] Runtime monitoring and alerting configured

Conclusion

Kubernetes security is about limiting blast radius: least-privilege access to the API, hardened pods, restricted networks, protected secrets and trusted images. Each layer makes it harder for one compromised container to become a compromised cluster.

Want to see what an attacker could do inside your cluster? Our Kubernetes Penetration Testing service tests your clusters from the outside and from a compromised pod, and our Kubernetes Security Training teaches your team to harden them. Talk to our team to get started.

Subscribe to our cyber security newsletter

Scroll to top