Kubernetes Security Checklist: Best Practices for 2026

Kubernetes security is the work of making sure one compromised pod, token or setting cannot become the whole cluster, or the cloud account the cluster runs in. In practice that means least-privilege RBAC, Pod Security Standards enforced on every namespace, encrypted and tightly scoped Secrets, default-deny network policies, a private API server, a separate cloud identity per workload, and audit logs someone reads. The checklist below groups those Kubernetes security best practices by area, with how to verify each and the OWASP Kubernetes Top 10 (2025) risk it closes, current to Kubernetes 1.37 as of November 2026.

It builds on the official Kubernetes security checklist, the NSA and CISA Kubernetes Hardening Guidance and the CIS Kubernetes Benchmark, and adds the common defaults, what managed providers leave to you, the components retired in 2026, and detection signals. To prove the checklist holds, a Kubernetes penetration test attacks one cluster from a single compromised pod, from $6,800 with a free retest; the cloud penetration testing cost guide shows how a cluster is priced with the account behind it.

Why Kubernetes clusters get breached: the defaults

Most Kubernetes compromises need no zero-day, just defaults nobody changed and permissions granted to make something work. In Red Hat’s 2024 survey of 600 DevOps, engineering and security professionals, nearly 9 in 10 organizations reported at least one container or Kubernetes security incident in the previous 12 months, 40% had detected misconfigurations, and 46% said an incident cost them revenue or customers. These defaults sit behind many findings:

Default	Why it matters
Secrets are stored unencrypted in etcd, and anyone who can create a pod in a namespace can read its Secrets (Kubernetes docs)	Etcd access, a backup or a Deployment permission exposes credentials
Pods get their service account token mounted automatically	One code-execution bug hands over an API credential
With no NetworkPolicy, every pod can reach every other pod	One foothold reaches databases and internal admin APIs
When started without a kubelet config file, the kubelet treats unauthenticated requests as anonymous and authorizes everything	On a self-managed node, the kubelet API can run commands in pods
New EKS clusters get an API endpoint that is public to the internet (AWS docs)	The control plane is one stolen credential from the internet
The API server writes no audit log without a policy, and EKS ships no control plane logs until you enable them	No record of who read a Secret or created a binding

If you fix nothing else: close the API endpoint, find every path to cluster-admin, enforce Pod Security baseline everywhere, block pods from the cloud metadata service, and turn on audit logs.

The Kubernetes security checklist: best practices by area

Each table gives the check, how to confirm it holds, and the OWASP Kubernetes Top 10 (2025) risk it addresses.

1. Versions and retired components

Check	How to verify	OWASP
A supported minor version: the project maintains 1.35, 1.36 and 1.37, and 1.34 reached end of life on October 27, 2026 (Kubernetes releases); nodes patched on a schedule	Versions against the release page or provider calendar	K07
No retired or deprecated components: the community Ingress NGINX controller, the Kubernetes Dashboard, KMS v1 encryption (deprecated since 1.28), or PodSecurityPolicy (removed in 1.25) with nothing in its place	Search running images and stored manifests	K07
Every add-on has an owner and a patch path: ingress controllers, CNI, CSI drivers, operators, mesh, policy engines	Add-on inventory matched to upstream advisories	K07

Ingress NGINX shows why. In March 2025, CVE-2025-1974 (CVSS 9.8) let anything on the pod network reach the controller’s admission webhook and, chained with related flaws, take over the cluster, because by default the controller can read every Secret. The community project (not F5’s NGINX Ingress Controller) was retired in March 2026; its steering and security committees warned that existing installs keep running unpatched and urged migration to Gateway API or a maintained ingress controller. The Kubernetes Dashboard repository was archived in January 2026, with users pointed to Headlamp. Both still turn up in clusters.

2. API server, authentication and control plane

Check	How to verify	OWASP
The API server is private, or reachable only from known address ranges	External scan; provider endpoint settings	K06
People sign in through SSO with MFA, not shared kubeconfigs or long-lived client certificates	Inventory of issued kubeconfigs and certificates	K09
The system:masters group is unused after bootstrap (it bypasses RBAC), and anonymous users can reach only health endpoints	Certificates granting the group; bindings to system:anonymous	K09
Kubelet anonymous auth off, Webhook authorization on, read-only port disabled	An unauthenticated kubelet request is refused	K06
etcd reachable only from the API server, with client certificate auth (self-managed)	Network path from pods and nodes to etcd	K06
The NodeRestriction admission plugin is on, so a kubelet can change only its own node and pods	API server admission settings	K02

3. RBAC and service accounts

Check	How to verify	OWASP
Few cluster-admin bindings, each justified, and no wildcard verbs or resources in custom roles	Bindings to cluster-admin; roles containing wildcards	K02
Escalation rights limited to platform admins: escalate, bind, impersonate, create on serviceaccounts/token, CSR approval, webhook configurations, patch on namespaces	Access review per verb across every identity	K02
get on nodes/proxy is treated as command execution in every pod on that node, and list or watch on Secrets as reading them	Who holds nodes/proxy and Secret access	K02
Rights to create pods or workloads are treated as rights to read that namespace’s Secrets	Who can create Deployments, Jobs and CronJobs	K02
Each workload runs as its own service account, with no legacy non-expiring token Secrets	Pods using default; token-type Secrets	K02
automountServiceAccountToken is false wherever a pod never calls the API	Pod specs and mounted token volumes	K02

The official checklist allows up to 24 months between access reviews. Review privileged bindings quarterly, and remove bindings for departed users, since a reused username inherits them.

4. Workloads and Pod Security

Check	How to verify	OWASP
Every namespace has Pod Security Admission labels: enforce baseline at minimum, restricted for applications, audit and warn at restricted	Namespace labels; a test privileged pod is rejected	K04
Containers run as non-root, with privilege escalation off, all capabilities dropped and a RuntimeDefault or custom seccomp profile	Pod security contexts	K01
No privileged containers, host PID, host IPC, host network or hostPath outside named system namespaces	Workloads filtered on those fields	K01
Workloads that need root use user namespaces (stable since 1.36), so container root maps to an unprivileged host user	Pod specs; node kernel support	K01
Admission rules cover what Pod Security cannot, through ValidatingAdmissionPolicy (stable since 1.30), Kyverno or OPA Gatekeeper	A non-compliant test deployment is rejected	K04
Memory requests and limits on every workload, and a ResourceQuota per namespace	Workload specs and quotas	K01
Sensitive workloads isolated on dedicated node pools or sandboxed runtimes	Taints, node selectors, RuntimeClass	K01

5. Secrets

Check	How to verify	OWASP
Encryption at rest with a KMS v2 provider (stable since 1.29; KMS v1 is off by default from 1.29)	Encryption configuration or provider setting	K03
No credentials in ConfigMaps, container images, manifests, Helm values or git history	Secret scanning of repositories and image layers	K03
High-value credentials kept in an external secret manager, delivered by the Secrets Store CSI driver or a sync operator	Where each credential lives	K03
etcd backups encrypted and access-controlled like etcd itself	Backup location and permissions	K03

6. Network

Check	How to verify	OWASP
The CNI enforces NetworkPolicy, and every namespace has default-deny ingress and egress with explicit allows	Cross-namespace test traffic is blocked	K05
Pods cannot reach the cloud metadata service; on EKS, IMDSv2 with a hop limit of 1 and no host networking for untrusted pods	A metadata request from a test pod fails	K08
Admission webhooks and controller admin ports accept traffic only from the API server	Policies on webhook services	K05
LoadBalancer services, NodePorts, ingresses and external IPs are inventoried, and DenyServiceExternalIPs is on	Exposed services; admission settings	K06

7. Cluster-to-cloud identity

Check	How to verify	OWASP
Each workload that calls cloud APIs has its own scoped identity: EKS Pod Identity or IRSA, Microsoft Entra Workload ID on AKS, Workload Identity Federation for GKE	Service account to cloud role mapping	K08
The node role holds only what nodes need, and pods cannot inherit it	Node role policy plus the metadata test	K08
Cloud principals mapped into the cluster (EKS access entries or the older aws-auth ConfigMap, Azure RBAC, Google IAM) are reviewed like RBAC	Every mapping traced to a named owner	K02

Deploy pipelines are cluster identities too: see CI/CD pipeline security for runner secrets and OIDC trust, and cloud security best practices for the account side.

8. Images and supply chain

Check	How to verify	OWASP
Minimal base images with no shell or package manager where the app allows	No shell or package manager in the image’s file list	K01
Images scanned at build and in the registry, with fixes ranked by exploitability rather than CVE count	Scanner policy and fix deadlines	K07
Images pulled only from approved registries, by digest or with signatures verified at admission	A test pod from an unapproved registry, or with an unsigned image, is rejected	K04

The 2025 OWASP list has no separate supply chain entry: untrusted registries fall under K04 and unpatched components under K07.

Signature verification usually means Sigstore: cosign attaches the signature to the image and checks that the signed digest matches it, and an admission policy refuses images that fail. The SLSA build levels grade how the image was built: Level 1 means provenance exists, Level 2 that a hosted build platform signed it, Level 3 that the platform is hardened against tampering. Both belong in the build stage of a secure SDLC.

9. Logging, detection and response

Check	How to verify	OWASP
API audit logging records Secret reads (at Metadata level, never the value), RBAC changes, exec and workload changes	Audit policy or provider log settings	K10
Audit logs shipped off-cluster, retained, and readable only by the security team	Log destination permissions	K10
Runtime detection flags shells in containers, unexpected processes and token file reads (Falco or a commercial sensor)	A benign test alert fires and reaches someone	K10
A rehearsed procedure to rotate a leaked token, kubeconfig or cloud key and to isolate a node	Date of the last exercise	K10

Managed Kubernetes: what EKS, AKS and GKE leave to you

Providers run the control plane. Almost everything an attacker uses after the first foothold is still yours.

Layer	Self-managed	EKS, AKS, GKE
API server, etcd, scheduler, controller manager	You	Provider
API endpoint exposure	You	You
Encryption of API data at rest	You	Provider (EKS envelope encrypts all API data by default); your own key is optional
Node OS, kubelet settings, patching	You	You, unless the provider runs the nodes (GKE Autopilot, EKS Auto Mode, AKS Automatic)
RBAC, Pod Security, network policy, Secrets, images, workload identity	You	You
Audit logs enabled, exported and watched	You	You

Our AWS, Azure and GCP testing guides cover the account around the cluster.

Multi-tenant Kubernetes: choosing an isolation model

When teams or customers share a cluster, the isolation model decides how much a single mistake costs. The Kubernetes multi-tenancy documentation describes a spectrum:

Model	What tenants share	What it leaves you to solve
Namespace per tenant	API server, nodes, cluster-wide resources	RBAC, quotas and default-deny network policy per namespace; CRDs, storage classes and webhooks stay shared
Virtual control plane per tenant	Nodes and the data plane	Node-level threats and noisy neighbors, which per-tenant control planes do not solve
Dedicated nodes or sandboxed runtimes, added to either	Kubelet and, without virtual control planes, the API server	A container escape reaches only that tenant’s node; sandboxing is the documented choice for untrusted code
Cluster per tenant	Nothing inside Kubernetes	The cost of running many clusters

Tenants who do not trust each other need more than namespaces. On a test, we start in one tenant’s pod and try to reach another’s Secrets, pods and nodes.

GitOps controllers are cluster-admin by another name

A GitOps controller such as Argo CD holds the rights to deploy everything, so it belongs in the RBAC review. Argo CD’s security documentation says it uses a cluster-admin level role by default, stores each external cluster’s credentials as a Secret in the argocd namespace, and does not need full write access. Limit its writes to the namespaces it manages, restrict who can read Secrets in its namespace, and protect the git repository like production: whoever can merge there can deploy.

Common Kubernetes attacks and how to detect them

Each attack with its MITRE ATT&CK IDs, the signal that should fire, and the control that stops it:

Attack	ATT&CK	Signal to alert on	What stops it
Entry through an exposed API server, kubelet or dashboard	T1133, T1190	Audit events from system:anonymous; API calls from unknown addresses	Private endpoint, kubelet authentication
Running commands in an existing pod	T1609	Pod exec, attach or portforward by an unusual identity; any nodes/proxy use (it bypasses pod exec logging)	Restrict pods/exec and nodes/proxy
Deploying a privileged pod to escape to the node, a privilege escalation from container to host	T1610, T1611	Pod Security audit annotations; pods created with privileged, host PID or hostPath	Pod Security enforce mode
Stealing a service account token or Secrets	T1528, T1552.007	Secret reads by an identity that never reads them; token requests for other service accounts	Automount off, least-privilege RBAC
Persisting through a new role binding	T1098.006	Role binding changes outside the deploy pipeline; audit events carrying an impersonated user	Restrict bind, escalate, impersonate
Persisting through a CronJob or DaemonSet	T1053.007, T1610	New CronJobs or DaemonSets in kube-system or created by a person	Admission policy, RBAC
Pivoting from a pod to the cloud account	T1552.005	Node role credentials used away from the node (Amazon GuardDuty flags this); pod connections to the metadata address	Metadata blocked, workload identity
Mining cryptocurrency on your nodes	T1496.001	Sustained CPU saturation; images from unknown registries; egress to mining pools	Registry allow-list, quotas, egress policy

If a tester execs into pods, mints tokens and binds cluster-admin and nobody is paged, that silence is a finding in its own right.

How Invadel tests Kubernetes security, and what it costs

Scanners such as kube-bench (CIS Benchmark), Kubescape and Trivy (manifests and live clusters) flag deviations and belong in every pipeline and on a schedule, but they cannot prove a chain: that create on pods in one namespace yields a token that reaches cluster-admin, or that a “low risk” pod reaches the node role and then a storage bucket, as our cloud application security guide shows for workloads.

A Kubernetes penetration test finds them from an assumed breach in one pod. Senior in-house testers benchmark the cluster against CIS and the NSA and CISA guidance, then attack RBAC, escape to the node, read Secrets, move between namespaces and pivot into the cloud account. Findings map to the OWASP Kubernetes Top 10, ranked by the attack paths each fix breaks.

What you need	Engagement	From
One cluster (EKS, AKS, GKE or self-managed) attacked from a compromised pod	Kubernetes penetration test	$6,800
The cluster plus several cloud accounts on one provider, in one report	Cloud penetration test, Medium tier	$10,500
One cloud account reviewed read-only against CIS, no exploitation	Cloud security assessment	$4,200
Manifests, Helm charts and infrastructure-as-code	Secure code review	$4,800
The APIs your cluster exposes	API penetration test	$4,000

Every penetration test includes executive and technical reports, an attestation letter for SOC 2, ISO 27001 or PCI DSS evidence, the findings platform and a free retest of everything you fix. Onboarding begins within 24 hours of a signed proposal. The scoping questionnaire returns a written fixed price the same day; see also the sample report, pricing page and cost calculator.

Frequently asked questions

What is Kubernetes security? The controls that stop one compromised workload, credential or setting from spreading across a cluster: RBAC, Pod Security, Secret protection, network policy, cloud workload identity, and audit logging with runtime detection.

What are the 4 C’s of Kubernetes security? Cloud, cluster, container and code: an older layered model from the Kubernetes documentation, where each layer depends on the one outside it. The current Kubernetes security overview is organized by lifecycle phase instead (develop, distribute, deploy, runtime), which leads to the same controls.

Is EKS, AKS or GKE secure by default? The provider secures the control plane, but RBAC, Pod Security, network policy, Secrets, workload identity and audit logging stay with you. New EKS clusters get a public API endpoint and no control plane logs until you change both.

How often should a Kubernetes cluster be penetration tested? At least annually and after significant changes such as a new cluster, ingress or identity model, or a major upgrade, with continuous benchmark scans in between. Our guide on how often to test gives the reasoning.

Which tools check a cluster against the CIS Kubernetes Benchmark? kube-bench, an open source tool from Aqua Security, runs the benchmark’s checks on a node and ships job definitions for EKS, GKE and AKS. Kubescape and Trivy, named above, scan live clusters and manifests. On a managed service, use the matching benchmark: CIS publishes separate ones for EKS, AKS and GKE, including EKS Auto Mode, AKS Automatic and GKE Autopilot.

What is the difference between a Kubernetes penetration test and a benchmark scan? A benchmark scan compares each setting with a recommended value and lists the deviations. A penetration test starts from a foothold, usually one compromised pod, and shows which deviations chain into cluster-admin, another namespace’s Secrets or the cloud account. Run the scan continuously and the test at least annually.

How do you secure a Kubernetes cluster? Make the API endpoint private, remove every path to cluster-admin, enforce Pod Security baseline on every namespace, block pods from the cloud metadata service, and turn on audit logging. Then work through the checklist above.

The short version

Kubernetes is insecure by default in specific places: unencrypted Secrets, mounted tokens, flat networking, permissive kubelets, public endpoints and missing audit logs. Fix those, lock down the RBAC escalation verbs, enforce Pod Security, cut the path from pods to the cloud, and retire what the project no longer patches. Then test whether it holds: a Kubernetes penetration test starts at $6,800 (see cloud penetration testing cost), and you can scope your cluster for a written fixed price the same day.