Lion Cipher Lab

Secure Kubernetes pods with a securityContext

• Cloud Security
• Intermediate
• ~45 min
• Free · no account required

Why it matters

By default, a Kubernetes pod is far more privileged than almost any app needs: the container often runs as root, can write its whole filesystem, keeps a broad set of Linux capabilities, and is allowed to escalate privileges. None of that is malicious — the defaults are tuned to make things start, not to make them safe — but it means that if an attacker ever gets code execution inside a container, they inherit a strong starting position for breaking out toward the node or the rest of the cluster. A securityContext is the per-pod, per-container set of switches that takes those privileges away:…

What you'll learn

• what a pod, container, capability, privilege escalation, and seccomp actually are
• why a default Kubernetes pod runs far more privileged than it needs to
• writing a hardened pod/container securityContext (runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation:false, drop ALL capabilities, seccompProfile RuntimeDefault)
• applying manifests with kubectl apply and verifying the result with kubectl exec
• proving a container can no longer run as root or write its root filesystem
• enforcing a baseline cluster-wide with Pod Security Admission (restricted profile)
• knowing securityContext is one layer, and testing which apps break under readOnlyRootFilesystem

Steps in this lab

1. The words first: pod, container, node
2. Why a default pod is too privileged
3. Deploy a default pod and prove it runs as root
4. What a securityContext is, switch by switch
5. Apply a hardened securityContext
6. Prove it: no longer root, can no longer write the root FS
7. Enforce it cluster-wide with Pod Security Admission
8. The reality: one layer, and some apps break — so test

Open the full interactive lab →