Domain 3 Β· Lesson 5 of 6
Virtualization, Cloud & Container Security
αΊ’o hΓ³a, ΔΓ‘m mΓ’y & BαΊ£o mαΊt Container
Key Terms
Hypervisor Type 1/2
VM Escape
VM Sprawl
Shared Responsibility
IaaS
PaaS
SaaS
Container
Docker
Kubernetes
Namespace
cgroup
Pod Security Standards
NetworkPolicy
Image Scanning
Registry
Hypervisor Types
A hypervisor (VMM β Virtual Machine Monitor) creates and manages virtual machines. The type determines the attack surface.
| Type | How It Runs | Examples | Attack Surface | Use Case |
|---|---|---|---|---|
| Type 1 Bare-metal |
Runs DIRECTLY on hardware β IS the operating system | VMware ESXi, Microsoft Hyper-V, KVM (Linux kernel) | SMALLER β no host OS layer to compromise | Data centers, cloud providers (GCP, AWS use Type 1) |
| Type 2 Hosted |
Runs on TOP of a host OS β OS + hypervisor both must be trusted | VirtualBox, VMware Workstation, Parallels | LARGER β host OS vulnerabilities add to attack surface | Developer workstations, testing environments |
Key VM Threats
| Threat | Description | Severity | Mitigation |
|---|---|---|---|
| VM Escape | Guest VM breaks out of virtualization boundary to access the host hypervisor or other VMs | CRITICAL β most severe VM vulnerability | Patch hypervisor promptly; minimize guest tools; use Type 1; separate sensitive VMs |
| VM Sprawl | Uncontrolled proliferation of VMs β forgotten, unpatched, unmanaged VMs increase attack surface | HIGH β unpatched VMs are easy targets | VM lifecycle management; automated decommissioning; inventory tracking |
| Snapshot Risk | Reverting to a snapshot undoes all patches, configuration changes, and security fixes applied since the snapshot | HIGH β can regress to vulnerable state | Snapshot management policy; prohibit production snapshot reversion without security review |
Cloud Shared Responsibility Model
The cloud provider and customer share security responsibility β but the division depends on the service model. The customer ALWAYS owns their data regardless of service model.
| Layer | IaaS Example: GCE | PaaS Example: GKE | SaaS Example: Gmail |
|---|---|---|---|
| Physical / Hardware | Provider | Provider | Provider |
| Network Infrastructure | Provider | Provider | Provider |
| Hypervisor | Provider | Provider | Provider |
| Operating System | Customer | Provider (node OS) | Provider |
| Runtime / Middleware | Customer | Provider | Provider |
| Application Code | Customer | Customer | Provider |
| Data | Customer | Customer | Customer |
| Access Configuration / IAM | Customer | Customer | Customer |
Platform C on GCP: Platform C runs on GKE (PaaS) + GCE (IaaS). GCP is responsible for hardware, network, hypervisor, and GKE node OS patches. FinTech Company X is responsible for: container security configuration (Pod Security Standards, RBAC, NetworkPolicies), application code security, data encryption (AES-256-CTR), secret management (Vault), image scanning, and access control configuration (GCP IAM).
Container Security (Docker / Kubernetes)
Container Isolation Mechanism
| Mechanism | What It Isolates | Kernel Feature |
|---|---|---|
| Namespaces | PID (processes), Network, Mount (filesystem), UTS (hostname), IPC (inter-process communication), User | Linux kernel namespaces β each container has its own view |
| cgroups | CPU, memory, disk I/O, network bandwidth resource limits | Linux cgroups v2 β prevents resource exhaustion (DoS) by noisy neighbors |
Critical distinction: Containers share the host kernel β they do NOT have full OS isolation like VMs. A kernel vulnerability affects ALL containers on the host simultaneously. VMs have separate kernels per VM (full isolation) but consume more resources. Container isolation is shallower than VM isolation.
Kubernetes Security Controls
| Control | What It Does | Platform C Configuration |
|---|---|---|
| RBAC | Role-based access control for Kubernetes API β who can do what in which namespace | Least privilege roles: developers get read-only on production namespace |
| NetworkPolicy | Layer 3/4 firewall for pod-to-pod traffic β default-deny + explicit allow rules | Default-deny ingress AND egress on all namespaces; explicit allow for service mesh traffic |
| Pod Security Standards | Admission control: Privileged (no restrictions), Baseline (prevents known escapes), Restricted (hardened) | Production namespace: Restricted (no root, no privileged containers, read-only root filesystem) |
| OPA / Gatekeeper | Policy-as-code admission controller β enforce custom rules at admission time | Block deployments without resource limits, block images from unregistered registries |
| Image Signing (cosign) | Cryptographically signs container images β verify provenance before admission | CI/CD pipeline signs images; Gatekeeper rejects unsigned images in production |
Container Registry Security
Image Scanning
Scan images for known CVEs before deploying. Tools: Trivy (Platform C uses in GitHub Actions), Snyk, Grype. Pipeline exits with code 1 on Critical severity findings β blocks deployment.
Digest Pinning vs. Tags
Tags are MUTABLE β :latest or :v1.2 can be overwritten. Digests are immutable SHA-256 hashes. Always pin to digest in production (image@sha256:abc...).
Exam Tips β Virtualization & Cloud
- Type 1 hypervisor (bare-metal) has SMALLER attack surface than Type 2 β no host OS layer to compromise. Cloud providers (AWS, GCP, Azure) use Type 1.
- VM escape = most severe VM vulnerability β guest breaks out to host hypervisor or other VMs. Patch hypervisors immediately when escape vulnerabilities are disclosed.
- Customer ALWAYS owns their data in cloud β even in SaaS, the provider never takes responsibility for the customer's data content. Data classification and access control = customer responsibility.
- Containers share the kernel β not as isolated as VMs. A kernel exploit can escape all containers on the node simultaneously. VMs provide stronger isolation but use more resources.
- Snapshot reversion bypasses security patches β reverting to a snapshot from 3 months ago re-applies all vulnerabilities patched since then. Treat snapshot reversion as a security event requiring re-patching.
FinTech Company X Work Application β Platform C Kubernetes Security Checklist
NetworkPolicy default-deny: All production namespaces have a default-deny NetworkPolicy for BOTH ingress AND egress. Services must explicitly open the ports they need. Verify with
kubectl get networkpolicy -A.Pod Security Standards: Production namespace enforces
Restricted profile β no root containers (runAsNonRoot: true), read-only root filesystem, dropped all capabilities.Trivy image scanning: GitHub Actions pipeline runs Trivy on every image build. Pipeline fails (exit code 1) on any Critical severity CVE. Results uploaded to GitHub Security tab.
No containers running as root: Audit all Deployment YAMLs for
securityContext.runAsUser: 0 or missing runAsNonRoot. Use OPA Gatekeeper to block root containers at admission.Vault Agent for secrets: All secrets injected via Vault Agent Injector sidecar β never stored as Kubernetes Secrets (base64 is not encryption) or environment variables visible in pod spec.
GKE node hardening: Node pools use Container-Optimized OS (COS β Google-hardened minimal OS). Shielded GKE nodes enabled (vTPM + Secure Boot). Auto-upgrade enabled for node security patches.
Shared responsibility reminder: Platform C on GCP (GKE = PaaS) β Google patches the GKE control plane and node OS. FinTech Company X is responsible for items 1-6 above. The PII incident was a customer responsibility failure (data encryption), not a GCP failure.
Practice Questions
Q1. A cloud data center uses VMware ESXi to run thousands of VMs directly on physical servers without any host OS. A developer's workstation uses VirtualBox to run test VMs on top of Windows. Which has a smaller attack surface and why?
A. VMware ESXi (Type 1) β it runs directly on hardware with no host OS layer, so an attacker cannot compromise a host OS to reach the hypervisorType 1 hypervisors run directly on bare metal and are the only software layer between hardware and VMs. Type 2 hypervisors (VirtualBox on Windows) require the attacker to compromise either the hypervisor directly OR the host OS, which then provides another path to the hypervisor and other VMs. Data centers always use Type 1 (ESXi, Hyper-V, KVM) for this reason. Type 2 is acceptable for developer workstations where the reduced attack surface is less critical.
Q2. A malicious actor running code in a guest VM is able to execute code on the hypervisor host and access other VMs on the same physical server. What type of attack is this?
A. VM Escape β a guest VM breaks out of the virtualization boundary to access the hypervisor or other guest VMsVM Escape is the most severe virtual machine vulnerability. VMs are supposed to be isolated from each other and the host. A VM escape exploits a vulnerability in the hypervisor or VM tools to break out of the isolation boundary. This can give an attacker access to the host hypervisor (with full control over all VMs) or the ability to read memory from other VMs on the same host. Critical hypervisor patches (e.g., VMware CVEs) should be applied immediately for this reason.
Q3. Platform C runs on GKE (Google Kubernetes Engine). A customer's PII was exposed due to a missing encryption configuration in the application's ORM layer. GCP claims no responsibility for the exposure. Who is correct?
A. GCP is correct β data encryption at the application level is the customer's responsibility in the PaaS shared responsibility modelIn PaaS (GKE), GCP is responsible for hardware, network, hypervisor, and node OS. The customer (FinTech Company X) is responsible for the application code, data classification, and data encryption. GCP provides infrastructure-level encryption (disk encryption at rest) but application-level encryption of sensitive fields (PII) is explicitly the customer's responsibility. This is the exact root cause of the Platform C PII incident β a customer responsibility failure, not a provider failure.
Q4. A security engineer compares Docker container isolation to VM isolation. Which statement is accurate?
A. Containers share the host kernel β a kernel vulnerability can compromise all containers on the host; VMs have separate kernels and provide stronger isolationDocker containers use Linux namespaces and cgroups for isolation, but they share the host kernel. If a kernel exploit is discovered, all containers on that node are potentially vulnerable. VMs run separate OS kernels β a kernel vulnerability in one VM does not affect other VMs on the same host. This is why high-security workloads often use VMs (or kata containers which run containers in lightweight VMs) rather than standard containers. The trade-off: containers are faster and lighter, VMs are more isolated.
Q5. A production Kubernetes cluster runs a critical financial application. During an emergency fix, an operations engineer reverts a VM snapshot taken before the last security patch cycle (2 months ago). What is the security risk?
A. Snapshot reversion undoes all security patches applied since the snapshot β the reverted system is now vulnerable to any CVEs that were patched in the last 2 monthsVM snapshots capture the entire state of the system at a point in time. Reverting a snapshot rolls back all changes β including OS patches, security updates, configuration hardening, and application updates. A 2-month-old snapshot will be missing potentially dozens of security patches. After snapshot reversion, the system must be immediately re-patched before being exposed to the network. Snapshot reversion to production should require a security review and immediate patch remediation plan.