Chapter 11 — Operating systems | Bachelor's Cloud and container security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 11 — Operating systems

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Containers are processes"]
  N2["11.2 Users"]
  N3["11.3 Capabilities"]
  N4["11.4 File systems"]
  N5["11.5 Pod Security Standards"]
  N6["11.6 Patching"]
  N7["11.7 Checking"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Containers are processes"]
  N2["11.2 Users"]
  N3["11.3 Capabilities"]
  N4["11.4 File systems"]
  N5["11.5 Pod Security Standards"]
  N6["11.6 Patching"]
  N7["11.7 Checking"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Containers are processes]
    |
    v
[11.2 Users]
    |
    v
[11.3 Capabilities]
    |
    v
[11.4 File systems]
    |
    v
[11.5 Pod Security Standards]
    |
    v
[11.6 Patching]
    |
    v
[11.7 Checking]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain how containers rely on Linux features; (2) describe users, permissions and capabilities in containers; (3) apply secure defaults to StudyHub pods; (4) recognise risky settings.

11.1 Containers are processes

A container is a group of processes isolated by Linux namespaces and limited by control groups. It shares the node's kernel, so settings that weaken isolation affect the whole node.

Because the kernel is shared, a container started with privileged settings or with the node's process namespace can see or affect other workloads on the same node. In StudyHub, several services from different teams share nodes, so one weak pod could expose others. The settings below limit what each container's processes can do.

11.2 Users

Many images run as root by default. Running as a non-root user means that a flaw in the application gives less power inside the container and less chance to affect the node.

Running as root inside a container is not the same as root on the node, but it removes barriers an attacker would otherwise face. A non-root process cannot change system files in the image or bind to low ports, and it gives fewer options if a kernel flaw allows escape. StudyHub's images now set a dedicated user in their build files.

11.3 Capabilities

Root powers are split into capabilities. Most web services need none; dropping all and adding only what is required is the secure default recommended by NIST SP 800-190.

StudyHub's web services listen on high ports and write only to mounted volumes, so they need no capabilities at all. One service that adjusts network settings for diagnostics needs a single capability, which is documented with its reason. Starting from none and adding only what is needed makes each exception visible in the pod specification.

11.4 File systems

A read-only root file system prevents changes to the application files at run time; temporary data goes to mounted volumes.

If an attacker exploits a flaw in records-api, a read-only root file system stops them from replacing the application's code or adding tools to the image. Temporary files go to a small volume that is discarded when the pod stops. Some images needed changes to write their caches to the volume, which the team tested before enforcing the setting. The volume is sized small on purpose.

11.5 Pod Security Standards

Kubernetes defines Privileged, Baseline and Restricted profiles. Restricted requires non-root, no privilege escalation, dropped capabilities and a seccomp profile. StudyHub targets Restricted for all application namespaces.

Baseline blocks the most dangerous settings, such as privileged containers, while Restricted adds the stricter defaults described above. Targeting Restricted means StudyHub's application pods follow all of them. System components such as log collectors may need Baseline or Privileged, and those namespaces are kept separate with documented exceptions. Namespace labels set which profile applies, so the enforcement level is visible in the cluster configuration and can be reviewed like any other setting.

11.6 Patching

Base images include operating system packages that need updates; images are rebuilt regularly from patched bases.

StudyHub's images are rebuilt weekly from the latest patched base, and the image scanner reports known vulnerabilities in each new build. Rebuilding regularly means patches arrive without a separate project each time. Images that have not been rebuilt for more than a month appear in Samuel's checker as findings. Rebuilding also brings application dependencies up to date, which sometimes changes behaviour, so each rebuilt image runs through the test suite in the test cluster before it is promoted to production.

11.7 Checking

Samuel's checker reads pod specifications and reports settings that violate Restricted.

The checker reads each pod's security context and reports, for example, "records-api: runs as root; root file system writable". It found the nine root pods described in the worked example below. Running the check before enforcement showed the scale of the work, so the team could plan it rather than discovering failures at admission. Each finding names the pod, its namespace and the exact field that breaks the profile, so owners know what to change. The checker runs weekly, and the list of root pods fell sprint by sprint as images were rebuilt.

Admission enforcement

Once pods comply, the Restricted profile is enforced at admission for application namespaces, so new non-compliant pods are rejected with a clear message. System namespaces keep documented exceptions with an owner and review date.

Worked example

The check finds that 9 of 31 StudyHub pods run as root, mostly because their images never set a user. Rebuilding the images with a non-root user and testing them in the test cluster takes two sprints; afterwards all application pods meet Restricted.

Synthetic case. Pods and counts are synthetic.

Errors and limits

Some system components need more privileges; isolate them rather than weakening the profile everywhere.

Exercises

EX031 — Shared kernel. Why do isolation-weakening settings affect the node? Rubric: 3 = containers share kernel; 2 = partial; 1 = vague; 0 = none.
EX032 — Restricted requirements. Name three Restricted requirements. Rubric: 3 = non-root, no escalation, dropped caps, seccomp; 2 = two; 1 = one; 0 = none.
EX033 — Root pods. How many pods ran as root and why? Rubric: 3 = 9 of 31; no user set; 2 = partial; 1 = vague; 0 = none.

Synthesis

Containers should run with minimal privileges by default.

Continue studying — chapter 11 of 40

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →