Skip to content
Invadel

Cloud

Kubernetes
Penetration Testing

EKS, AKS, GKE, and self-managed cluster testing

One cluster from $6,800, fixed scope, free retest. See all pricing →

Get a fixed quote

Reply in one business day

Full scoping questionnaire 
Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When a Kubernetes cluster needs testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • You run microservices on EKS, AKS, GKE, or a self-managed cluster and no outsider has attacked the cluster itself, only the applications on it.
  • An enterprise customer or a cyber insurer asked specifically how the cluster is secured, and a passing CIS scan did not answer it.
  • You granted broad RBAC or cloud permissions to a service account to make something work, and nobody has traced where that access reaches.
  • The cluster sits inside your SOC 2 or ISO 27001 scope and the auditor expects application-layer evidence beyond the cloud account.
  • You want the container platform tested alongside the cloud account it runs in, so the report tells one story from a pod to the control plane.

Definition

What is Kubernetes penetration testing?

Kubernetes penetration testing is a manual attack on the cluster itself, not the applications running on it. It starts from a realistic foothold, usually code execution in one pod, and works out how far that reaches: through RBAC and service-account permissions, through workload settings that break the container boundary, through secrets that should not be readable, and through the identity the cluster holds in the cloud account behind it. The point is to prove the paths a real attacker would follow, from one pod to the control plane and beyond.

One cluster, whether EKS, AKS, GKE, or self-managed, starts at $6,800, the same as the cloud penetration testing Small tier. When you want the cluster tested alongside the account it runs in, our cloud penetration testing covers the AWS, Azure, or GCP identities and services around it, and the two are scoped together.

What we look for

Kubernetes vulnerabilities we hunt for

A cluster concentrates every workload behind one API and one set of identities. The findings that matter are the ones that let a single compromised pod, service account, or misconfiguration reach the node, the control plane, or the cloud account behind it. We test to the OWASP Kubernetes Top Ten.

RBAC and authorization

The permissions that decide what every user and workload can do, where an over-granted role turns a foothold into cluster-admin.

We test for

  • Over-permissive roles, cluster roles, and bindings
  • Service accounts with more access than the workload needs
  • Escalation through create, escalate, bind, and impersonate verbs
  • Wildcard resource and verb grants
  • Default service-account tokens mounted where they should not be

Workload configuration

The pod settings that break the boundary between a container and the node it runs on.

We test for

  • Privileged containers and dangerous Linux capabilities
  • hostPath, host network, host PID, and host IPC
  • Containers running as root without a restricted security context
  • Pod Security Standards coverage (Baseline and Restricted)
  • Missing admission control and policy enforcement

Secrets management

Where the cluster keeps its secrets, and who can read them. By default, Kubernetes Secrets are stored unencrypted in etcd.

We test for

  • Secrets readable by anyone who can create a pod in the namespace
  • Encryption at rest for etcd and Secret objects
  • Secrets in environment variables, images, and manifests
  • External secret-store integration and scoping
  • Token and kubeconfig exposure on nodes and in pods

Exposed components

The control-plane and node components that should never be reachable, and the defaults that leave them open on self-managed clusters.

We test for

  • API server exposure and anonymous access
  • kubelet read and write ports (anonymous auth and AlwaysAllow on unhardened clusters)
  • etcd reachable without authentication
  • Exposed dashboards, metrics, and debugging endpoints
  • Ingress and load-balancer exposure of internal services

Pod escape and lateral movement

The path a real attacker takes: from code execution in one pod, to the node, to the rest of the cluster.

We test for

  • Container escape through privileged settings and host mounts
  • Node compromise and access to other pods on the node
  • Lateral movement between namespaces and workloads
  • Network policy gaps that leave pods flat
  • Access to the kubelet and node credentials

Cluster-to-cloud pivot

The bridge from the cluster to the AWS, Azure, or GCP account behind it, where a pod inherits an identity it should never hold.

We test for

  • Node instance-profile and metadata-service abuse (IMDS)
  • EKS Pod Identity and IAM roles for service accounts (IRSA) scope
  • Microsoft Entra Workload ID and Workload Identity Federation for GKE
  • Over-privileged workload identities reaching cloud resources
  • The path from a pod to control of the cloud account

Beyond a scanner

Why a passing CIS scan is not a penetration test

A Kubernetes benchmark scan reads the cluster configuration and flags deviations from the CIS Kubernetes Benchmark, which is fast and useful. What it cannot do is prove exploitation: whether an over-granted service account actually escalates to cluster-admin, whether a privileged pod really escapes to the node, or whether a workload identity lets a compromised pod reach the cloud account. Those take a tester chaining the findings by hand.

This engagement does the manual work a scan cannot. We benchmark the cluster against CIS and the NSA and CISA Kubernetes Hardening Guidance as the starting point, then attack from an assumed-breach position in a workload and prove the routes to the control plane and the cloud. The result is a ranked set of exploitation chains, not a list of settings to double-check.

Managed clusters

EKS, AKS, GKE, and self-managed

The managed providers harden the control plane you cannot see, so the test concentrates on what you own: the workloads, the RBAC, and the identity that bridges to the cloud.

Amazon EKS

RBAC and the access entries or older aws-auth ConfigMap that map IAM principals into the cluster, node instance-profile and IMDS exposure, and the reach of EKS Pod Identity or IAM roles for service accounts (IRSA) into the AWS account. AWS’s customer-testing policy does not list EKS among the pre-approved services, so we keep testing to your own workloads and cluster resources and confirm the current policy during scoping.

Azure AKS and GKE

On AKS, Azure RBAC and Kubernetes RBAC, and the reach of Microsoft Entra Workload ID. On GKE, cluster RBAC and Workload Identity Federation for GKE, plus the metadata-server exposure that workload identity is meant to close. Both are tested within the provider’s customer rules for your own resources.

Self-managed

A cluster you run on your own VMs or hardware exposes the control plane too: the API server, etcd, and the kubelet, whose defaults (anonymous authentication and AlwaysAllow authorization) are open until hardened. Self-managed clusters get the widest scope, because you own every layer.

Whichever you run, the container images and the pipeline that builds them are a related surface; our guide to CI/CD pipeline security covers that side. A secure code review covers the manifests and infrastructure-as-code, and the API test covers the services the cluster exposes.

Methodology

Kubernetes penetration testing methodology

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your Kubernetes penetration testing runs through.

  1. 01

    Scope & access

    One cluster, the provider or distribution, and the credential level we start from, with the fixed price agreed in writing.

  2. 02

    Enumerate & benchmark

    RBAC, workloads, secrets, and components mapped and benchmarked against the CIS Kubernetes Benchmark and the NSA and CISA hardening guidance.

  3. 03

    Exploit from a pod

    An assumed-breach start from a workload, chaining RBAC, configuration, and escape paths the way an attacker would.

  4. 04

    Pivot to node and cloud

    Movement to the node, across the cluster, and toward the cloud account behind it, proven end to end.

  5. 05

    Report & retest

    Exploitation chains mapped to the OWASP Kubernetes Top Ten, fixes ranked by paths broken, and a free retest.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Scope & kickoff

    Targets, roles, and rules of engagement defined in writing, with a fixed scope and timeline.

  2. 02

    Testing goes live

    Findings post to your live platform dashboard the moment our testers confirm them.

  3. 03

    Track remediation

    Follow every finding from open to fixed, with severity, evidence, and status in one place.

  4. 04

    Report & retest

    Executive and technical reports land, then request a free retest in one click.

Compliance

Frameworks a Kubernetes test supports

A cluster hosts the workloads your customers and auditors care about, so its testing evidences the application and infrastructure controls in every framework.

SOC 2Evidence for CC6.1, CC6.6, and CC7.1 across the cluster and the workloads inside your audit boundary.ISO 27001Annex A 8.8 technical vulnerability management and A 8.9 configuration management evidence for the container platform.PCI DSSRequirement 11.4 testing and segmentation evidence where cardholder data workloads run in the cluster.HIPAATechnical safeguard evidence for ePHI processed in containerized workloads.
Common inSaaS & SoftwareAll industries

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

Fintech · Payments

Web Application Penetration Test

High risk

Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.

Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.

1

Critical (RCE)

Mid-test

Critical remediated

2

High

Read the case study

HR & Payroll SaaS

Web Application Penetration Test

High risk

Critical: a file-inclusion flaw that let an attacker read sensitive files from the server through the application itself. High: stored cross-site scripting capable of session theft, insecure direct object references, and an authorization bypass that let an administrator create or delete organization owners.

Outcome. Delivered a remediation plan sequenced by real business impact, critical and high findings first, with a complimentary retest to verify every fix.

28

Findings

1

Critical

5

High

Read the case study
LatentPerygeeCity National BankAubaDesteiaDTCC
Request a reference 

Resources

Field notes from the offensive side

All articles →

AWS Penetration Testing: Rules, Scope, Attack Paths and How to Prepare

AWS penetration testing explained: what AWS allows without approval, what is prohibited, the IAM, S3, Lambda and IMDS attack paths, and how to scope a test.

GCP Penetration Testing: Google's Rules and Real Attack Paths

GCP penetration testing guide: Google's testing policy, IAM and service-account attack paths, the metadata server, GKE workload identity, and scoping.

Cloud Security Best Practices

The cloud security best practices that actually prevent breaches: identity, data protection, configuration, monitoring, and testing, in priority order.

Want to see a report first?

Read a sample report for a fictional client, or request a redacted one from a real engagement. Our guide explains what a penetration testing report should contain.

See the sample report

FAQ

Frequently asked questions

What teams most often ask before scoping Kubernetes penetration testing.

Still have questions? 
01What does a Kubernetes penetration test cover?

The cluster itself: RBAC and service-account permissions and the paths they escalate; workload configuration such as privileged pods, host mounts, and capabilities; secrets handling in etcd, environment variables, and images; exposed components such as the API server, kubelet, etcd, and dashboards; container escape and lateral movement to the node and across namespaces; and the pivot from a compromised pod to the cloud account behind it. We test to the OWASP Kubernetes Top Ten and benchmark against the CIS Kubernetes Benchmark.

02Do you test EKS, AKS, and GKE, or only self-managed clusters?

All of them. On managed clusters (EKS, AKS, GKE) the provider hardens the control plane you cannot reach, so the test concentrates on what you own: the workloads, the RBAC, and the workload identity that bridges to the cloud, such as EKS Pod Identity or IRSA, Microsoft Entra Workload ID, and Workload Identity Federation for GKE. Self-managed clusters get the widest scope, including the API server, etcd, and the kubelet, because you own every layer.

03How is this different from a cloud penetration test?

A cloud penetration test attacks the AWS, Azure, or GCP account: the identities, storage, network, and services. A Kubernetes test attacks the cluster on top of it: RBAC, workloads, secrets, and pod escape, then the pivot back into the cloud account. They overlap at that bridge, which is why we often scope them together so the report tells one story from a pod to control of the account. One cluster is $6,800, the cloud Small tier.

04Do you need cluster-admin to run the test?

No, the opposite. The most useful engagement starts from what an attacker would have: code execution in one pod, or a low-privileged service-account token, and proves how far it reaches. We agree the starting point during scoping. For the configuration side we can also review the cluster with a read-only role, but the value is in the assumed-breach exploitation, not a settings export.

05Will testing disrupt the cluster or the workloads?

No. Testing runs under written rules of engagement, in a non-production or staging cluster where one exists, and there is no denial-of-service testing. Where production is the only option, we agree the boundaries in writing, avoid anything destructive, and escalate a confirmed critical finding the moment we prove it rather than waiting for the report.

06How much does Kubernetes penetration testing cost?

One cluster, EKS, AKS, GKE, or self-managed, starts at $6,800, fixed before work begins, with a free retest. Several clusters, a very large cluster, or the surrounding cloud account tested in depth alongside it are quoted from the scope. A common first engagement is one cluster plus the cloud account it runs in, scoped together. Starting prices for every service are on our pricing page.

07Do we need AWS, Azure, or Google approval?

You can test your own workloads and cluster resources on all three within their customer-testing rules. Amazon EKS is not on AWS’s list of services you can test without prior approval, so on EKS we keep testing to your own workloads, node configuration, and cluster resources rather than the managed control plane, and confirm the current policy during scoping. On Azure and Google Cloud the work stays within each provider’s rules for testing your own resources.

Ready to test your defenses?

Talk to our team about scoping Kubernetes penetration testing.

Prefer the full scoping questionnaire? 
RelatedCloud Cloud Assessment API Secure Code Review

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.