How Cloud Penetration Testing Verifies Tenant Isolation

Key takeaways

• Modern cloud penetration testing evaluates technical trust boundaries and tenant isolation across External, Overlay, and Underlay architectural zones rather than focusing solely on perimeter interfaces.
• Arbitrary code execution within managed containers or serverless runtimes represents an intended feature; true security risk emerges only when attackers pivot into shared provider control planes.
• Landmark security research including ChaosDB and Azurescape demonstrates that over-privileged IAM service tokens and outdated container runtimes create dangerous paths to cross-tenant data access.
• Safe testing protocols require establishing dual dedicated test tenants to confirm cross-tenant impact on synthetic data without disrupting production services or exposing real customer workloads.

Modern cloud penetration testing assesses whether technical trust boundaries and tenant isolation mechanisms withstand targeted attacks across multi-tenant environments. Rather than stopping at public management consoles or isolated code execution within a customer container, comprehensive cloud security assessments evaluate how effectively an infrastructure prevents lateral movement between tenants and the underlying provider management planes. By testing transitions across the external perimeter, internal service management overlays, and physical infrastructure underlays, cloud security teams determine whether compromise of a single workload or identity token can cascade into cross-tenant unauthorized data access or provider-level infrastructure manipulation.

Architectural layers and the three-zone model

Cloud environments diverge significantly from traditional single-tenant application hosting. While standard web applications operate on predictable stacks consisting of load balancers, web servers, application runtimes, and databases, cloud platforms introduce deep uncertainty regarding internal component distribution. As detailed in the Kaspersky Security Services research on cloud penetration testing, assessing a multi-tenant provider requires categorizing systems across three primary architectural zones: the External perimeter, the provider Overlay, and the infrastructure Underlay.

A practical mental model for this architecture is a hotel structure. The External layer represents the hotel lobby, booking portal, and exterior doors. In a cloud context, this encompasses public application programming interfaces (APIs), the customer management console, authentication gateways, and exposed tenant endpoints. Within this outer zone, a tenant acts as a guest inside an assigned room: customers legitimately manage virtual machines, Kubernetes pods, databases, and object storage buckets, but their permissions must never extend into neighboring environments or administrative facilities.

The Overlay layer functions as the back-of-house staff area, containing the logical service management plane that provisions, updates, monitors, and bills resources. This internal zone splits into two critical operational tiers: service runtimes (the virtual machines or containers running customer databases and applications) and internal provider components (task schedulers, billing pipelines, observability collectors, and internal IAM controllers). Customers consume the outputs of these systems but must remain isolated from direct interaction with them.

The Underlay layer forms the building foundation and utility infrastructure. It houses physical compute servers, host operating systems, hypervisors, transport networking switches, storage fabrics, and baseboard management controllers. Penetration testing at this level requires rigorous operational controls, as disruption can destabilize an entire availability zone or shared physical rack.

Identifying true trust boundaries versus assumptions

A frequent error in cloud security assessments is treating network reachability or intended code execution as proof of vulnerability. In managed services such as interactive data science notebooks, serverless computing functions, and automated continuous integration pipelines, arbitrary code execution is an explicit product feature rather than an exploitable defect. A meaningful security finding requires proving that the execution environment allows an attacker to breach an enforced trust boundary.

Technical trust boundaries are defined by active enforcement mechanisms rather than documented assumptions. These controls include cryptographic authentication through mutual TLS (mTLS), strict identity and access management (IAM) role policies, mandatory access controls, and hypervisor-level memory segmentation. When a cloud platform replaces verified controls with architectural assumptions, severe vulnerabilities emerge.

For example, subtle differences in protocol parsing between front-facing APIs and backend workers can dissolve boundary protections. If an internal management API accepts strings containing null bytes and forwards them without sanitation to a low-level worker querying a PostgreSQL database, the worker C-library truncates the string. This input handling failure can reset authorization contexts and allow an unprivileged user to overwrite database superuser credentials, transforming a routine input into complete database takeover.

To distinguish genuine isolation breaches from false positives, experienced penetration testers apply a four-stage verification sequence:

1. Network visibility: The researcher verifies whether an internal service endpoint or neighboring tenant IP is reachable from the tenant plane. This confirms potential attack surface exposure without proving exploitability.
2. Authentication validation: The tester attempts to authenticate against the discovered endpoint using compromised service account credentials, metadata tokens, or forged certificates.
3. Authorization inspection: The target service evaluates the provided identity context and confirms whether elevated privileges or cross-tenant actions are permitted.
4. Controlled action beyond the boundary: The tester performs a minimal, reversible operation—such as writing a benign marker record into a dedicated secondary test tenant—to demonstrate practical business impact.

Attacker models and initial foothold vectors

Structuring a cloud assessment requires establishing realistic threat actor personas. Cloud pentests evaluate four primary attacker models: external attackers possessing no initial credentials, authenticated customers with legitimate tenant privileges, internal adversaries with a compromised runtime environment, and privileged operators possessing stolen service identities. Regardless of the starting persona, researchers pursue three primary technical vectors to establish an initial foothold.

The first vector focuses on achieving code execution inside a provider-managed service. Attackers exploit vulnerabilities in web management interfaces, database engines, or third-party extensions to spawn shell sessions within the underlying host environment. Alternatively, supply chain vectors—such as publishing poisoned container images that tenants download—allow adversaries to initiate container breakouts directly onto shared worker nodes.

The second vector prioritizes credential acquisition over code execution. Rather than bypassing network barriers, attackers extract valid IAM service account tokens, metadata tokens, or cryptographic certificates embedded in local configuration files and environment variables. If an identity token possesses excessive permissions across regional control planes, an adversary can invoke standard cloud APIs to manipulate resources without triggering perimeter network alerts.

The third vector leverages administrative and support channels. Attackers target provider operations teams through phishing, compromised contractor credentials, or unauthenticated remote management portals. Gaining access to a support console or administrative virtual private network grants an immediate operational foothold inside the provider overlay, bypassing all external security perimeters.

Get the Weekly Brief

Curated analysis for tech leaders. Every Thursday.

Subscribe

Analyzing the architectural implementation of the target platform is essential during this phase. Cloud providers rarely deploy uniform technology stacks. Foundational cloud frameworks defined in NIST Special Publication 800-145 outline service models such as IaaS and PaaS but leave underlying software implementations open to provider preference. A platform might run custom orchestration scripts on top of OpenStack, utilize multi-tenant Kubernetes clusters, or combine proprietary microVM hypervisors with distributed Ceph storage networks. Pentesters must reconstruct this environment by inspecting running processes, mount points, network interfaces, and kernel parameters.

Attack chains and cross-tenant incident precedents

Public vulnerability research highlights how minor configuration errors in cloud infrastructure escalate into critical platform-wide compromises. In multi-tenant container platforms, relying solely on namespace boundaries represents a known architectural weakness. Official Kubernetes multi-tenancy security guidance warns that namespaces do not provide hard tenant isolation without additional layers such as network policies, runtime class sandboxing, and strict admission controllers.

This structural risk was demonstrated by the Azurescape attack chain documented by Unit 42. In that incident, researchers escaped an outdated container runtime within Azure Container Instances, acquired an administrative Kubernetes service account token on the underlying host, and established full cluster-level control over the multi-tenant control plane, enabling unauthorized access across customer accounts. Similarly, detailed Kaspersky analysis of cloud isolation bypasses confirmed that initial code execution on managed Kubernetes worker nodes can be chained with host privilege escalation to compromise neighboring tenant workloads.

Cross-tenant compromises can also occur without host escape or kernel vulnerabilities. During the ChaosDB research on Azure Cosmos DB, an embedded Jupyter Notebook visualization feature inadvertently exposed internal service account tokens and primary database keys. Because these credentials had global read and write privileges across the service fabric, researchers demonstrated access to thousands of external customer databases through legitimate administrative API calls.

Securing infrastructure cores against lateral movement requires strict network segmentation. Engineering baselines documented in the OpenStack Security Guide mandate isolating tenant traffic, messaging queues, and control plane management networks onto separate physical or virtual networks to prevent hypervisor breakout escalation. In enterprise operational environments, continuous behavioral monitoring and threat hunting across cloud infrastructure are critical to intercept token misuse before adversaries pivot from isolated runtimes into shared storage repositories.

Safe confirmation of impact and rules of engagement

Because cloud penetration testing directly touches shared infrastructure, testing methodologies must balance rigorous technical validation with strict operational safety. Careless automated scanning or aggressive privilege escalation can inadvertently disrupt production message brokers, overwrite centralized telemetry databases, or corrupt shared backup snapshots. Explicit rules of engagement are mandatory before commencing an assessment.

To safely evaluate multi-tenant isolation, penetration testing teams configure two independent test tenants under their own administrative control. When an authorization flaw or credential leak is discovered in the first tenant, researchers attempt to access only pre-seeded synthetic data inside their second tenant. This protocol provides indisputable proof of cross-tenant exposure while ensuring that real customer data remains confidential and unaccessed.

Executive leadership and platform engineering teams look to penetration testing engagements to resolve five decisive security questions:

• Can an adversary operating within one tenant read, alter, or delete data belonging to another tenant?
• Can user-supplied code or unprivileged accounts harvest provider IAM service tokens or assume elevated service identities?
• Does the compromise of a single workload runtime permit lateral movement across an entire availability cell or regional cluster?
• Can internal administrative resources, billing backends, or deployment pipelines be influenced from low-trust tenant networks?
• Is virtual machine or container runtime escape achievable against hardened production hypervisors?

A testing cycle that concludes with zero trust boundary breaches provides immense operational value. Documenting that specific security controls successfully repelled targeted lateral movement confirms that defensive investments are functioning effectively, allowing engineering teams to focus hardening resources where verification reveals genuine exposure.

Bottom line

Cloud security assurance requires shifting focus from surface-level vulnerability counts to systematic validation of trust boundaries and tenant isolation. As multi-tenant architectures combine virtual machines, containers, and complex microservices across shared physical infrastructure, organizations cannot rely on documentation or vendor claims alone to guarantee confidentiality. Technical teams should evaluate cloud providers based on verified isolation controls—including rigorous IAM scoping, hardened hypervisor boundaries, and network segmentation—while conducting ethical penetration testing to verify that runtime footholds cannot escalate into platform-wide compromise.

Sources

• Cloud pentesting: testing trust boundaries and tenant isolation | Securelist
• An insecure neighbor: how a vulnerability chain led to an isolation bypass in cloud infrastructure | Securelist
• ChaosDB: How we hacked thousands of Azure customers’ databases
• Azurescape: Breaking Out of Azure Container Instances to the Host and Control Plane
• SP 800-145, The NIST Definition of Cloud Computing | CSRC
• Multi-tenancy | Kubernetes
• OpenStack Security Guide