The three-layer hotel model: External, Overlay, Underlay
The authors map cloud infrastructure to a hotel with three zones: the booking website (External), the guest rooms (Overlay), and the staff area (Underlay). The External layer is the public attack surface — management consoles, public APIs, SDKs and customer endpoints. The Overlay is split into two sublayers: the runtime environments of tenant services (pods, VMs, managed databases) and the provider’s internal components (billing, backups, monitoring, IAM and internal APIs). The Underlay is the hardware and virtualization base: host OSes, hypervisors, transport networks, storage systems and BMCs. The core test is not whether code ran; it is whether trust boundaries between these zones can be breached.
Typical attack chains: from managed features to provider-level impact
The source lays out multiple real-world patterns. One chain begins with a vulnerability in a managed service interface (for example, a web interface vulnerability such as CVE-2026-19478), leads to remote code execution in a service runtime, and then to extraction of an IAM service account token that is not scoped to a single tenant. That token can be used to call internal APIs and affect other tenants. Another pattern — exemplified by the Azurescape description from Unit 42 — starts with a container escape, acquisition of a privileged Kubernetes service account, and compromise of a multi-tenant cluster. A third path exploits public worker operations (restore, import, image build) whose internal workers validate parameters too loosely, allowing replacement of images or packages that later run in other tenants’ workloads. Finally, virtual-machine escape is a classic vector: a guest-to-host vulnerability can reach the hypervisor and then the management network, but such testing carries high operational risk and requires explicit provider approval.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildWhat makes a boundary “real”: controls, context, and four stages of confirmation
Controls — authentication and authorization (IAM/RBAC), isolation (virtualization, namespaces, networking), cryptography (mTLS), and input handling — are what turn an architectural line on a diagram into an enforceable trust boundary. To distinguish hypotheses from real compromise, the authors prescribe four sequential stages from the researcher’s perspective: (1) network visibility of an internal service from the tenant plane; (2) successful authentication using a compromised token or certificate; (3) confirmation that the authenticated context has permissions to act on the target object; and (4) a controlled action beyond the original trust boundary, typically performed against a second test tenant under the researcher’s control. A negative finding — inability to move from tenant plane to provider overlay — is still a valid and useful result because it demonstrates which boundaries hold under targeted testing and which depend on assumption rather than enforced controls.
Choosing the next boundary: telemetry, IAM, backups, billing, supply chain, and management services
After gaining an initial zone, testers weigh two factors: network visibility (what segments and services are reachable) and available trust level (which credentials and certificates are accepted). The source highlights several priorities: centralized telemetry and observability (whether logs/metrics/traces cross-tenant or reveal credentials), data storage and backups (scope of snapshots, restore volumes, and tenant binding), billing and quota systems (mismatches that enable unbilled usage or quota bypass), IAM/service accounts (token scope, lifetime and tenant binding), supply chain components (image registries, package repositories, CI/CD configurations), and management services (schedulers, message queues, configuration management) that can push changes across many resources. Any one of these areas can turn a local compromise into cross-tenant or provider-level impact.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: focus pentests on trust boundaries, not just open ports. Verify where service tokens live (pod, managed cluster or operator), test telemetry isolation, and treat supply-chain write access as a priority risk because altering images or packages can affect many tenants.
- Procurement and enterprise buyers: ask whether a managed product’s external appearance masks fundamentally different architectures. A “managed database” may run in an isolated VM in one implementation, a shared Kubernetes namespace in another, or a tenant-dedicated cluster in a third — and those differences change the threat model and required SLAs for isolation and testing.
- End users and application owners: code execution inside a product feature (notably notebooks, CI runners, or serverless) is a feature in many services — but it is only the start of a security assessment. The meaningful question is whether that execution can be used to obtain service account tokens, access backups, or affect other tenants.
Measured, sequential testing — record the start context, validate each new context’s identity and privileges, and use the minimal safe action needed to prove cross-boundary impact — is the practical core of a cloud pentest. The method turns scattered technical findings into provable risk: can one tenant affect another, or can a low-trust segment reach provider internals? Where the answer is “no,” the finding still documents which controls worked in practice and which relied on untested assumptions.
Original: Transcending the trust boundaries: how a cloud pentest works — securelist.com
