KCSA study guide

KCSA is the same shape as KCNA — 90 minutes, online proctored, multiple choice, no prerequisites — but a different question. KCNA asks what the components do. KCSA assumes you know that, and asks how each one fails, who can reach it, and what an attacker does once they have.

Six domains, and unlike KCNA the weight is spread fairly evenly. There is no single domain you can carry the exam on, and no domain small enough to skip.

Written before sitting it — this is a prep plan, not a retrospective.

Kubernetes Cluster Component Security — 22%

Official sub-topics: API server, controller manager, scheduler, kubelet, container runtime, KubeProxy, Pod, etcd, container networking, client security, storage.

The framing to hold onto: for each component, what does it authenticate, what can it reach, and what does an attacker get by owning it?

API server

The single front door, and therefore the single most valuable target. Everything hinges on the request pipeline: authentication → authorization → admission → persistence. Know that anonymous auth exists and should be off, that --insecure-port is long gone, and that the API server is the only component that should be talking to etcd.

etcd

Owning etcd is owning the cluster — every Secret, every ServiceAccount token, all state, and no audit trail of the read. So: mutual TLS between etcd and the API server, etcd on its own network segment, no other client, encryption at rest configured, and backups that are themselves treated as crown-jewel data. A stolen etcd backup is a full cluster compromise in a tarball.

kubelet

The most commonly misconfigured component. Its API can expose /exec and /run on every node. The specifics to know: the read-only port (10255) should be disabled, the authenticated port (10250) must require authn and authz (--anonymous-auth=false, --authorization-mode=Webhook), and the kubelet’s own credentials should be scoped by Node authorization plus the NodeRestriction admission plugin so a compromised node can only mutate its own objects.

Controller manager and scheduler

Lower-profile but privileged. Both hold credentials to the API server. The controller manager holds signing keys for ServiceAccount tokens — enough to mint an identity. Bind them to localhost, run them with their own least-privilege ServiceAccounts, and use --use-service-account-credentials so each controller loop gets a separate identity rather than one omnipotent one.

Container runtime and kube-proxy

The runtime (containerd, CRI-O) is the boundary between the workload and the kernel. Understand that container escape is fundamentally a kernel-boundary problem, which is why sandboxed runtimes (gVisor, Kata Containers) exist — they add a second boundary rather than hardening the first. kube-proxy runs privileged and manipulates iptables/IPVS; it is a trust-sensitive DaemonSet, which is an argument for eBPF-based dataplanes that shrink the privileged surface.

Pod

Where the securityContext lives. Know runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false, dropping all Linux capabilities and adding back only what is needed, and why privileged: true, hostNetwork, hostPID, and hostPath mounts are each a path off the Pod and onto the node.

Client security

kubeconfig files are credentials. Certificate lifetimes, avoiding long-lived cluster-admin certs, preferring short-lived OIDC tokens, and never shipping a kubeconfig into a container image or a CI variable that gets logged.

Kubernetes Security Fundamentals — 22%

Official sub-topics: Pod Security Standards, Pod Security Admissions, authentication, authorization, secrets, isolation and segmentation, audit logging, network policy.

Authentication

Kubernetes has no user objects. Identity arrives as an X.509 client certificate (the CN is the username, the O entries are groups), a bearer token, an OIDC token from an external identity provider, or a webhook. Workload identity is the ServiceAccount. Know that modern ServiceAccount tokens are short-lived, audience-bound projected volumes rather than the old never-expiring Secret, and that automountServiceAccountToken: false is the correct default for workloads that never call the API.

Authorization — RBAC

The centre of gravity for this domain. Role + RoleBinding are namespaced; ClusterRole + ClusterRoleBinding are cluster-wide; a RoleBinding referencing a ClusterRole grants those verbs inside one namespace only. Verbs: get, list, watch, create, update, patch, delete, deletecollection.

The escalation paths worth recognising on sight:

• create pods in a namespace ≈ the ability to run as any ServiceAccount in that namespace
• escalate and bind let a principal grant itself permissions it does not have
• list secrets is read-access to every credential in scope — list returns the values
• access to pods/exec is shell access to running workloads
• wildcard * on resources or verbs, in any binding, is the thing to flag

Know that ABAC and Node and Webhook authorizers exist alongside RBAC, and that authorization modes are evaluated in order with the first allow winning.

Pod Security Standards and Admission

Three profiles: privileged (unrestricted), baseline (blocks known privilege escalations), restricted (hardened — non-root, no privilege escalation, seccomp RuntimeDefault, all capabilities dropped). Applied by Pod Security Admission through namespace labels in three modes — enforce, audit, warn — each of which can pin a version. PSA replaced PodSecurityPolicy, removed in v1.25; expect at least one question that depends on knowing PSP is gone.

For anything beyond the three fixed profiles you need a policy engine — Kyverno or OPA Gatekeeper — running as a validating (and optionally mutating) admission webhook.

Secrets

Base64 is encoding, not encryption. By default Secrets sit in etcd in plaintext. The mitigations: encryption at rest via an EncryptionConfiguration (with a KMS provider rather than a local key), RBAC that does not hand out list on secrets, mounting as files rather than environment variables (env vars leak into crash dumps, /proc, and child processes), and external secret stores — Vault, cloud KMS, the Secrets Store CSI Driver — so the material never lands in etcd at all.

Isolation and segmentation

Namespaces are a scope for names and policy, not a security boundary on their own — they do not isolate the network or the kernel. Real segmentation comes from combining namespaces with RBAC, NetworkPolicy, ResourceQuota and LimitRange, and, where the threat model demands it, separate node pools or separate clusters. Know the multi-tenancy spectrum: soft multi-tenancy (namespaces plus policy, trusted tenants) versus hard multi-tenancy (separate clusters or sandboxed runtimes, untrusted tenants).

Network policy

Default is a flat, allow-all network. NetworkPolicy selects Pods by label and, once a Pod is selected by any policy for a direction, that direction becomes default-deny. Know how to express a default-deny-all baseline, how ingress and egress rules differ, that policies combine additively (there is no explicit deny), and — critically — that enforcement is the CNI’s job. A NetworkPolicy applied on a CNI that does not implement it is silently inert, which is the security failure mode that bites hardest in practice.

Audit logging

The audit policy defines what gets recorded and at which level: None, Metadata, Request, RequestResponse. Know that audit logs are the primary detection surface for a Kubernetes intrusion, that they must be shipped off-cluster (an attacker with cluster-admin can otherwise erase them), and that logging at RequestResponse on Secrets writes secret material into the log.

Kubernetes Threat Model — 16%

Official sub-topics: trust boundaries and data flow, persistence, denial of service, malicious code execution and compromised applications in containers, attacker on the network, access to sensitive data, privilege escalation.

This is the domain that rewards having actually thought about attacker paths rather than memorised flags. Work through each named attacker goal and ask what mechanism blocks it.

Trust boundaries. Draw them: internet → ingress; ingress → workload; workload → workload; workload → API server; node → control plane; control plane → etcd; and the whole cluster → cloud provider metadata endpoint. Each is a place where authentication should exist.

Persistence. How an attacker stays: a CronJob or DaemonSet they created, a mutating admission webhook that re-injects their container, a modified image in the registry, a ServiceAccount token they minted, a backdoored ClusterRoleBinding. Persistence in Kubernetes is almost always a legitimate object with malicious contents, which is why admission control and audit review matter more than file integrity monitoring.

Denial of service. A Pod with no limits starving a node; a namespace with no ResourceQuota consuming the cluster; unbounded API server requests. The controls are requests and limits, ResourceQuota, LimitRange, API priority and fairness, and PodDisruptionBudgets.

Malicious code execution. Attacker has code running in a container. What is reachable? The kernel (→ escape), the node filesystem via hostPath, the kubelet, the cloud metadata endpoint (→ node IAM credentials — block 169.254.169.254 in egress policy), the ServiceAccount token, and every other Pod on the flat network.

Attacker on the network. Sniffing east-west traffic, spoofing a Service, DNS manipulation. Controls: mTLS everywhere (service mesh or application-level), NetworkPolicy, and encrypted node-to-node transport.

Privilege escalation. The chain to be able to recite: container → node (escape or hostPath) → node’s kubelet credentials → other Pods’ secrets → a ServiceAccount with more RBAC → cluster-admin. Every hardening control maps to breaking one link in that chain.

Platform Security — 16%

Official sub-topics: supply chain security, image repository, observability, service mesh, PKI, connectivity, admission control.

Supply chain security is the largest idea here and the one with the most named projects. Know SBOM (SPDX, CycloneDX), image signing and verification with Sigstore / cosign, provenance attestations and SLSA levels, and the in-toto attestation framework. The enforcement point is an admission controller that rejects unsigned or unattested images — signing without verification at admission is theatre.

Image repository. Private registries with authenticated pulls, vulnerability scanning (Trivy, Grype, or Harbor as a CNCF registry that bundles scanning and signing), pinning by digest rather than mutable tags, minimal base images (distroless, scratch) to shrink the attack surface, and not baking secrets into layers — a deleted file in a later layer is still in the image.

Admission control as a platform capability: mutating webhooks run before validating ones, both run after authn/authz, and a failing webhook with failurePolicy: Fail can wedge the cluster — which is itself a denial-of-service consideration.

PKI. The cluster CA, what certificates exist (API server serving cert, kubelet client and serving certs, etcd peer and client certs, front-proxy), rotation, and certificate signing requests through the certificates.k8s.io API. Know that anyone who can approve CSRs can mint identities.

Service mesh in a security frame: mTLS between workloads, identity based on SPIFFE-style workload identity rather than IP, authorization policy at layer 7, and the sidecar-versus-ambient trade-off in operational and attack surface.

Observability as a security control, not just an ops one: audit logs, runtime security with Falco (syscall-level detection of anomalous container behaviour), and the fact that detection only helps if someone is on the other end of the alert.

Overview of Cloud Native Security — 14%

Official sub-topics: the 4Cs, cloud provider and infrastructure security, controls and frameworks, isolation techniques, artifact repository and image security, workload and application code security.

The 4Cs of Cloud Native Security is the framing model for the whole exam, and it is worth being able to recite: Cloud → Cluster → Container → Code, each layer nested inside the one before it. A weakness in an outer layer cannot be fixed by hardening an inner one — if the cloud account is compromised, no Pod securityContext saves you.

Cloud and infrastructure: IAM and least privilege, the metadata service as a credential source, private control plane endpoints, network segmentation, node OS hardening and patching.

Isolation techniques: namespaces and cgroups as the baseline, then seccomp, AppArmor and SELinux as kernel-level restrictions, then sandboxed runtimes (gVisor, Kata) and finally separate clusters. Understand this as a ladder of increasing isolation and increasing cost.

Code: dependency scanning, SAST/DAST, secrets scanning in repositories, and the fact that application-layer vulnerabilities are the most common initial access — the cluster is usually not where the break-in happens, only where it spreads.

Compliance and Security Frameworks — 10%

Official sub-topics: compliance frameworks, threat modelling frameworks, supply chain compliance, automation and tooling.

The smallest domain, and largely a vocabulary check. Be able to place:

• CIS Kubernetes Benchmark — the prescriptive configuration baseline; kube-bench automates checking against it
• NIST frameworks, PCI-DSS, SOC 2, ISO 27001, GDPR — what kind of thing each is, not their clauses
• Threat modelling: STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) and the general practice of modelling before mitigating
• MITRE ATT&CK for Containers — the tactic/technique taxonomy that maps neatly onto the threat-model domain above
• Supply chain compliance — SLSA levels, attestations, and provenance as evidence rather than as claims
• Tooling: kube-bench (CIS), kube-hunter (attack surface), Trivy (vulnerabilities), Falco (runtime), Kyverno / OPA Gatekeeper (policy)

The unifying idea: compliance is the automated, evidenced version of the controls in the other five domains. Policy-as-code is how a control becomes continuous instead of annual.

Logistics — verified facts only

From the official Linux Foundation certification page:

• Online, proctored, multiple choice
• 90 minutes
• No prerequisites — despite the subject matter, it is positioned as beginner-level
• Valid for 2 years
• 12-month eligibility window
• One retake included
• $250 exam-only at list price

As with KCNA, the number of questions and the passing score are not published. Prepare to know the material rather than to clear a rumoured number.

A study sequence

1. Read the official KCSA curriculum PDF in the CNCF curriculum repository. Every heading above is taken from it, and the sub-topic lists are unusually specific for a beginner exam — they are effectively a syllabus.
2. Read the Kubernetes security documentation on kubernetes.io, especially the Pod Security Standards pages, the RBAC reference, and the controlling-access overview.
3. Read the CNCF Cloud Native Security Whitepaper. It is the source of the 4Cs framing and the lifecycle model the exam leans on.
4. Run kube-bench and kube-hunter against a throwaway cluster. The findings are the CIS benchmark expressed as concrete misconfigurations, which is a far better way to learn it than reading the PDF.
5. Break something deliberately. Deploy a Pod with hostPath: /, reach the node filesystem, then apply the restricted Pod Security Standard and watch it get rejected. The threat-model domain stops being abstract the moment you have done the escape once.
6. LFS250 covers the shared Kubernetes foundations; the security-specific depth comes from the docs and the whitepaper rather than from a single course.

What not to over-invest in

• CKS-level hands-on work. Seccomp profile authoring, AppArmor syntax, and runtime policy tuning are the next exam’s problem. Here you need to know what each does and when to reach for it.
• Memorising CIS control numbers. Know what the benchmark is and that kube-bench checks it.
• Vendor security products. The exam is upstream and CNCF projects.
• Exhaustive CVE history. Know the classes — container escape, privilege escalation via RBAC, supply chain compromise — not individual identifiers.

Part of the Kubestronaut run. The foundations it assumes are in the KCNA study guide. Containment and choke points as an engineering discipline, at a larger scale, is the thread under ai-safety.