Cloud pentesting should test trust boundaries, not just public interfaces

Penetration testing a cloud platform should go beyond its customer-facing console, APIs and network perimeter. The central question is whether an attacker who gains a foothold in one part of the environment can cross into a more trusted zone, reach another tenant’s resources or affect provider-managed systems.

That is the methodology set out by researchers at Kaspersky Security Services in an overview of cloud penetration testing. They argue that finding a vulnerability—or achieving remote code execution in an isolated tenant workload—is not, by itself, a measure of the risk. The assessment must establish what the access allows an attacker to do and whether controls between trust zones hold.

Three layers help map cloud boundaries

The researchers describe cloud environments through three broad layers: External, Overlay and Underlay. The External layer includes the customer-facing management console, public APIs, service endpoints and software development kits. It is where customers authenticate and manage resources in their own tenant.

The Overlay is the provider’s logical service layer. It can include managed-service runtimes, internal APIs, schedulers, backup and monitoring systems, billing services and identity components. The Underlay consists of the infrastructure beneath those services, including host operating systems, hypervisors, physical servers, storage and transport networks.

The model is intended to help testers reason about changes in trust, rather than imply that every provider uses the same architecture. A managed database, for example, might run in a dedicated virtual machine at one provider or as a container in a shared Kubernetes cluster at another. The product’s name and customer interface do not reveal how it is built internally.

Nor does a boundary always correspond to a subnet or a transition to administrator privileges. It may separate roles within a process, an API from a background worker, a service runtime from a management component, or a virtual machine from its hypervisor. Testers need to identify which component controls a resource, whose data it serves, which identity it uses and how far that identity’s permissions extend.

Measure impact by what access enables

The approach places particular emphasis on tracing the context gained after an initial compromise. That context includes the runtime environment, network routes, available services and credentials or tokens, including those associated with an IAM service account. A weakness in one component can matter beyond that component if it exposes an identity or route that enables access to provider systems or other resources.

Assessments should therefore investigate whether an attacker can read, change or delete another tenant’s data; take over a provider IAM service account; use a compromised runtime to reach other services; affect provider resources from a lower-trust segment; or escape a virtual environment. These are questions to test, not outcomes to assume.

The researchers illustrate why implementation details matter with managed databases. A customer may be authorized to issue SQL queries but not to access the operating system running the database. If a flaw in the database service lets a tester cross from permitted query access into the service runtime, the new position may expose host files, processes, internal network connections or credentials. The security significance depends on what those capabilities permit next.

They also describe a class of boundary failure in which an internal API and a background worker handle input differently. If the API accepts data that the worker later trusts in a sensitive operation, the mismatch may undermine validation or permission logic. The example underscores that cloud risk can arise between components, not only at internet-facing entry points.

Architecture changes the assessment

Cloud platforms do not share one required technical design. Standards such as NIST SP 800-145 and ISO/IEC 17788 define cloud concepts and relationships, but they do not prescribe a single implementation. Providers may use OpenStack-like infrastructure, Kubernetes-based platforms, custom control planes or mixed stacks.

As a result, a tester may need to reconstruct parts of the system from indirect evidence, such as running processes, network routes, certificates, service names and agent configurations. A finding in a containerized service has different implications from the same apparent access in a dedicated virtual machine, because isolation mechanisms and reachable components differ.

The researchers caution that safely confirming impact matters. Testing should determine whether a boundary can be crossed without causing harm to provider systems or customer workloads. A test that cannot move from a tenant environment into the provider’s overlay can still provide useful evidence that a control is working in the tested path. It does not prove that every possible route is secure.

For cloud providers and enterprise customers, the practical takeaway is to assess the boundaries that protect tenant data and provider operations, not just the public surface. A disciplined test maps each transition, identifies the identity and privileges in play, and verifies the consequences of access. That produces a more meaningful view of isolation than a vulnerability count alone.