Container escape and cloud metadata services

Objective 4.5 in this course covers cloud-based attacks — CompTIA describes it as exploiting container escapes, metadata service attacks and identity and access management (IAM) misconfiguration. This lesson takes the first two; lesson 34 takes IAM. Runs against your own cloud account or a local container, in the lab from lesson 2. Everything here needs the scoping care from lesson 4: the cloud provider owns the infrastructure, and their testing rules apply on top of the client's authorisation.

Why this matters

Cloud attacks are their own objective because the boundaries are different from on-premises: the trust model, the identity system and the "escape" targets all change. Container escape and metadata-service abuse are two of the most reliable routes from "code running in a workload" to "credentials for the whole account", and both are examined by name.

The lesson

What a container is and is not a security boundary against

A container isolates a workload using operating-system features — separate process, filesystem and network views — sharing the host kernel rather than running its own.

What follows, and what people over-trust:

• A container is a good isolation boundary and a weak security boundary. It keeps well-behaved workloads apart; it is not designed to contain an attacker who is actively trying to break out, in the way a virtual machine's hardware boundary is.
• It shares the host kernel. A kernel flaw, or a container granted more access to the host than it needs, is a path out — and out of a container is onto the host running every other container.
• "It's in a container" is not "it's contained". The security depends entirely on the container's configuration and the host's hardening, which is an empirical question exactly like lesson 22's segmentation.

So the assessment question is the same shape as everywhere: not "is it containerised" but "what can this workload actually reach".

Privileged containers, mounted sockets and host paths

The configuration mistakes that make escape straightforward, and the ones to look for:

• Privileged containers. A container run with elevated privilege has most of the host's capabilities and is close to running directly on the host. This is the single most common escape enabler, and it is usually set to make something work rather than for any real need.
• A mounted container-runtime socket. A container that can talk to the host's container management can start new containers — including a fully privileged one mounting the host filesystem — which is escape by design.
• Host paths mounted in. A container with the host's filesystem, or sensitive parts of it, mounted read-write can modify the host directly.
• Excessive capabilities. Even without full privilege, specific capabilities granted to a container can be enough to affect the host.

These are configuration findings and are worth reporting on discovery — the misconfiguration is the vulnerability, and demonstrating the full escape is proof, not the finding itself.

The metadata service as a credential vending machine

Cloud platforms expose an internal metadata service to instances — reachable at a fixed internal address — that describes the instance and, critically, hands out temporary credentials for the identity attached to it.

Why this is an attacker's favourite target:

• It hands out credentials. An instance with a role attached can ask the metadata service for that role's temporary credentials, and so can anything running on the instance — including an attacker who reached it.
• It is reachable from any code on the instance, including, dangerously, from a server-side request-forgery flaw in an application: an application tricked into making a request to the metadata address can retrieve the credentials and hand them to the attacker without any code execution at all.
• The credentials are the role's, so the blast radius is whatever the role can do — which lesson 34's IAM misconfiguration usually makes far too broad.

This is the cloud equivalent of lesson 29's credential dumping: reach the instance, ask the metadata service, and you hold the workload's identity.

Demonstrating both in your own cloud account or locally

The applied lab for objective 4.5's first half. Container escape can be practised locally; metadata abuse needs a cloud account, and a free tier suffices.

For container escape, locally on the lab from lesson 2:

1. Run a deliberately misconfigured container — privileged, or with a host path or the runtime socket mounted.
2. From inside it, reach the host using that misconfiguration.
3. Confirm host access, then remove the misconfiguration and confirm the escape stops working.

For the metadata service, in your own cloud account:

1. Attach a role to an instance, and from the instance, query the metadata service for its credentials.
2. See what those credentials can do — which is lesson 34's territory.
3. Then enable the hardened version of the metadata service (below) and see the easy retrieval fail.

Everything is your own account and your own containers — no client infrastructure and no provider terms broken, per lesson 4.

IMDSv2, and hardening the container runtime

Remediation at the cause, for both halves:

• The hardened metadata service. Newer metadata services require a session-oriented request that a simple forged request cannot satisfy, which specifically defeats the server-side request-forgery path. Requiring it, and restricting the metadata service where workloads do not need it, is the fix.
• Least privilege on the instance role. The credentials the metadata service hands out are only as dangerous as the role, so a tightly-scoped role limits the damage of any retrieval — lesson 34's whole subject.
• Do not run privileged containers, and do not mount the runtime socket or host paths unless genuinely required, and then read-only and minimal.
• Drop unneeded capabilities, run as non-root inside the container, and keep the host kernel patched.
• Runtime protections that watch for the behaviour of an escape, so that a successful one is at least detected — and whether the client's tooling saw your demonstration is part of the report.

The client message: containers and cloud identity are safe when configured for least privilege and hardened defaults, and dangerous when configured for convenience — and most of these findings are convenience settings nobody revisited.

What to take into the exam

• A container is an isolation boundary, not a strong security boundary; it shares the host kernel, so the question is what the workload can reach.
• Privileged containers, a mounted runtime socket, and host paths mounted read-write are the staple escape enablers, and are findings on discovery.
• The metadata service hands out the instance role's temporary credentials to any code on the instance, including via server-side request forgery with no code execution.
• Fix with the session-based metadata service (defeating SSRF retrieval), least privilege on the role, and not running privileged containers or mounting the runtime socket.