Security Best Practices
Cluster security is layered, and the layers fail independently. This topic is the baseline that closes the common holes — the security equivalent of the production-readiness checklist, drawing the controls from Chapter 6 into one posture you can audit against.
No single control is security; the point is defense in depth, so that a gap in one layer is caught by another. Skip one and a compromise that should have been contained spreads.
Least-Privilege Identity
Start at the API. Use RBAC scoped to the minimum each subject needs — no cluster-admin by default, no wildcard verbs, no binding to system:authenticated (Topic 32). Give every workload its own least-privilege ServiceAccount and disable token automount where API access isn't needed (Topic 33). Federate human access through OIDC and Pod-to-cloud access through workload identity, so there are no long-lived credentials to leak.
Workload Hardening
Constrain what Pods can do. Apply the Restricted Pod Security Standard where feasible (Baseline at minimum) via Pod Security Admission, and set the matching securityContext: run as non-root, drop all capabilities, read-only root filesystem, no privilege escalation (Topic 34). A compromised container that cannot escalate, write its filesystem, or reach the host is a contained problem rather than a cluster-wide one.
Network and Data
Segment the network with a default-deny NetworkPolicy baseline plus explicit allows, on a CNI that actually enforces it (Topic 23) — so a compromised Pod cannot freely reach everything. Protect data: encrypt Secrets at rest with a KMS, scope get secrets tightly, and prefer an external secret store for high-value credentials (Topic 35). These two — network segmentation and secret protection — are where lateral movement and credential theft are stopped.
| Layer | Baseline control |
|---|---|
| Identity | Least-privilege RBAC; per-workload ServiceAccounts; OIDC/federation |
| Workload | Restricted PSS + hardened securityContext |
| Network | Default-deny NetworkPolicy + explicit allows |
| Data | Encrypt Secrets at rest; tight RBAC; external store |
| Supply chain | Signed, scanned, digest-pinned images |
| Audit | Audit logging enabled and monitored |
Supply Chain and Audit
Trust what runs: only signed, scanned, digest-pinned images from trusted registries, enforced at admission (Topics 36-37). Enable audit logging so API actions are recorded and monitored — you cannot investigate what you didn't log. The full posture is the sum: least-privilege identity, hardened workloads, segmented network, protected data, trusted supply chain, and audit. Each closes a class of attack; together they are defense in depth. Audit your cluster against this list, not against whether it merely works.
Single control — e.g. tight RBAC alone — leaves the other layers open; one bypass and the attacker has the cluster.
Defense in depth — identity + workload + network + data + supply chain + audit — a gap in one layer is caught by another.
- Granting
cluster-adminor wildcard RBAC for convenience. - Running privileged, root containers with no securityContext or Pod Security Standard.
- No NetworkPolicy (or a CNI that doesn't enforce it), leaving the network flat and open.
- Unencrypted Secrets and broad secret-read access.
- Running unsigned, unscanned, or
:latestimages with no admission enforcement.
- Apply least-privilege RBAC and per-workload ServiceAccounts; federate identity, no long-lived keys.
- Enforce Restricted Pod Security and a hardened securityContext.
- Adopt a default-deny NetworkPolicy baseline on an enforcing CNI.
- Encrypt Secrets at rest, scope access tightly, and use an external store for high-value secrets.
- Admit only signed, scanned, digest-pinned images, and enable audit logging.
Knowledge Check
Why is defense in depth the goal rather than one strong control?
- Layers fail independently; multiple controls mean a gap in one is caught by another
- A single tightly scoped control is always sufficient protection on its own
- It reduces the number of security controls you need to configure and maintain down to a single one
- Kubernetes only supports one security control active at a time
What is the network-layer baseline for cluster security?
- A default-deny NetworkPolicy plus explicit allows, on a CNI that enforces it
- Leaving the flat pod network fully open between all namespaces for operational simplicity
- A single LoadBalancer Service fronting all cluster traffic
- Disabling cluster DNS entirely to limit reachable endpoints
Which image policy belongs in the security baseline?
- Only signed, scanned, digest-pinned images from trusted registries, enforced at admission
- Always pull the :latest tag with an imagePullPolicy of Always so every Pod runs the freshest build
- Pull images directly from arbitrary public registries at container runtime
- Bake long-lived credentials into image layers for deployment convenience
You got correct