By Olivia Harper. Fact-checked against Kubernetes project documentation, CNCF and NSA/CISA guidance, 2025–2026 security research and public vulnerability reports.
The biggest Kubernetes security change of 2026 wasn’t a new feature. In March 2026, Ingress NGINX, one of the most widely used controllers for routing traffic into clusters, stopped receiving fixes, including security fixes. Clusters that run it still work, but any new flaw stays open.
Most guides to Kubernetes security best practices predate that change. Where Kubernetes and security meet, the details shift with every release. This guide groups 15 current practices by layer and ends with a checklist you can run against your own cluster. It builds on our cloud security guide.
What Is Kubernetes Security?
Kubernetes security is the set of controls that protects a cluster and the workloads running on it. It decides who can reach the API, what pods are allowed to do, how traffic moves between them, which images run and how attacks get spotted while they’re happening.
So what is Kubernetes security in practice? The Kubernetes project splits it into four layers, the 4 Cs: cloud, cluster, container and code. Each sits inside the one before it, so a strict pod policy won’t save a cluster whose cloud account is wide open.
When engineers talk about k8s security, they usually mean the cluster and container layers, and that’s where this guide focuses.
What Do EKS, AKS and GKE Secure for You?
Amazon EKS, Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE) run the control plane for you. Most of the security work stays with you:
| The provider handles | You handle |
|---|---|
| API server uptime and scaling | Who can call it: RBAC and endpoint access |
| etcd storage and availability | Encrypting Secrets with your own key |
| Control-plane patching | Cluster upgrades and worker-node patching |
| Hosts and core networking | Pods, network policies, images and add-ons such as ingress controllers |
That’s why AWS’s EKS security best practices guide and Microsoft’s Azure Kubernetes security best practices both focus on identity, workloads and network rules.
GKE Autopilot and EKS Auto Mode also manage the worker nodes, but your workloads and access stay yours.
What Changed in Kubernetes Security in 2025-2026?
If you skimmed the Kubernetes security news of the past 18 months, these changes matter most:
- March 2025: IngressNightmare (CVE-2025-1974, CVSS 9.8) left about 43% of cloud environments vulnerable and more than 6,500 clusters exposed to the internet.
- August 2025: v1.34 made it standard to allow anonymous API requests only on specific endpoints.
- March 2026: the Ingress NGINX retirement took effect, four months after it was announced.
- April 2026: user namespaces reached general availability in v1.36.
The worst Kubernetes security vulnerabilities came from an add-on, not from Kubernetes itself, and one k8s vulnerability there could take over whole clusters.
Most Kubernetes security issues still start with settings, though. In Red Hat’s 2026 State of Cloud-Native Security report, 97% of organizations had a cloud-native security incident in the past year, and 78% reported incidents involving misconfigurations. Those Kubernetes security risks cost time too: 74% delayed or slowed releases.
How Do You Secure the Control Plane?
Securing Kubernetes starts with the API server, because every change goes through it. Kubernetes cluster security depends on four controls here.
1. Keep the API Server Off the Public Internet
How long does an exposed cluster go unnoticed? Wiz’s 2025 research saw malicious probing start within 18 minutes.
To secure a Kubernetes cluster, turn off public endpoint access or limit it to listed IP ranges; EKS, AKS, and GKE all offer private endpoints. On self-managed clusters, allow anonymous requests only on health-check paths such as /healthz.
2. Apply Least-Privilege RBAC
A pipeline needs to update one app, so someone binds its service account to cluster-admin. Months later, a leaked CI token hands over the whole cluster.
Grant namespaced Roles instead, never use * for verbs or resources, and review access with:
kubectl auth can-i --list --as=system:serviceaccount:ci:deployer3. Encrypt Secrets and etcd at Rest
Kubernetes Secrets are only base64-encoded by default, so anyone who reads etcd or its backups reads every password. Turn on encryption with a KMS v2 provider, or your managed service’s own-key option.
Keep the most sensitive values in AWS Secrets Manager, Azure Key Vault or HashiCorp Vault, synced in by the External Secrets Operator.
4. Turn On Audit Logging
Write an audit policy before you need it. Log Secret access at the Metadata level, which records who read a value without storing it, and log every pods/exec call.
Ship the logs outside the cluster, on EKS, they reach CloudWatch only after you enable that log type. When you’re working out how to secure a Kubernetes cluster after an incident, these logs are often the only record.
How Do You Harden Worker Nodes?
Worker nodes run your containers, so one weak node exposes every pod on it.
5. Stay on a Supported Kubernetes Version
Kubernetes patches only its three newest minor versions, each for about 14 months, so a cluster that skips upgrades loses security fixes within about a year.
EKS adds a cost push: extended support runs $0.60 per cluster per hour instead of $0.10. Schedule each upgrade at least two months before end of support.
6. Use a Minimal OS and Check It Against the CIS Benchmark
Container-focused systems such as Bottlerocket, Container-Optimized OS and Azure Linux drop the packages a node never uses, and the first two keep the root filesystem read-only.
Measure Kubernetes node security against the CIS Kubernetes Benchmark with kube-bench, and replace SSH with session tools such as AWS Systems Manager.
How Do You Secure Pods and Workloads?
Kubernetes container security comes down to what each pod can do once it starts. These settings limit how far an attacker gets after breaking into one container.
7. Enforce Pod Security Standards
PodSecurityPolicy was removed in v1.25. Its built-in replacement, Pod Security Admission, applies three Pod Security Standards (privileged, baseline and restricted) through namespace labels. Start in warning mode so nothing breaks:
kubectl label namespace payments pod-security.kubernetes.io/warn=restrictedFix whatever triggers warnings, then switch warn to enforce.
8. Set a Strict Security Context
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
seccompProfile:
type: RuntimeDefaultThese lines cover most Kubernetes security context best practices: no root, no privilege escalation, no extra Linux capabilities and filtered system calls. The restricted standard doesn’t require a read-only filesystem, but it stops intruders from saving tools.
9. Isolate Pods With User Namespaces
Set hostUsers: false, and root inside the container maps to an unprivileged user on the node, so a container escape no longer means root on the host. The feature is Linux-only and needs a recent kernel and runtime, so test it on one node pool first.
10. Stop Auto-Mounting Service Account Tokens
Every pod gets an API token unless you say otherwise, and most apps never use it. Setting automountServiceAccountToken: false is one of the simplest container security wins in Kubernetes. Pods that need the API already get short-lived tokens; pair them with a narrow Role from Practice 2.
How Do You Lock Down Cluster Networking?
Network controls decide how far an attacker moves after one pod falls, and what reaches the cluster from outside.
11. Start With a Default-Deny Network Policy
Kubernetes lets every pod talk to every other pod by default. Good k8s network security flips that:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: payments
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Then allow each real connection, including DNS on port 53. One catch: your network plugin (CNI) must enforce policies. Calico and Cilium do; the EKS VPC CNI does only once enabled. Without enforcement, network security for Kubernetes exists only on paper.
12. Replace Ingress NGINX Before It Becomes a Liability
IngressNightmare showed that one flaw in Ingress NGINX’s admission webhook could expose Secrets in every namespace. Check whether you run it:
kubectl get ingressclass -o custom-columns=NAME:.metadata.name,CONTROLLER:.spec.controllerA k8s.io/ingress-nginx controller means you’re affected. F5’s NGINX Ingress Controller is a separate, maintained product. Plan a move to Gateway API, and until then let only the API server reach the webhook.
How Do You Secure the Software Supply Chain?
Most of what runs in your cluster was built by someone else, so check it before it ships.
13. Scan Images and Block Critical CVEs in CI
Start with distroless or minimal base images, then make scanning a gate: fail the build on any critical CVE that has a fix, for example with Trivy’s --exit-code 1 option. Deploy by digest (@sha256:…) instead of mutable tags.
Those habits cover most of Kubernetes image security and block the poisoned-package path from our cloud security risks guide.
14. Sign Images and Verify Signatures at Admission
Only about half of organizations sign their container images, according to Red Hat. Sign in CI with Sigstore’s cosign, using keyless signing so there’s no private key to leak.
Then let the Sigstore policy-controller or Kyverno reject unsigned images at admission, so Kubernetes application security rests on a verifiable chain from commit to pod.
How Do You Catch Attacks While They Happen?
Prevention eventually fails, so the last practice makes sure you notice in minutes.
15. Add Runtime Detection
Scans see what a workload should be, not what it’s doing. eBPF-based tools such as Falco watch system calls and alert on a web server spawning a shell, traffic to a crypto-mining pool or an unexpected read of the token file. Alert on kubectl exec into production too.
Add Kubernetes security automation for clear cases, such as isolating a pod with a network policy. A CNAPP puts runtime alerts and cluster posture in one place.
What Should a Kubernetes Security Checklist Include?
A useful Kubernetes security best practices checklist pairs each control with proof that it works. Run it as a quarterly Kubernetes security assessment and after every upgrade. Our one-page version lists all 15 practices with a way to check each: 13 read-only commands, plus two safe tests for signing and runtime alerts, a simple form of Kubernetes security testing.
[Download the Kubernetes security best practices PDF]
For continuous checks, a Kubernetes security posture management (KSPM) tool maps findings to Kubernetes compliance frameworks such as the CIS Benchmark. KSPM is the Kubernetes branch of cloud security posture management.
FAQ’s
What's the difference between Kubernetes security and container security?
Scope. Container security covers one container’s image, vulnerabilities and runtime behavior, wherever it runs. Kubernetes security adds the orchestration layer: the API server, RBAC, scheduling, network policies and how teams share one cluster.
Is Kubernetes secure by default?
No. Several defaults favor convenience over safety, including open pod-to-pod traffic, root containers and auto-mounted tokens. Practices 7, 10 and 11 fix them, and most k8s security best practices here apply on managed clusters too.
Which compliance frameworks apply to Kubernetes?
The CIS Kubernetes Benchmark (with EKS, AKS and GKE versions), the NSA/CISA Kubernetes Hardening Guide (August 2022) and NIST SP 800-190, NIST’s application container security guide. SOC 2 and PCI DSS auditors usually accept evidence mapped to them, which simplifies Kubernetes security compliance.
Do you need a service mesh for Kubernetes security?
Not to start with. A service mesh such as Istio or Linkerd adds mutual TLS between services and fine-grained traffic rules, but it also adds real operational overhead.
Most clusters get more protection, sooner, from default-deny network policies and tight RBAC. Add a mesh when compliance requires encrypted service-to-service traffic, or when your microservices need a verified identity on every request.
Which tools help put these practices in place?
Most of these practices can start with free tools: Trivy for image scanning, kube-bench for CIS checks, Kyverno for admission policies and Falco for runtime alerts. Our guide to Kubernetes security tools compares 14 free and paid options, including the outdated ones to avoid in 2026.
