Command Palette

Search for a command to run...

Hectal
Phase 5Advanced6 of 10 in Kubernetes

Security

Who can do what to the cluster, what a container is actually allowed to do once it's running, and the guardrails that block a bad manifest before it's ever scheduled.

A cluster with no security configuration lets any pod reach any other pod (Phase 3.3 already covered this), any user with cluster access do anything, and any container run as root with full privileges. This phase covers the four layers that actually lock that down: who can act on the API, what a running container can do, how real secrets get managed safely, and the admission checks that enforce all of it automatically.

0/4 · 0%
4 topics ~56 min 12 code blocks & diagrams
Start with the first topic
1
5.1

RBAC & ServiceAccounts

RBAC decides who (or what) is allowed to do what to the cluster's API — Roles define permissions, RoleBindings grant them to a specific user or ServiceAccount, and least privilege applies exactly as it does everywhere else in this course.

14 min 1 diagram 2 code practice

2
5.2

Pod Security & SecurityContext

By default, a container can run as root with broad Linux capabilities — a SecurityContext is how you lock that down per-pod or per-container, and Pod Security Standards enforce a baseline across an entire namespace.

14 min 3 code practice

3
5.3

Secrets Management in Kubernetes

A raw Kubernetes Secret is a reasonable starting point, but real production secrets management means access-controlling who can read them, never committing them to Git, and often integrating an external secrets manager entirely.

14 min 1 diagram 2 code practice

4
5.4

Admission Controllers

An admission controller intercepts every request to the API server AFTER authentication and authorization but BEFORE it's actually persisted — the layer that can automatically validate or even modify a resource before it ever takes effect.

14 min 1 diagram 2 code practice