Kubernetes Security & Cluster Hardening
Secure a cluster the way attackers try to break it. Learn the NSA/CISA threat model, control-plane and etcd hardening, authentication and audit, and image supply-chain and runtime defense — and remember it with spaced repetition.
- flashcards
- 82
- flashcards
- per day
- ~10 min
- per day
- level
- Intermediate → Advanced
- level
- modules
- 6
- modules
Why harden a Kubernetes cluster?
A default Kubernetes cluster is built for convenience, not for defense. The NSA and CISA hardening guidance is blunt about where compromise comes from: the supply chain, malicious threat actors, and insider threats. Beyond stealing data, clusters are prized for their raw compute — cryptojacking and denial of service are common goals — so hardening is about shrinking the attack surface across every layer.
The control plane is the crown jewels. The API server is the single front door to everything, and etcd holds every Secret in the cluster, so securing authentication, authorization and audit logging is where hardening starts. Getting authorization wrong — for example running the API server with --authorization-mode=AlwaysAllow — throws away least privilege entirely.
This track breaks cluster hardening into bite-sized, practical questions: the threat model and control-plane hardening, authentication, authorization and audit, and supply-chain, runtime and lifecycle hardening (Pod Security Standards, non-root vs rootless, image scanning) — and uses spaced repetition so the defenses stick when it matters.
Three further modules are written against the KCSA exam blueprint: the cloud native security model (the 4Cs, lifecycle phases, isolation techniques and the frameworks security is measured against), component-by-component security for the kubelet, controller manager, PKI and service account tokens, and an explicit Kubernetes threat model — trust boundaries, persistence, denial of service and privilege escalation. The Kubernetes and Cloud Native Security Associate guide maps this track and its companion decks onto the six KCSA domains.
6 modules, seed to bloom
Each module is a set of flashcards — 82 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Cloud Native Security Model
The 4Cs, lifecycle phases, isolation techniques, and the frameworks security is measured against
15 cardsThreat Model & Control-Plane Hardening
NSA threat model, API server and etcd, kubeconfig, worker-node segmentation, cloud metadata
12 cardsKubernetes Threat Model
Trust boundaries, persistence, denial of service, privilege escalation and lateral movement
15 cardsCluster Component Security
Kubelet, controller manager, PKI, service account tokens and the components' own defaults
16 cardsAuthentication, Authorization & Audit
User authentication, anonymous requests, authorization modes, audit policy levels and backends, log resilience
12 cardsSupply Chain, Runtime & Lifecycle Hardening
Pod Security Admission, image scanning, sandboxed runtimes, seccomp, resource limits, TLS, encryption at rest, service mesh, CIS benchmarks
12 cardsSample questions
A taste of the real flashcards. Pick an answer, then reveal the explanation.
According to NSA/CISA, what are the three most common sources of Kubernetes cluster compromise?
- ASupply chain risks, malicious threat actors, and insider threats — the guide's three vectors
- BDenial-of-service floods, weak passwords, and outdated TLS — generic perimeter weaknesses
- CMisconfigured Ingress, exposed dashboards, and default namespaces — common cluster mistakes
- DContainer drift, image bloat, and noisy-neighbor contention — operational hygiene problems
Why is leaving the API server's --authorization-mode=AlwaysAllow dangerous?
- AIt approves every authorization request, effectively disabling authorization and least privilege
- BIt forces every incoming request to fall back to anonymous authentication on the secure port
- CIt disables TLS on the API server, so all authorization traffic is sent unencrypted over 6443
- DIt deletes all existing RBAC Roles and RoleBindings the next time the API server is restarted
Which three policy levels do the Pod Security Standards define?
- APrivileged, Baseline, and Restricted — from fully unrestricted to a hardened best-practice policy
- BTrusted, Limited, and Locked — escalating tiers applied per namespace by the admission webhook
- COpen, Guarded, and Sealed — three presets that map directly to Linux capability bitmask sets
- DLow, Medium, and High — severity bands the API server assigns to each Pod's security context
What is the difference between a non-root container and a rootless container engine?
- AThe app runs as a non-zero UID inside the container, versus the whole runtime running unprivileged
- BThe container drops all Linux capabilities, versus the engine running as a privileged DaemonSet
- CThe container uses a read-only root filesystem, versus the engine encrypting every image layer
- DThe container runs with no ServiceAccount token, versus the engine bypassing the API server
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why cluster hardening is worth your time
Defend the whole attack surface
Hardening spans the control plane, identity, workloads and images — knowing the model lets you secure each layer deliberately.
Grounded in real guidance
The deck follows the NSA/CISA Kubernetes Hardening Guide, so you learn the threat model practitioners actually design against.
Least privilege by default
Understanding RBAC, authentication modes and Pod Security Standards is how you stop one mistake from owning the cluster.
CKS-aligned
Control-plane hardening, audit, supply chain and runtime security map closely to the Certified Kubernetes Security Specialist domains.
Common questions
Do I need to know Kubernetes first? +
Yes — this track assumes you already understand Pods, Deployments, Services and RBAC. If the primitives are new, start with the Kubernetes Fundamentals track, then come here.
Is this based on the NSA/CISA hardening guide? +
Yes. The threat model, control-plane and etcd hardening, and supply-chain and runtime guidance follow the NSA/CISA Kubernetes Hardening Guide and current Pod Security Standards.
Does this prepare me for the CKS? +
Gnoseed is a study companion, not a course or exam dump. These cards map closely to the CKS security domains, so they complement hands-on labs by making the concepts stick in long-term memory.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
Ready to harden Kubernetes?
Plant your first seed today. Ten minutes a day is all it takes to grow real, lasting cluster-security instincts.