Cloud penetration testing across AWS, Azure, and GCP.

1. 01

   Scoping and provider authorisation

   We agree accounts, subscriptions and projects in scope, and confirm the provider's testing policy. AWS, Azure and GCP each permit customer-initiated testing within published rules, and we work inside those rather than asking you to seek special permission.

2. 02

   Identity and configuration review

   IAM policies, storage permissions, network rules, logging coverage and key management get reviewed against how they are actually configured rather than how the architecture diagram says they are. Most cloud incidents begin with an over-permissive role rather than an exploit.

3. 03

   Exploiting the reachable surface

   Internet-facing services, exposed storage, unauthenticated endpoints and application entry points are tested for genuine exploitability, not flagged from a configuration snapshot. A public bucket with nothing sensitive in it is not the same finding as one holding customer data.

4. 04

   Privilege escalation across accounts

   The cloud-specific risk is a foothold in one place becoming control of everything. We test role assumption, cross-account trust, metadata service access and service-account chaining to establish how far an initial compromise actually reaches.

5. 05

   Container and Kubernetes testing

   Where containers are in scope we test image provenance, registry exposure, runtime configuration, secrets handling and cluster RBAC — the places where an escape from a workload turns into control of the cluster.

6. 06

   Reporting, debrief and retest

   You receive findings split into configuration issues and proven exploitation, an executive summary, a live debrief, and a complimentary retest after you have made the changes.

Common questions

What is cloud penetration testing?

Cloud penetration testing is an authorized, hands-on attack against your cloud environment, its identities, configurations, network exposure, storage, and workloads, to find and safely exploit the weaknesses a real attacker would use. It works within each provider's rules of engagement (AWS, Azure, GCP) and focuses on cloud-specific failure modes: over-permissive IAM roles, public storage, metadata-service abuse, and cross-account privilege escalation.

Which cloud providers do you test?

SubRosa tests AWS, Microsoft Azure, and Google Cloud, plus multi-cloud and hybrid environments, and the containers and Kubernetes clusters running on them. Testing covers identity (IAM, Entra ID, service accounts), storage exposure, network, and workload security.

Do you need cloud provider authorization to run a cloud pen test?

Most simulated attacks against your own cloud resources no longer require prior approval from AWS, Azure, or GCP, but each provider has a pen-testing policy and rules of engagement that define what is in scope. SubRosa scopes and runs every engagement within those rules so the test is thorough and fully authorized.

Do AWS, Azure and GCP allow penetration testing?

Yes, all three permit customer-initiated testing of your own environments within published rules, and for most common services no advance approval is needed. Certain activities — notably denial-of-service simulation — remain restricted or require prior authorisation. We confirm the current policy for your provider during scoping and work inside it, so you are not left seeking special permission.

How is cloud penetration testing different from a cloud security posture review?

A posture review reads your configuration and reports what deviates from best practice. A penetration test establishes what is actually exploitable from outside, and how far a foothold reaches. Both are useful and they answer different questions — a public storage bucket containing nothing sensitive and one holding customer records look identical to a configuration scanner and are not remotely the same finding. Our report separates the two.

Do you test containers and Kubernetes?

Where they are in scope, yes: image provenance, registry exposure, runtime configuration, secrets handling and cluster RBAC. The finding that matters is usually whether escaping a single workload gives an attacker control of the cluster, and that requires testing rather than inspection.

What does a cloud penetration test cost and how long does it take?

It is scoped on the number of accounts or subscriptions, the services in use and whether containers are included, so we quote after a scoping call rather than from a list price. Most engagements run one to three weeks of active testing. The retest after you remediate is included.