Learning outcomes
- Map shared mechanisms for processes, containers, virtual machines, and hosts.
- Select isolation from adversary, workload authority, and consequence.
- Keep workload identity distinct from execution boundary.
- Test breakout, host, credential, network, and recovery failure paths.
Protection need
Execution isolation must bound what a compromised workload can read, change, impersonate, or disrupt. Processes share an operating-system kernel and often a user or filesystem context. Containers add namespace and control-group boundaries while sharing the host kernel. Virtual machines add a guest kernel and hypervisor boundary. Separate hosts reduce shared hardware and management but still share networks and control planes.
Security objectives and requirements
Select a boundary from code trust, tenant trust, credential authority, data sensitivity, escape impact, side-channel concern, operational access, and recovery. Minimize host privileges, mounts, devices, sockets, capabilities, metadata access, and shared credentials. Isolate high-authority access components from untrusted workloads.
Security invariants and evidence
One workload cannot read another workload's memory, filesystem, credential, network identity, or control socket. Compromise cannot change the host, runtime, policy, evidence, or recovery authority beyond the stated boundary. Runtime and deployment evidence identify exact workload, image, node, privileges, and trust.
Failure cases
- A container mounts the runtime socket or privileged host path.
- Two tenants share a node and a kernel escape crosses the boundary.
- A VM has a shared management credential or metadata role.
- A sidecar can read another process's credential.
- Recovery restores the same compromised image or host state.
Design tradeoffs and residual risk
Stronger isolation costs startup time, density, memory, device access, and operational complexity. More boundaries add images, kernels, patching, and control planes. Confidential computing can protect selected data from some host threats and does not guarantee safe application behavior.
Residual risk includes hypervisor or kernel compromise, hardware side channels, management-plane takeover, shared network and storage, and valid workload use of its own authority.
Pomerium boundary
Pomerium protects configured access paths. It does not isolate the runtime, container, virtual machine, node, or host that runs Pomerium or an upstream. Operators choose execution boundaries and prevent compromised workloads from reaching Pomerium credentials, control planes, or direct upstreams.
Exercise
Compare one process, container, and virtual-machine deployment for an access component. Inventory kernel, host, runtime, filesystem, device, network, credential, metadata, administration, evidence, and recovery sharing.
Test another workload's files, service account, metadata, network, runtime socket, control API, and direct upstream. State the maximum credible effect of one escape in each design.
Evaluation checklist
- Which kernel, host, runtime, device, network, credential, and control mechanisms are shared?
- Does the boundary match the workload and tenant trust assumption?
- Can one workload reach another workload's identity or access-system authority?
- Are management and recovery paths stronger than the workload boundary?
- Which residual host, hypervisor, hardware, and control-plane risks remain?
Next learning unit
Trust Boundary and Data Flow
Map where data or authority crosses between components with different control, identity, or assurance assumptions.
