Transcending the trust boundaries: how a cloud pentest works

A series on cloud penetration testing

This is the first article in a series on cloud penetration testing.

We'll cover the three cloud layers (External, Overlay, and Underlay), common architectures (OpenStack and Kubernetes), typical attack chains, and real-world incidents.

Users trust a cloud provider to configure and maintain their IT services, including data storage. In turn, the provider guarantees that hosted services will stay up and that data will remain strictly confidential.

To demonstrate that their platforms are secure, providers choose different strategies: some run bug bounty programs, some rely on regular internal audits, and some bring in external research teams.

However, cloud pentest methodology still has plenty of blind spots: there’s no single standard, and the outcome depends on the experience and skill of the team.

Most pentests in this area have historically focused on the external layer: the management console, customer interfaces, APIs, and the basic network perimeter. This layer is important, but it’s only the surface.

In this introductory article, we share our approach to penetration testing of cloud environments, which we’ve developed over several years and dozens of projects. We don’t claim to cover every possible scenario. Instead, we want to show the reasoning behind our pentests and highlight less obvious points that are easy to miss.

Key points

• Cloud infrastructure is more complex than a traditional web application. To simplify, you can think of it as a hotel with three zones: the booking website (External, the outermost layer), the guest rooms (Overlay, the logical layer), and the staff area (Underlay, the infrastructure or base layer). A cloud service is well protected if the trust boundaries between these zones cannot be breached.
• A cloud pentest’s value isn’t measured by the number of vulnerabilities found or by the mere fact that code ran. Remote command execution in an isolated tenant container is only the beginning of a pentest, not the end. The main goal is to assess whether an attacker can violate trust boundaries.
• The assessment should answer five critical questions:
  • Can an attacker read, modify, or delete other tenants’ data?
  • Can they take over the provider’s IAM service account?
  • Does compromising a runtime environment lead to the attack spreading to other resources and services?
  • Can the provider’s internal resources be affected from low-trust segments?
  • Is a virtual environment escape possible?
• A negative result is still a result. If a pentester cannot move from the tenant plane to the provider overlay, that is a valuable finding. It shows which protection boundaries work in practice and which rely only on assumptions and need additional controls. However, it does not prove that the trust boundary is impossible to cross or that no other attack paths exist.

Key terms

Below, we explain some specific terms that are most often used in cloud infrastructures.

Tenant (think of a renter in an apartment building) is a logically isolated unit within a cloud platform. Examples include a user (such as an organization), a separate project or cloud account, or another unit of administrative and resource isolation.

Tenant plane is the set of IT services and data that a tenant manages directly: virtual machines, Kubernetes clusters, databases, object storage, and managed applications.

Management console is the graphical web interface and the entry point for the customer at the External layer.

Service runtime is the actual environment in which a provider’s cloud product runs: a process, container, pod, virtual machine, or microVM.

Service management plane consists of the provider’s internal components that create, update, restart, back up, and delete the service runtime.

IAM service account (service identity) is a special digital identity for programs, bots, cloud services, or servers. It lets them access the required cloud resources automatically and securely, without human involvement.

Context (in cloud security) is the set of attributes and credentials that define the current permissions and runtime environment of a subject in the system. It includes the identity in use (for example, a service account token, certificate, or key), the privilege level (roles and IAM policies), and the technical environment from which the request is initiated (container, virtual machine, or network segment).

Initial zone is the context in which the researcher lands right after the first successful transition. It consists of the specific runtime, IAM service account (service identity), namespace, network routes, and the set of available services.

Provider overlay is the provider’s internal environment, hidden from the customer, that is accessible from the initial zone: network segments, DNS zones, internal APIs, and management components.

Control plane consists of the platform components that make global management decisions and change the platform state: they allocate resources, assign permissions, configure the network, and coordinate state.

Data plane consists of the components that transfer or process user data and application traffic.

Some components (or systems) sit at the intersection of different architectural layers, so they can’t automatically be assigned to the data plane or the control plane. Examples include logging, backup and billing systems. Their role changes depending on the task a component is performing at a given moment and how its work affects user traffic.

Cell is a bounded portion of the platform in which compute, disk, network, or management components are shared (often tied to a region, availability zone, service type, or group of tenants).

Pods are the smallest compute units in Kubernetes. A pod is one or more containers that are deployed on the same host and share common resources.

Cross-tenant impact is confirmed impact from the context of one tenant on the resources of another, without a trust relationship defined by the architecture.

Provider-level impact is impact on a provider’s management, infrastructure, or supply chain component that goes beyond the original tenant resource.

Tenant workload is the set of compute resources, processes, and applications that a customer runs and uses in their tenant to perform business tasks. It includes virtual machines, containers (such as pods in Kubernetes), serverless functions, managed databases, and any other active services that process tenant data.

What a pentester needs to check

During a project, a pentester needs to examine not only the management console but also the boundaries that separate the tenant plane from managed services and the provider’s internal infrastructure.

A single request passes through many components, from the API gateway to the storage system. A configuration error in any of them changes the attack context: the researcher takes over an IAM service account, gains access to the cloud’s internal network, or acquires the ability to affect another tenant.

This is why a cloud pentest is not just a search for vulnerabilities in the management console, nor a sequential scan of cloud subnets. Above all, it means testing trust boundaries: verifying how transitions between zones with different trust levels are controlled. A more trusted zone must treat everything that comes from a less trusted zone as potentially hostile.

What makes a boundary real? Controls such as authentication and authorization (IAM, RBAC), isolation (virtualization, containerization, network segmentation), cryptography (mTLS), input handling, and others.

We build a map of potential boundaries and check each one: is it actually enforced by controls, or does it rely on assumptions (architectural, infrastructural, implementation-related, and others)?

Cloud platform as a research target

When we assess the security of a traditional system, we usually start from basic architectural patterns. For web applications, this is a typical stack of a web server (Nginx, Apache, and so on), server-side logic, object storage, and integrations with third-party services. For hardware solutions, it is a chain from physical interfaces to firmware and protocol handlers.

Cloud platforms are different: how they’re actually built is highly uncertain. Cloud computing standards and reference architectures (such as NIST SP 800-145 and ISO/IEC 17788) define the roles of participants and the relationships between cloud components, but they don’t prescribe strict rules for how to build a platform.

Because there is no single technical standard, a managed database that looks the same from the outside can run in an isolated virtual machine at one provider, in a namespace of a shared Kubernetes cluster at another, and in a dedicated tenant cluster at a third.

The same variability applies to software choices. A provider can use OpenStack, Kubernetes, its own control plane, or a combination of them. This means a familiar product name doesn’t give a full picture of the system’s internal structure.

That’s why a cloud pentest is harder than assessing a traditional system. Once the tenant trust boundary is breached (say, by escaping from a microVM to the host operating system), the job is no longer finding the next open port. It becomes reconstructing the architecture from indirect clues.

The pentester puts the puzzle together by studying running processes, network routes, certificates, service names, and agent configurations. From these details, the researcher determines the role of each component and the trust boundaries between them.

To keep our approach vendor-agnostic, we will look at cloud infrastructure without reference to specific brands. Depending on the architectural scenario, the same component can be implemented in fundamentally different ways.

For example, in one case a managed database can run as a separate managed service isolated at the virtual machine level (where the main risks are hypervisor security and the management API). In another case, it can run as a container inside a shared Kubernetes cluster (where the threat comes from the possibility of container-to-host escape and the quality of namespace isolation).

The hotel analogy and the three cloud layers

There is no single standard for building cloud infrastructure. To make pentesting systematic, we use our own three-layer model of the cloud: External, Overlay, and Underlay.

The easiest way to picture a cloud platform is as a large hotel. It has a public area for guests, back-of-house areas for staff, and technical floors with utility systems. This analogy doesn’t cover every detail, but it shows well how areas of responsibility are divided and how the transitions between them work.

External layer: in a hotel, this is the booking website, the doors, and the front desk. At this layer, the pentester interacts with cloud components the way a typical user does: logs in to an account, calls the public API, creates IT services, and connects to their endpoints.

Work at this layer is similar to external penetration testing or application security assessment. The main goal is to gain initial access from the outside to another customer’s tenant, or to move to the Overlay layer.

The External layer is where tenant access is provided as intended. In a hotel, the tenant is the room itself: guests control the belongings and equipment in their own room, but their key card must not open neighboring rooms. In the cloud, customers manage only their own data, virtual machines, pods, databases, object storage (S3 buckets), and accounts within their own project.

A tenant is not a separate infrastructure layer. It is what the user gets at the External layer. This is where the user’s legitimate privileges end and the first trust boundary, the one the pentester checks, begins.

The provider’s service layer (Overlay): in a hotel, this is the “Staff only” area: kitchens, laundries, the control room, service corridors, and the master key system. In cloud infrastructure, this is the internal logical service management layer: runtime environments for managed services, schedulers, backup, monitoring (observability) and billing systems, the IAM system, and internal APIs.

Customers use the results provided by these systems but must not get any access to them unwarranted by the architecture.

Don’t confuse this term with an overlay network in traditional network engineering: a logical network on top of a transport underlay network, such as VXLAN segments. In our methodology, Overlay has a broader meaning: it’s the internal logical layer for running and managing cloud services, and it can be split differently depending on the cloud.

For clarity, the table below divides it into two sublayers: runtime environments of tenant services and provider’s internal components.

Infrastructure layer (Underlay): in a hotel, this is the utilities, electrical equipment, and physical access control systems that keep the building running. In the cloud, this is the hardware layer: physical servers, host operating systems, hypervisors, the transport network, storage systems, and out-of-band management.

Careless testing at this layer can do serious damage. But the key point of this analogy is not the rooms themselves, but the doors between them. A vulnerability on a booking website is dangerous, but a master key left in a room that opens several or every door in the building is far more so.

The same rule applies in the cloud: remote code execution (RCE) inside an isolated tenant container (pod) is only a local problem. Compromise of an IAM service account that manages the resources of a region affects the entire platform.

The table below gives examples of components, pentester entry points, and assessment goals for each layer. We split the Overlay into two sublayers because the runtime environment of a tenant service and the provider’s internal infrastructure have different trust boundaries and different entry points.

| Layer | What it contains | Typical pentester entry point | Main assessment goal |
| External | Public