rootnode-academy/content/root/root-09-kubernetes-security/m01-security-model-and-securitycontext/01-lesson-security-model.md

Defense in Depth & the Kubernetes Security Model

Security is a posture, not a single setting

There is no single "make it secure" switch in Kubernetes. Real security comes from defense in depth — multiple independent layers, each reducing what an attacker (or a bug) can do if an earlier layer fails. If a container has a vulnerability that lets an attacker execute arbitrary code, the question that actually matters is: what can that code DO once it's running? A container running as root, with every Linux capability, on a writable filesystem, with no restrictions at all, can do far more damage than one deliberately hardened to need almost nothing.

Least privilege: grant only what's actually needed

The organizing principle behind everything in this course is least privilege: a workload should have exactly the permissions and capabilities it needs to do its job, and nothing more. This sounds obvious stated plainly, but the DEFAULT behavior of a plain container is closer to "maximum privilege unless told otherwise" — root user, all standard Linux capabilities, a writable filesystem. Hardening a Pod means deliberately narrowing that down.

SecurityContext: where you actually configure this

securityContext (settable at the Pod level and per-container) is where you declare these restrictions:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    securityContext:
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

• runAsNonRoot / runAsUser — the container process runs as a specific non-root user instead of root. If a container image was built to require root and you set this, it will fail to start — which is a good, loud failure, not a silent security gap. Hardening sometimes surfaces an image's OWN bad assumptions.
• capabilities: drop: ["ALL"] — Linux capabilities are fine-grained permissions (NET_BIND_SERVICE, SYS_ADMIN, dozens more) a process can hold even without full root. Dropping all of them, then adding back only the specific ones actually needed, is the least-privilege pattern applied to capabilities specifically.
• readOnlyRootFilesystem: true — the container's own filesystem cannot be written to at all (use an explicit emptyDir volume, ROOT 08, for anything that genuinely needs to write temporary files). This closes off a whole category of attack that relies on writing a malicious file to disk.

Why this matters even when "nothing is currently wrong"

None of these settings fix a bug or a vulnerability — they limit the BLAST RADIUS if one exists that you don't yet know about. A container hardened with non-root, dropped capabilities, and a read-only filesystem gives a successful exploit dramatically less to work with than an unhardened one, even against the exact same vulnerability. This is the entire point of defense in depth: you don't rely on any single layer being perfect.

Instructor Notes

Approximate timing: 15 minutes read; 10-12 minutes live with the demonstration.

Demo plan: Have the demonstration activity ready to run right after this lesson — seeing a concrete before/after Pod definition lands the abstract "least privilege" principle far better than the lesson text alone.

Likely misconceptions to watch for:

• Students sometimes think hardening settings are only relevant "if you expect to be attacked." Reframe: defense in depth assumes SOMETHING will eventually go wrong somewhere (a vulnerability, a bug, a misconfiguration) and prepares for that, rather than betting everything on nothing ever going wrong.
• runAsNonRoot: true failing a Pod's startup is sometimes read as "the security setting is broken." It's the opposite — it's correctly refusing to let a root-requiring image start, which is valuable, actionable information about the image itself.

Discussion question: "If dropping all capabilities breaks a container that turns out to genuinely need one specific capability, what's the right fix — removing the drop, or something more targeted?" (Answer: add back only that ONE specific capability rather than removing the blanket drop — least privilege means "exactly what's needed," not "give up and grant everything again.")

Optional extension: ask students to identify one setting from this lesson that would have made zero difference against a vulnerability that lets an attacker read environment variables (a good check that they understand these are layered, not universal, protections — the answer is that none of SecurityContext's settings here directly protect secrets stored in env vars; that's a different concern, covered later in this course).