Memory hook: Remove privileges, reduce syscalls, constrain filesystem access.
Must remember
Minimize host packages, daemons, remote access and unnecessary network listeners. Patch the OS/runtime, protect SSH/admin access and audit changes. Containers share a host kernel in ordinary runtimes; container isolation is not automatically a VM boundary.
Linux capabilities divide some root privileges. Drop unneeded capabilities and add only a demonstrated requirement. allowPrivilegeEscalation: false limits gaining more privilege through supported mechanisms; privileged containers and host namespace/mount access greatly expand exposure. A read-only root filesystem reduces writable paths but applications still need explicitly provided writable locations.
seccomp filters system calls. AppArmor applies mandatory access-control profiles to supported processes/resources. They address different layers and require supported node configuration. Start from an appropriate runtime/default profile and refine with evidence; denying a required syscall can break a legitimate application.
For current APIs, locate securityContext.seccompProfile and securityContext.appArmorProfile. RuntimeDefault selects the relevant runtime profile; Localhost refers to a profile already available on the node. A seccomp localhost profile is a path relative to the kubelet's seccomp directory; an AppArmor localhost profile names a loaded profile. Confirm support on every eligible node: a valid YAML field does not install the required host profile.
Run as a suitable non-root UID/GID, constrain filesystem permissions and use runtime isolation such as a supported sandbox/RuntimeClass when the threat model warrants it. A RuntimeClass references an installed configured runtime handler; writing its name does not install a sandbox. Stronger multitenancy may require separate nodes or clusters in addition to namespace controls.
Verification drill: inspect the live Pod security context, selected runtime and node support; exercise normal application behavior, then confirm a prohibited action is denied in a disposable environment.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Reduce syscall attack surface | An appropriate seccomp profile. |
| Constrain supported filesystem/process access | AppArmor profile with node support. |
| Untrusted workload needs a stronger boundary | Evaluate supported sandboxed runtime or stronger infrastructure separation. |
Traps
- Non-root is one control, not a complete security boundary.
- RuntimeClass does not install its runtime handler.
Active recall
1. What does seccomp restrict?
System calls available to the process.
2. What is a Linux capability?
A separated privileged operation that can be granted/dropped more narrowly than full root.
3. Why use a read-only root filesystem?
To reduce unauthorized modification/persistence, with explicit writable volumes where needed.
4. Why test after hardening?
A security profile can block legitimate required operations.
5. Why can namespaces alone be insufficient?
They do not automatically isolate the shared kernel, nodes or every network/identity path.