A cloud or Kubernetes penetration test scopes the layers you are responsible for in the shared-responsibility model: identity and IAM, storage exposure, network paths, the Kubernetes control plane and its workloads, and the applications and APIs running on top. A web-application penetration test scopes only that last layer. Understanding where those two engagements overlap, and where they do not, is the single most useful thing a buyer can do before requesting a quote, because it determines both what gets tested and what the test costs.
Cloud native infrastructure is now the default, which is why this has become a mainstream purchase rather than a specialist one. In the CNCF 2025 Annual Cloud Native Survey, 82% of container users run Kubernetes in production (up from 66% in 2023) and 98% of surveyed organizations have adopted cloud native techniques. The cost of getting it wrong tracks that footprint: the IBM Cost of a Data Breach 2025 report puts the global average breach at US$4.44M, and breaches involving data spread across multiple environments at US$5.05M, the most expensive class it measures. A cloud environment is exactly that kind of spread-out, multi-service target.
This guide is written for a security buyer scoping their first cloud or Kubernetes pentest. It answers the core question first, then walks the six layers, the Kubernetes-specific scope, the shared-responsibility boundary, the cost drivers, and a scoping checklist. There are no exploit walkthroughs here, only scope-level altitude and defensive framing.
What does a cloud or Kubernetes penetration test cover, and how is it scoped?
A cloud penetration test covers the parts of your cloud environment that you configure and control: your identities and IAM policies, your storage and its exposure, your network paths and segmentation, your Kubernetes control plane and workloads if you run containers, and the applications and APIs deployed on top. It is scoped by the shape of your environment, not by a host count. The unit of scope is the account, subscription, or project, plus the clusters inside them, plus the identity graph that ties them together.
The test is scoped this way because a cloud attacker does not think in hosts. They think in identities and reachability: one compromised credential, one over-permissioned role, one publicly exposed storage bucket, one workload that can reach the control plane. Stolen and compromised credentials remain the number one initial access vector in the Verizon 2025 Data Breach Investigations Report, which is why identity is usually the first layer a cloud pentest interrogates and why a host-count quote misses the point. A good scope names the accounts, the clusters, the crown-jewel data, and the tester's starting assumption, and lets the tester follow the paths between them.
The six layers a cloud penetration test scopes
Most cloud engagements move through six layers. Not every test covers all six, and a good scoping conversation decides which ones are in play.
Identity and IAM. Roles, policies, trust relationships, federation, and service accounts. This is where privilege escalation and lateral movement usually start. Identity attack-path work is deep enough to be its own engagement; our cloud IAM penetration testing guide covers it in detail.
Storage and data exposure. Object storage, databases, snapshots, and backups. The classic failure is a bucket or data store that is reachable by an identity, or by the internet, that should never touch it.
Network and reachability. Security groups, network ACLs, peering, private endpoints, and the paths between public and private subnets. The question is what an attacker can reach once they have a foothold.
Kubernetes control plane. The API server, RBAC, admission control, and cluster configuration. If you run managed Kubernetes, the provider secures the control-plane internals, but you own its configuration.
Workloads and containers. Pod security, container privileges, service accounts, and whether a compromised container can reach the node, the control plane, or cloud credentials.
Applications and APIs. The software running on top: authentication, authorization, business logic, and the data the app exposes. This is the layer a web-app pentest already covers.
Cloud pentest vs web-app pentest: what each one scopes
Buyers frequently ask whether their existing web-application pentest already covers the cloud. It does not, and the gap is not a matter of thoroughness. The two tests model different trust boundaries. A web-app pentest asks whether an attacker can abuse the software you shipped. A cloud pentest asks whether an attacker who lands anywhere in your environment can move through identities, storage, network, and clusters to reach something that matters.
Dimension | Web-app penetration test | Cloud and Kubernetes penetration test |
|---|---|---|
Unit of scope | An application at its trust boundary | Accounts, subscriptions, clusters, and the identity graph |
Primary question | Can an attacker abuse this application? | How far can an attacker move once inside the environment? |
Identity and IAM | Application roles and sessions only | Full cloud IAM: roles, trust policies, federation, service accounts |
Storage | What the app reads and writes | Buckets, databases, snapshots, and their exposure and reachability |
Network | The app's own surface | Segmentation, peering, private endpoints, and reachable paths |
Kubernetes | Not in scope | Control plane, RBAC, workloads, network policy, secrets |
Typical starting point | Anonymous or low-privileged app user | Assumed-breach foothold: one identity or one workload |
Best used for | Proving application security at the trust boundary | Proving blast radius across the cloud environment |
Read the table as complementary rather than competitive. The application layer sits inside the cloud environment, so a mature program runs both: the web-app test proves the software, the cloud test proves everything the software sits on. Where the pipeline that builds and ships that software is itself the concern, a CI/CD pipeline penetration test scopes the build chain as a separate high-trust surface.
Kubernetes-specific scope: control plane, RBAC, workloads, network policy, secrets, supply chain
Kubernetes adds a scope dimension that a plain cloud test does not have, and it is worth calling out explicitly because it is where teams most often assume the provider has them covered. Managed Kubernetes offloads the control-plane machinery to the provider, but the configuration, the identities, and the workloads are yours. The CISA and NSA Kubernetes Hardening Guide organizes the hardening surface into the same areas a pentest scopes.
Six areas define the Kubernetes-specific scope.
Control plane and API server. Whether the API server is exposed, how authentication is enforced, and whether admission control blocks unsafe workloads.
RBAC and service accounts. Whether roles follow least privilege, whether default service accounts are over-permissioned, and whether a pod token can escalate.
Workloads and containers. Privileged containers, host mounts, and whether a compromised pod can reach the node or cloud instance credentials.
Network policy. Whether pod-to-pod traffic is segmented or flat, and whether a compromised workload can reach the control plane or other namespaces.
Secrets management. How secrets are stored, mounted, and rotated, and whether they leak into environment variables, logs, or images.
Image and supply chain. Whether images come from trusted registries, whether they are scanned, and whether an unsigned or poisoned image can land on a cluster.
The business case for testing these areas is not abstract. In the Red Hat State of Kubernetes Security Report 2024, 67% of respondents said their organization delayed or slowed application development because of container and Kubernetes security concerns, and 42% named security as a top concern with their container strategy. Testing the cluster the way an attacker would is how those concerns become a prioritized fix list instead of a source of delay.
Shared responsibility and cloud-provider testing policies
Two boundaries govern what a cloud pentest can and cannot touch, and both are worth stating plainly before you scope.
The first is the shared-responsibility model. Your provider secures the physical infrastructure, the hypervisor, and, for managed services, the internals of the control plane. You are responsible for your identities, your configurations, your network rules, your workloads, and your data. A penetration test tests your side of that line. It cannot test the provider's infrastructure, and it does not need to, because that is not where your exposure lives. The scoping conversation is really about drawing your side of the line accurately.
The second is provider testing policy. All three major providers now let you test your own resources without asking first, within limits.
AWS permits testing of a defined list of services (including EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, ECS, and Fargate) without prior approval, but prohibits denial-of-service and simulated denial-of-service, and requires prior authorization for command-and-control and simulated events (AWS penetration testing policy).
Azure has not required pre-approval since June 2017, but customers and their testers must comply with the Microsoft Cloud Unified Penetration Testing Rules of Engagement, and denial-of-service testing is prohibited (Azure penetration testing).
Google Cloud does not require notification to test your own projects, provided you comply with the Acceptable Use Policy and Terms of Service and your testing only affects your own projects (Google Cloud Security FAQ).
The common thread: you can test what you own, you cannot test the provider, and denial-of-service is off the table everywhere. A credible testing partner scopes inside these rules by default and documents authorization before touching anything.
What drives the cost of a cloud or Kubernetes penetration test
Cloud and Kubernetes pentests are not priced per application. They are priced by the size and complexity of the environment and the depth of the engagement. Five drivers move the number more than anything else.
Account, subscription, and project count. Each additional account or subscription adds identities, trust relationships, and reachable paths to enumerate. A single-account startup and a fifty-account enterprise are different engagements.
Cluster count and size. Each Kubernetes cluster is its own control plane, RBAC model, and workload set. Ten clusters is not ten times one cluster, but it is meaningfully more than one.
Identity and IAM complexity. Federation, cross-account trust, many roles, and heavy service-account use all expand the attack-path surface a tester has to reason about.
Box color. A black-box test (no credentials, external view) costs differently from a grey-box test (a low-privileged foothold, the most realistic and common starting point) or a white-box test (full configuration access, the most thorough per hour of effort).
Compliance depth. A test that has to produce evidence mapped to SOC 2, ISO 27001, PCI DSS 4.0, or DORA carries more reporting and rigor than a point-in-time assurance test.
We do not publish a flat cloud-pentest rate because a flat rate would be misleading given those variables. Current packages and the factors behind them are on the Stingrai pricing page, and our guide to how much a penetration test costs explains the market drivers in more depth. The practical takeaway for a buyer is that a precise scope produces a precise quote, and a vague scope produces a padded one.
How to scope a cloud or Kubernetes penetration test
Scoping a cloud engagement well means describing your environment, not your host list. The inputs below give a testing partner what they need to price accurately and test realistically.
Accounts and clusters in scope. Which cloud accounts, subscriptions, or projects, and which Kubernetes clusters, are in play, and which are explicitly out.
Identity sources. IAM users and roles, SSO and federated identities, service accounts, and CI/CD identities that can reach the environment.
Starting assumption. Black-box, grey-box, or assumed-breach. A grey-box or assumed-breach start produces the most realistic attack paths.
Crown-jewel targets. The data stores, secrets, and administrative capabilities the test should try to reach, so impact is measured against what matters.
Provider testing policy. Which provider or providers, so the test stays inside AWS, Azure, or Google Cloud rules of engagement from the first hour.
Guardrails and rules of engagement. Production versus staging, read versus write, blast-radius limits, and any change windows.
Deliverables. A reproducible attack path, prioritized remediation, and a retest to confirm fixes closed the path rather than reconfigured it.
Where human testers own the infrastructure, and where Snipe fits
Cloud, IAM, and Kubernetes control-plane testing is human-pentester work. Reasoning across trust policies, RBAC, role-assumption chains, network reachability, and cluster configuration to find the one sequence that reaches production is adversarial judgment that automated posture tooling approximates but does not prove. Stingrai runs this as a manual, senior-led engagement, and as a CREST-accredited penetration testing service provider we deliver it with reproducible evidence rather than a re-skinned scanner report. It fits naturally alongside a red team engagement when the goal is a full assumed-breach path, and inside a continuous PTaaS program when the environment changes fast enough to need repeat validation.
Snipe, Stingrai's autonomous AI agent, has a specific and honest role here. Snipe is built for web application penetration testing: it hunts complex flaws such as IDOR, broken authorization, and business logic bugs in the applications and APIs running on your cloud or cluster, runs black-box and white-box analysis, and can open AutoFix pull requests. It does not test cloud IAM, the Kubernetes control plane, or the infrastructure itself, and we do not claim it does. The value of the pairing is a single consolidated report: human testers prove the infrastructure and cluster blast radius, Snipe covers the application layer running on top, and you get one prioritized picture instead of two disconnected ones.
That division also produces exactly the exploit-proven evidence a SOC 2, ISO 27001, PCI DSS 4.0, or DORA program benefits from, where auditors increasingly want proof that access controls and segmentation hold under an adversary, not just a policy document that says they should.
What this means for defenders
Scope the environment, not a host list. Name your accounts, clusters, identities, and crown jewels. A host count under-scopes a cloud test every time.
Test from an assumed breach. Credentials are the number one initial access vector. Start where a real attacker starts, with one identity or one workload, and measure the reach.
Do not assume the provider covers Kubernetes. Managed Kubernetes secures the control-plane internals, but RBAC, workloads, network policy, and secrets are yours to test.
Stay inside provider rules of engagement. AWS, Azure, and Google Cloud all allow testing your own resources and all prohibit denial-of-service. A credible partner scopes inside those rules and documents authorization first.
Retest after remediation. Least-privilege and network fixes need a retest to confirm the path is closed, not merely reconfigured.
Frequently Asked Questions
What does a cloud or Kubernetes penetration test cover?
It covers the layers you own in the shared-responsibility model: identity and IAM, storage and data exposure, network paths and segmentation, the Kubernetes control plane and workloads if you run containers, and the applications and APIs on top. It is scoped by accounts, subscriptions, projects, and clusters rather than by a host count, because a cloud attacker moves through identities and reachability, not through a list of servers.
How is a cloud pentest different from a web-application pentest?
A web-app pentest scopes a single application at its trust boundary and asks whether an attacker can abuse the software. A cloud pentest scopes the whole environment and asks how far an attacker can move through identities, storage, network, and clusters once they have any foothold. The application layer sits inside the cloud environment, so mature programs run both.
What is included in Kubernetes penetration testing scope?
Six areas: the control plane and API server, RBAC and service accounts, workloads and containers, network policy, secrets management, and the image and supply chain. Managed Kubernetes offloads the control-plane internals to the provider, but the configuration, identities, and workloads remain the customer's responsibility and are what the test covers.
Can you penetration test AWS, Azure, or Google Cloud?
Yes, you can test resources you own on all three, without prior approval, within each provider's rules. AWS permits testing of a defined service list but prohibits denial-of-service and requires authorization for command-and-control. Azure requires compliance with the Microsoft Cloud Unified Penetration Testing Rules of Engagement and prohibits denial-of-service. Google Cloud requires no notification provided you comply with its Acceptable Use Policy and only affect your own projects.
What drives the cost of a cloud or Kubernetes penetration test?
Account and subscription count, cluster count and size, identity and IAM complexity, box color (black, grey, or white), and compliance depth. Cloud pentests are priced by environment size and engagement depth, not by a flat per-application rate, which is why a precise scope produces a precise quote.
Does the shared-responsibility model limit what a pentest can test?
Yes, and helpfully so. The provider secures the physical infrastructure, the hypervisor, and managed control-plane internals; you are responsible for identities, configuration, network rules, workloads, and data. A penetration test tests your side of that line, which is where your exposure actually lives.
Does Stingrai's Snipe agent test cloud infrastructure or Kubernetes?
No. Snipe is Stingrai's autonomous AI agent for web application penetration testing. It covers the applications and APIs running on your cloud or cluster, hunting complex flaws such as IDOR, broken authorization, and business logic bugs. Cloud IAM, the Kubernetes control plane, and the infrastructure itself are tested by human pentesters, and the two combine into a single consolidated report.
How do I scope my first cloud or Kubernetes pentest?
Describe the environment, not a host list. Provide the accounts and clusters in scope, the identity sources, the starting assumption, the crown-jewel targets, the provider or providers involved, the guardrails, and the deliverables you expect. That is enough for a partner to price accurately and test realistically.
How does a cloud penetration test support compliance?
It produces exploit-proven evidence that access controls, least privilege, and segmentation hold under an adversary, which supports SOC 2, ISO 27001, PCI DSS 4.0, NIST, and DORA programs. Auditors increasingly want demonstrated blast-radius limits, not only policy documents.
References
CNCF. 2025 Annual Cloud Native Survey: Kubernetes Established as the De Facto Operating System for AI. January 2026. https://www.cncf.io/announcements/2026/01/20/kubernetes-established-as-the-de-facto-operating-system-for-ai-as-production-use-hits-82-in-2025-cncf-annual-cloud-native-survey/. Annual community survey of cloud native adoption, including Kubernetes production usage.
IBM. Cost of a Data Breach Report 2025. 2025. https://www.ibm.com/reports/data-breach. Reports the global average breach cost and cost by environment, including multi-environment and public-cloud incidents.
Verizon. 2025 Data Breach Investigations Report. 2025. https://www.verizon.com/business/resources/reports/dbir/. Analyzes breach patterns across thousands of incidents, including initial access vectors and the role of stolen credentials.
CISA and NSA. Kubernetes Hardening Guide, Version 1.2. August 2022. https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF. Cybersecurity Technical Report with recommended configuration and hardening guidance for Kubernetes clusters.
Red Hat. The State of Kubernetes Security Report, 2024 edition. 2024. https://www.redhat.com/en/blog/state-kubernetes-security-2024. Survey of container and Kubernetes security concerns, incidents, and their business impact.
Amazon Web Services. Penetration Testing. https://aws.amazon.com/security/penetration-testing/. AWS customer policy on permitted services, prior-approval requirements, and prohibited activities.
Microsoft. Penetration testing (Azure security fundamentals). https://learn.microsoft.com/en-us/azure/security/fundamentals/pen-testing. Azure policy on customer penetration testing and the Microsoft Cloud Unified Penetration Testing Rules of Engagement.
Google Cloud. Cloud Security FAQ. https://support.google.com/cloud/answer/6262505. Google Cloud policy on customer penetration testing, the Acceptable Use Policy, and Terms of Service.
Center for Internet Security. CIS Benchmarks. https://www.cisecurity.org/cis-benchmarks. Consensus configuration baselines for major cloud providers and Kubernetes.
Kubernetes. Securing a Cluster and Role Based Access Control (RBAC). https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/. Official Kubernetes documentation on control-plane, RBAC, and workload security controls.
