Chapter 6 — Operating systems and virtualization
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Virtual machines"]
N2["6.2 Containers"]
N3["6.3 Isolation differences"]
N4["6.4 Images"]
N5["6.5 Tags and digests"]
N6["6.6 Running as root"]
N7["Hosts and nodes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Virtual machines"]
N2["6.2 Containers"]
N3["6.3 Isolation differences"]
N4["6.4 Images"]
N5["6.5 Tags and digests"]
N6["6.6 Running as root"]
N7["Hosts and nodes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Virtual machines]
|
v
[6.2 Containers]
|
v
[6.3 Isolation differences]
|
v
[6.4 Images]
|
v
[6.5 Tags and digests]
|
v
[6.6 Running as root]
|
v
[Hosts and nodes]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) explain virtual machines and containers; (2) compare their isolation; (3) describe what a container image contains.
6.1 Virtual machines
A virtual machine runs a full operating system on shared hardware, separated by a hypervisor. Cloud providers use this to run many customers on the same physical machine. Each virtual machine has its own kernel, so a flaw in one guest's operating system does not directly reach the others; the hypervisor is the shared layer that must hold. Cobalt rarely manages hypervisors itself, because providers run them, but the cluster nodes it does manage are virtual machines. Ristenpart et al. (2009) showed that even this separation can leak information between tenants on the same physical machine, so shared hardware is never treated as perfect isolation.
6.2 Containers
A container packages an application with the files it needs and runs it as an isolated process on a shared kernel. Containers start quickly and are small, which is why Cobalt uses them. For Cobalt, the speed matters: a rebuilt booking image can replace the old containers within minutes, which is what makes fixing an advisory quick once the affected workloads are known. The same property cuts the other way, because a container started from an outdated image starts just as quickly and nothing in the runtime warns that the image is old.
6.3 Isolation differences
Containers share the host kernel, so their isolation is weaker than separate virtual machines. NIST SP 800-190 advises grouping containers of similar sensitivity on the same hosts and keeping the host operating system minimal. Cobalt's cluster layout follows this advice only partly, for reasons of cost. Large clients have their own clusters, so their containers never share nodes with another client's, while smaller clients share a cluster and are separated by namespaces and network policies. Priya notes that namespace separation is an administrative boundary, not a kernel one, which is one reason pod security settings on the shared cluster matter so much.
6.4 Images
An image is a layered file bundle from which containers start. It includes a base layer, often a small operating system, plus the application. The advisory affected the base layer, so every image built on it was affected. Layers are reused: when a team builds an image, it usually starts from a base image published by someone else and adds its own files on top. That reuse saves time but spreads any flaw in the base to every image built on it, and nothing in the final image name reveals which base it used. Answering the advisory therefore needs records of base images, not only application images.
6.5 Tags and digests
A tag such as node:14 is a label that can be moved; a digest identifies exact content. Recording digests gives a reliable answer to "what exactly is running?" The difference matters for evidence. If the registry owner moved node:14 to new content after the advisory, a record that says only node:14 cannot show which version was running before. A digest is a hash of the image content, so the same digest always means the same bytes. Priya records the tag for readability and the digest for proof, and she later blocks the latest tag in the pipeline for the same reason.
6.6 Running as root
Containers that run as root give more power to anyone who compromises them. Kubernetes Pod Security Standards discourage it in the Restricted profile. Root inside a container is not automatically root on the node, but it removes a barrier: a compromised root process can change files in the container, install tools and, combined with a kernel flaw or a loose setting, reach further. Running as an ordinary user limits what a compromise can do. Priya's later warn-mode check finds that the reports workload runs as root, and fixing it requires a change to the image rather than to the cluster.
Hosts and nodes
In Kubernetes, the machines that run containers are called nodes. Keeping nodes updated matters because a kernel flaw affects every container on that node.
Worked example
Priya inspects the booking workload's image record and sees it uses node:14 by tag. She looks up the digest from the registry and records both. Kwame explains that because the tag could have been moved, only the digest proves which content was running on the day of the advisory.
Synthetic case. Image names are synthetic.
Errors and limits
Container isolation is useful but not equal to virtual machine isolation.
Exercises
- EX016 — Shared kernel. Why is container isolation weaker than VM isolation? Rubric: 3 = containers share the host kernel; 2 = partial; 1 = vague; 0 = none.
- EX017 — Base layer impact. Why were many images affected by one advisory? Rubric: 3 = shared base layer; 2 = partial; 1 = vague; 0 = none.
- EX018 — Digest value. What does a digest prove that a tag does not? Rubric: 3 = exact content; 2 = partial; 1 = vague; 0 = none.
Synthesis
Know what is inside an image and pin it by digest when evidence matters.
Continue studying — chapter 06 of 30
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →