Chapter 07: Security Context & Pod Hardening
Learning Objectives
By the end of this chapter, you will be able to:
- Explain what each setting of the platform’s security context takes away from a process that has been taken over - and what it does not
- Tell the layers apart: Pod Security at admission, the security context in the container, the check in the pull request
- Prove the hardening of a running pod with commands, not with a manifest
- Fix a “Read-only file system” failure with a size-limited writable volume, and tell it from a “Permission denied” - without ever reaching for root
Recall Check
Before continuing, quickly recall:
- Which namespaces may the everyday sign-in write to, and which only read? (Chapter 01)
- Which check runs every hook again on every pull request? (Chapter 05)
- A pod in
developis taken over. Which connections can it still open, and which can it not? (Chapter 06)
If you can’t answer these, revisit the corresponding chapter before proceeding.
Context
Chapter 06 limited where a pod may connect. This chapter limits what a process may do inside its container - on the day it is no longer yours. A bug in a library, a dependency with a known vulnerability, a request the code did not expect: an attacker gets to run commands as the application’s process. What they can do next depends on what that process is allowed to do.
By default a container is generous. It runs as root, keeps a set of Linux capabilities, may gain more privileges through setuid programs, can write to every file of its image, and finds a token for the Kubernetes API in a well-known file. None of that is a door to the node by itself - but each one is a tool the attacker does not have to bring.
The platform takes those tools away from every app container: a user that is not root, a root filesystem that cannot be written, no privilege escalation, no capabilities, the kernel’s default seccomp filter, no service account token. Where an app must write, the path is declared: a small volume with a size limit. Pod Security refuses a pod without most of these at the door of the cluster; a check refuses the same regression in the pull request.
The price is real, and the chapter does not hide it: an app that writes somewhere nobody declared fails on its first write. That failure is loud, and the fix is one volume. The failure the hardening prevents is quiet - an attacker who had everything they needed.
Work through each lesson section; the chapter video, once it is published, gives the concept overview.
Three Layers, One Container
