Blog

Kubernetes security testing checks whether a cluster's controls hold up under an attacker's logic, not just whether they exist on paper. There are five misconfiguration categories our testers find most often.
1) RBAC gaps granting too much access.
2) Exposed control-plane components.
3) Missing network policies.
4) Unsafe pod defaults.
5) Weak admission control.
Pentesters chain them into the attack path they open once RBAC, network policy, and pod security interact.

A Kubernetes cluster can pass a compliance scan and still hand an attacker a working path to a Secret. That gap isn't rare. Most of the controls that keep a cluster safe depend on each other, and a weakness in one cancels out the strength of another.

Testing a cluster properly means tracing those dependencies the way an attacker would. It's not enough to check each control in isolation. Our cloud audits cover Kubernetes alongside the wider cloud environment it runs on. We do it because container security rarely stops at the cluster's boundary. 

Five Kubernetes Security Misconfigurations We Keep Finding

Kubernetes security testing keeps turning up the same five gaps. Below, we explain what the setting looks like, how a tester chains it into a working attack path, and what an attacker gains once they're through.

RBAC and Least Privilege

Role-based access control (RBAC) is the primary safeguard for any cluster. It's also the control most likely to be compromised by its defaults. Kubernetes lets you scope permissions tightly, but most deployment tools don't enforce that scoping by default.

Our audit of Kubernetes-based Event Driven Autoscaler (KEDA), the Cloud Native Computing Foundation's (CNCF) event-driven autoscaler, found a clean example of this. Its Helm chart allowed a setting called scaledRefKinds to grant wildcard get access across Application Programming Interface (API) groups and resource types once enabled. The chart's default values left the scope unrestricted. 

KEDA had already built in a way to restrict Secret access. The wildcard permission sat alongside it, undermining the very restriction the project had designed. Nobody had to misuse a feature to trigger this. The default configuration did it on its own.

That's the pattern cloud security should test for. It's not enough to check whether a ClusterRole looks reasonable. 

What matters is what its resolved permissions allow once every default and dependency stack together. Running kubectl get clusterrole -o yaml on every role your tools create is a quick first check. It won't, on its own, catch how those permissions combine with a compromised service account.

Exposed API Server, Dashboard, and Kubelet

The Kubernetes API server, dashboard, and kubelet API all accept commands if you can reach them. That makes exposure the fastest route from outside a cluster to inside it. 

• An API server reachable without authentication is close to an open door to the whole cluster. 

• On a worker node, a kubelet API that’s left open can run commands within any pod on that node.

A vulnerability scanner will usually flag an open port. But it rarely confirms what commands succeed once a tester reaches it without valid credentials. That's the part that decides whether the exposure is a real path or a dead end. 

Cloud security testing means attempting the same calls an attacker would try. They’ll test listing pods, reading Secrets, and executing inside a container, all unauthenticated.

Missing Network Policies

By default, every pod in a Kubernetes cluster can talk to every other pod. Network policies exist to restrict that, but they need to be written and applied on purpose. A cluster with no network policies can give an attacker who compromises a low-value pod access to every other workload on the network.

Service meshes add a layer to test on their terms. Linkerd, for example, is built to enforce mutual Transport Layer Security (TLS) and traffic policy between services. Our audit of Linkerd reviewed its core APIs and proxy for the third time as the project matured. A mesh like this can tighten pod-to-pod trust considerably, but it's not a substitute for native network policies. 

Testing needs to confirm both layers hold up, not assume one covers for the other.

Unsafe Pod Defaults and Privileged Containers

A container running as root, with a privileged security context or a mounted host path, hands an attacker a direct route to the underlying node. That route opens the moment they break out of the application. 

This issue remains one of the most common findings in cluster reviews, mostly because it's set during early development and never revisited.

The National Security Agency's (NSA) and Certified Information Systems Auditor’s (CISA) Kubernetes Hardening Guide recommends running containers as non-root users and applying restrictive security contexts as a baseline, not an advanced control. 

Testing this means checking pod specs for privileged: true, root users, and host path mounts. From there, we confirm what an attacker gains if that specific container is the first one compromised.

Weak or Missing Admission Control

Admission controllers sit at the last checkpoint before a resource gets created in a cluster. A weak or missing one lets risky configurations through, even when every other control is set correctly. Without enforcement here, nothing stops a developer, or an attacker with limited access, from deploying a privileged pod or a role with excess scope.

Testing admission control means trying to create the resources your policies are meant to block. We then confirm they get rejected, rather than assume the policy's active just because it's deployed. 

A policy that exists but isn't enforced offers no more protection than no policy at all.

Get Your Cluster Tested

RBAC, network policy, pod security, and admission control all depend on each other holding up. Our manual testing traces those dependencies end to end. You get a report that shows real attack paths, not a list of settings copied from a checklist.

Talk to Our Kubernetes Testers

Common Questions About Kubernetes Security Testing

Is a CIS Benchmark Scan the Same as a Penetration Test?

No. A Center for Internet Security (CIS) Benchmark scan checks configuration against a published baseline, and it's a useful starting point. It doesn't test whether small, low-risk settings chain into a working attack path. That's what manual pentesting is built to find.

What Is the Most Dangerous Default Kubernetes Misconfiguration?

Wide-open network access between pods tends to cause the most damage, since it turns a single compromised workload into a foothold across the entire cluster. RBAC over-permissioning runs a close second, especially where a Helm chart's default values grant more than the deployment needs.

Can RBAC Alone Protect a Cluster?

No single control protects a cluster on its own. RBAC governs who can do what through the API. It does nothing to stop pod-to-pod traffic or a privileged container breaking out to its node. Kubernetes security depends on RBAC, network policy, pod security, and admission control working together.

How Does Kubernetes Security Testing Differ From a General Cloud Audit?

A cloud security audit looks at the wider environment: identity, storage, and account isolation across the platform a cluster runs on. Kubernetes security testing goes deeper into the cluster itself, tracing how its internal controls interact rather than reviewing them one at a time.

Does Container Security Testing Cover the Images Themselves?

In this context, it doesn’t. Container security in the sense we've covered here is about cluster-level configuration: RBAC, network policy, pod security, and admission control. Reviewing what's inside a container image is a related but separate exercise, usually paired with a code or supply-chain audit.

Validate Your Real-World Attack Paths

Compliance scans confirm that controls exist. They rarely confirm that those controls survive contact with a real attack path. Our testers combine cloud and Kubernetes security testing to trace how cluster-level configurations interact.

Scope Your Kubernetes Assessment

Want to Read More?

• Learn how developers can secure dependency chains and cache mechanisms in our audit findings on Requests, CacheControl, and urllib3.
• Understand the transition process and the risks associated with legacy protocols by reading our guide on NTLM hash security and Kerberos migration.
• Explore our comprehensive code audit services to see how our manual penetration testing process identifies vulnerabilities located in your source code.