Skip to content

Isolation Techniques: KCSA practice questions

Isolation techniques decide how far a compromised workload can reach. Kubernetes documentation puts the baseline plainly: containers use OS-level virtualization and therefore offer a weaker isolation boundary than virtual machines that use hardware-based virtualization.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Isolation Techniques covers in KCSA

Isolation techniques decide how far a compromised workload can reach. Kubernetes documentation puts the baseline plainly: containers use OS-level virtualization and therefore offer a weaker isolation boundary than virtual machines that use hardware-based virtualization. Containers are processes on a shared kernel that mount file systems such as /sys and /proc from the host, so a kernel vulnerability or a careless configuration can let an attacker escape to the node and everything running on it.

Sandboxing is the answer when the code itself may be hostile. The multi-tenancy guide describes it as running each pod in a separate execution environment and names two popular approaches: virtual machines and userspace kernels. gVisor is the userspace-kernel example. Its Sentry component acts as the kernel for the container, services the application's system calls itself and does not pass them through to the host kernel, while a separate Gofer process mediates file system access. runsc, its runtime, implements the OCI runtime specification, which is how Docker and Kubernetes can use it. The trade-off gVisor documents is reduced application compatibility and higher per-system-call overhead.

The virtual-machine approach gives each workload its own kernel. Kata Containers runs containers inside lightweight virtual machines with a dedicated kernel and hardware-enforced isolation, supports the OCI image format and the Kubernetes CRI, and can use QEMU, Cloud Hypervisor or Firecracker as the hypervisor. Firecracker itself is a user-space process that uses Linux KVM to create microVMs with a minimal device model, a startup time under 125 ms and a memory footprint under 5 MiB, and it is built for running serverless functions and containers.

Multi-tenancy is the context where these choices are made. Kubernetes describes hard multi-tenancy as the case where tenants do not trust each other and soft multi-tenancy as weaker isolation, and stresses that the two are ends of a spectrum rather than fixed definitions. Within one cluster, namespaces scope RBAC Roles and NetworkPolicies, resource quotas limit what a tenant can create and reduce noisy-neighbor effects, and node isolation dedicates nodes to one tenant using taints, tolerations and node selectors. At the far end, each tenant gets a dedicated cluster, possibly on dedicated hardware when VMs are not considered an adequate boundary. Soft multi-tenancy suits trusted teams that want efficient sharing; untrusted tenants push toward sandboxes, dedicated nodes or separate clusters.

Several Pod settings quietly remove isolation, which is why the Baseline Pod Security Standard forbids them: sharing host namespaces through hostNetwork, hostPID or hostIPC; privileged containers, which disable most security mechanisms; and hostPath volumes, which is how a container runtime socket on the node would be mounted into a pod. Sharing a PID namespace lets processes see and signal each other. Mandatory access control adds a layer: since Kubernetes v1.30 an AppArmor profile is set with securityContext.appArmorProfile (type RuntimeDefault, Localhost with localhostProfile, or Unconfined); earlier releases used the container.apparmor.security.beta.kubernetes.io/<container> annotation.

Key points

  • gVisor intercepts system calls in a userspace kernel (the Sentry); it is not a virtual machine.
  • Kata Containers and Firecracker isolate workloads in lightweight VMs, each with its own kernel.
  • Hard multi-tenancy assumes tenants do not trust each other; the stronger end of the spectrum is a cluster per tenant.
  • Baseline Pod Security forbids hostNetwork, hostPID, hostIPC, privileged containers and hostPath volumes.
  • The pre-1.30 AppArmor annotation was container.apparmor.security.beta.kubernetes.io/<container-name>.

Three sample questions

8 KCSA questions on Isolation Techniques, 8 with explanations. How practice works

Question 1

What are the key characteristics of gVisor and Firecracker? (Select all that apply)

Select all that apply.

  1. A.gVisor is a user-space kernel providing sandboxing
  2. B.Firecracker uses lightweight microVMs with KVM
  3. C.Both provide full hardware virtualization
  4. D.Firecracker is a container runtime interface
  5. E.gVisor offers better performance than traditional VMs

Correct answers: A, B, E

gVisor provides sandboxing by running in user space and intercepting system calls, which enhances security without the need for full hardware virtualization. Firecracker uses microVMs, leveraging KVM for efficient isolation. gVisor can offer better performance compared to traditional VMs due to its lightweight nature.

Sources: gVisor Documentation, Firecracker Documentation

Question 2

What is the primary difference between MicroVM and User-Space Kernel approaches in cloud native security?
  1. A.MicroVMs are larger in size
  2. B.User-space kernels provide hardware virtualization
  3. C.MicroVMs run directly on hardware without a host OS
  4. D.User-space kernels intercept system calls in user space
  5. E.There is no difference; they are the same

Correct answer: D

The primary difference lies in how they operate. User-space kernels, like gVisor, run in user space and intercept system calls, providing a lightweight sandboxing mechanism. MicroVMs, on the other hand, are full-fledged virtual machines that run directly on hardware but require a host OS for management.

Sources: gVisor Documentation, MicroVM Overview

Question 3

In which scenarios is soft multi-tenancy preferred over hard multi-tenancy in cloud-native environments?
  1. A.When strict tenant isolation is mandatory
  2. B.For workloads from untrusted tenants requiring strong isolation
  3. C.To maximize resource utilization efficiency in trusted tenant environments
  4. D.When compliance with strict regulatory requirements is necessary
  5. E.When deploying workloads across multiple Kubernetes clusters

Correct answer: C

Soft multi-tenancy is preferred when tenants are trusted and strict isolation is not required, allowing for more efficient sharing of resources. Hard multi-tenancy, by contrast, enforces strict isolation suitable for untrusted tenants or compliance-driven environments. Therefore, soft multi-tenancy optimizes resource usage in trusted settings but is not suitable where strong isolation or regulatory compliance is mandatory.

Sources: Kubernetes Official Documentation - Multi-tenancy, CNCF - Multi-tenancy in Kubernetes

Practice this topic

Focus mode keeps every question on Isolation Techniques until you leave it. 10 free guest answers, then a free account; no credit card.

Or open KCSA practice across all topics.

Sources

The explanation above was checked against these official documents.