KCSA — Kubernetes and Cloud Native Security Associate

The hard part of a platform is not making things possible — it is making the dangerous things impossible. The Kubernetes and Cloud Native Security Associate (KCSA) is the CNCF and Linux Foundation’s entry-level credential for exactly that instinct: the 4Cs, what each cluster component can be tricked into doing, Pod Security Standards, NetworkPolicy, secrets, audit logging, the supply chain, and the threat models that name the attacks. This page transcribes the official curriculum, explains what those words mean, maps them onto lessons already on this site — and gives you an honest verdict on whether to sit it at all.

What the KCSA is, and who it is for

☺ Like you’re 10: A multiple-choice test about how people break into clusters, and what stops them.

The KCSA is a knowledge-based, associate-tier certification from the CNCF, delivered by the Linux Foundation: multiple-choice questions, online and remote-proctored, with no live cluster and no terminal. It certifies that you understand the security posture of a Kubernetes platform — where the trust boundaries are, which defaults are dangerous, and what an attacker does once they’re inside a pod.

That changes how you study. For a hands-on exam you drill muscle memory; for KCSA you build a map of the attack surface. Take any Kubernetes feature and ask: what does an attacker gain if this is misconfigured, and which of the 4Cs does the fix live in?

Who should sit it, and what it doesn’t test

It suits platform engineers who own guardrails — if you write admission policy or answer “is this safe to run?” for other teams, this is your vocabulary formalised. Also SREs inheriting someone else’s cluster, appsec engineers meeting Kubernetes from outside, and anyone warming up for CKS.

Two things are out of scope. Remediation: you aren’t graded on cluster state, so memorising every kube-apiserver flag isn’t the assignment — knowing what those flags protect is. And tool trivia: the curriculum names capability areas (“Admission Control,” “Service Mesh”), not products.

Why a platform engineer might take it — and when to skip

☺ Like you’re 10: Worth it if you decide what others may run. Not if you’re mid-way through a bigger badge.

The honest case for: the CNPE’s Security & Policy Enforcement domain is 15% of that exam and assumes a literacy the CNPE never teaches — why a default-deny NetworkPolicy matters, what Pod Security Admission enforces, why signing an image differs from scanning it. KCSA is that missing prerequisite, laid out as a curriculum. Even unsat, its six domains are the best-organised free inventory of “what goes wrong in a Kubernetes platform” anyone publishes.

When to skip it — properly

• You are mid-CNPE or mid-CNPA. Finish what you started; CNPA and CNPE cover security at the depth they test, and they’re what a platform hiring manager scans for.
• You’re going straight to CKS. CKS requires an active CKA, is hands-on, and is far more respected. Read KCSA’s curriculum; skip its fee.
• You lack the fundamentals. KCSA assumes Pod, Service and ServiceAccount are second nature. If not, KCNA first — otherwise half the questions become vocabulary tests.
• Nobody will fund it and your platform has no security remit. A credential you never exercise decays faster than its validity window. Spend the weekend on Security & Policy and a real Kyverno ruleset instead.

The official domains and their weights

☺ Like you’re 10: The test isn’t spread evenly — two chunks are nearly half of it.

The official KCSA Exam Curriculum, published by the CNCF, splits the exam into six weighted domains whose weights sum to exactly 100%. Domain names and weights below are transcribed verbatim from that document; the bars are drawn to scale and re-ordered heaviest-first (the published PDF uses its own layout order):

Where the weight really sits

44% is the two 22% domains — cluster components and the built-in primitives — and both are enumerable: eleven named components, seven named primitives, each with a “what it exposes, what hardens it” pair. Finite lists are where you bank marks.

The 16% domains surprise people. Kubernetes Threat Model isn’t a feature list — it’s attacker behaviour, and rewards different thinking. Platform Security reaches into supply chain, PKI, mesh and admission control: the most platform-engineering domain on the blueprint. The 10% compliance domain is dry and cheap to secure — don’t leave it to the last night.

Every competency, domain by domain

Six domains, forty-two competencies (6 + 11 + 7 + 7 + 7 + 4), and the weights add to 100% — that is the entire testable surface, and it fits on one page.

What you actually need to know

☺ Like you’re 10: Four layers of defence, a list of parts that can be tricked, and a few switches that stop most attacks.

The 4Cs, and why the order matters

The first domain hangs off one model: Cloud, Cluster, Container, Code — nested layers, each secured by the one outside it. Cloud is the infrastructure underneath (node images, IAM, the metadata endpoint); Cluster is Kubernetes itself; Container is the image and its runtime isolation; Code is your app and its dependencies. The exam point is the direction of dependency: you cannot secure a container on a compromised cluster. Hardening works outside-in, and a control at the wrong layer is theatre.

Isolation techniques run down the same ladder: namespaces and cgroups isolate processes; seccomp, AppArmor and SELinux restrict syscalls; sandboxed runtimes (gVisor, Kata) give a stronger kernel boundary; Kubernetes namespaces, node pools and separate clusters isolate tenants. Know which layer each operates at.

Cluster components — what each can be tricked into doing

Learn the 22% component domain as “what it exposes → what hardens it.” Wider architecture is on Kubernetes as the Substrate.

Pod Security Standards vs Pod Security Admission

Two different things, and the exam cares. Standards (PSS) are three policy levels: privileged, baseline, restricted. Admission (PSA) is the built-in controller that enforces a level via namespace labels, in three modes: enforce (reject), audit (record), warn (message the user). Roll out with warn and audit; flip to enforce when nothing screams.

# Namespace labels ARE the configuration — this is Pod Security Admission.
apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted    # record violations
    pod-security.kubernetes.io/warn: restricted     # warn at apply time
---
# A Pod that actually satisfies the "restricted" standard.
apiVersion: v1
kind: Pod
metadata: { name: checkout, namespace: payments }
spec:
  automountServiceAccountToken: false     # don't hand out a token nobody uses
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile: { type: RuntimeDefault }
  containers:
    - name: app
      image: ghcr.io/acme/checkout@sha256:5f1a...   # digest, not a mutable tag
      securityContext:
        allowPrivilegeEscalation: false   # blocks setuid / file-capability escalation
        privileged: false
        readOnlyRootFilesystem: true
        capabilities: { drop: ["ALL"] }

PSA is deliberately coarse — namespace-wide, three levels, no exceptions. When you need “no latest tags” or “images only from our registry,” you’ve left PSA for policy engines: Kyverno or OPA/Gatekeeper, under the Admission Control competency.

Network Policy, authentication and secrets

Kubernetes networking is flat by default: every pod can reach every other pod, in every namespace. That single default drives most of the “Attacker on the Network” competency. A NetworkPolicy is namespaced, additive (rules union — they never deny), and only takes effect if your CNI implements it. On a CNI that ignores it, a policy silently protects nothing — a favourite exam trap.

# 1. Default-deny everything in the namespace, both directions.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: payments }
spec:
  podSelector: {}                 # empty selector = every pod in the namespace
  policyTypes: ["Ingress", "Egress"]
---
# 2. Then allow only what the app genuinely needs.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: checkout-allow, namespace: payments }
spec:
  podSelector:
    matchLabels: { app: checkout }
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: gateway }
      ports: [{ protocol: TCP, port: 8080 }]
  egress:
    - to:
        - podSelector:
            matchLabels: { app: orders-db }
      ports: [{ protocol: TCP, port: 5432 }]
    - to:                          # DNS, or nothing will resolve
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
      ports: [{ protocol: UDP, port: 53 }, { protocol: TCP, port: 53 }]

On authentication: Kubernetes has no User object. Humans authenticate via client certificates, OIDC or a proxy; workloads use short-lived, audience-bound ServiceAccount tokens. Authentication answers who, authorization (RBAC, Node, Webhook) answers what, admission control answers is this object acceptable — always in that order.

On secrets: a Kubernetes Secret is base64, not encryption — a costume, not a lock. It lives in etcd, readable by anyone with get secrets in the namespace, and isn’t encrypted at rest by default. The fixes: an EncryptionConfiguration, tight RBAC, and an external store — see Secrets & Workload Identity and External Secrets.

# Encryption at rest — API server flag: --encryption-provider-config
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - kms:                       # a KMS/HSM provider is the strong option
          apiVersion: v2
          name: cluster-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
      - identity: {}               # plaintext fallback — MUST be last, or nothing encrypts
---
# Audit policy: prove who did what. Levels: None, Metadata, Request, RequestResponse.
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  - level: RequestResponse         # full bodies for the crown jewels
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: Metadata                # who/what/when for everything else

Threat model, supply chain and compliance

The Threat Model domain names seven attacker goals, best learned as one story. An attacker gets malicious code execution in a container, hunts for access to sensitive data (the mounted token, env vars, the cloud metadata endpoint), tries privilege escalation via a privileged container or hostPath mount, moves sideways as an attacker on the network, establishes persistence with a CronJob or mutating webhook — and failing all that, falls back on denial of service. Every control above breaks one hop; trust boundaries and data flow is the discipline of drawing where one hop becomes another.

Platform Security is home turf. Supply chain: build reproducibly, generate an SBOM, scan with Trivy, sign with Sigstore/cosign, record provenance (SLSA, in-toto) — and the forgotten step, verify the signature at admission so an unsigned image cannot start. PKI: cert-manager issuing certificates, mTLS from Istio or Linkerd. Observability as a security control: Falco for runtime detection, audit logs shipped somewhere tamper-evident.

Compliance and Security Frameworks: compliance frameworks (CIS Kubernetes Benchmark, NIST SP 800-190, PCI DSS, SOC 2, ISO 27001) say what good looks like; threat modelling frameworks (STRIDE, MITRE ATT&CK for Containers, the CNCF Security TAG’s Kubernetes threat model) say how attacks are structured; supply chain compliance ties SBOMs to those obligations; automation and tooling stops you doing it by hand. Expanded on Governance & Compliance.

How to prepare using this site

☺ Like you’re 10: Nearly every KCSA topic already has a page here. This table is the shortcut.

This site was built for a platform exam that assumes KCSA-level literacy, so the overlap is close to total. Work it heaviest domain first:

Four weeks. Week 1: read Security & Policy beside the official curriculum, and write the six domains and forty-two competencies out by hand. Week 2: the 44% — work the component table until the “exposes/hardens” pair comes from memory, then do the workshop above. Week 3: narrate the attack chain aloud; run Trivy and Kyverno on kind so admission-time verification is something you’ve seen. Week 4: Governance & Compliance, then drill with the flashcards, quiz and glossary, and skim Know Cold for the facts worth memorising. The security lab and the security practice set are both deeper than KCSA needs — they are performance-based drills for a performance-based exam — but nothing cements a concept like building it once.

Exam logistics — and go verify them yourself

☺ Like you’re 10: Here are the published numbers. Numbers move — look them up before you pay.

The KCSA is administered by The Linux Foundation. One row below comes from a document this page can quote directly — the domains and weights, taken from the CNCF KCSA Exam Curriculum PDF. Most of the rest are logistics figures published on the Linux Foundation’s own product and FAQ pages, and those move without notice — where those pages publish nothing, this table says so rather than guessing. Treat every row as “last checked at time of writing, verify before you pay”:

Do not confuse the two exam styles. The CNCF associate exams — KCNA, KCSA and CNPA — are knowledge-based: multiple choice, proctored in a browser, nothing to type into a cluster. The CKA, CKAD, CKS and the CNPE are performance-based: a real terminal, real clusters, tasks graded on the state you leave behind. Study material written for one style is close to useless for the other, and vendors of practice tests are not always careful about the distinction.

Book on the official Linux Foundation KCSA page, and take the curriculum from the CNCF KCSA page — the PDF is versioned, and the version in force on your exam date is the one linked there, not the one in anyone’s course. Read the Certification Candidate Handbook once for ID and proctoring rules.

Where it sits in the ladder, and what to do next

☺ Like you’re 10: A first badge, not a final one. Take it, then earn a harder one.

Place KCSA honestly. It sits with KCNA and CNPA on the associate rung: valuable as a structured curriculum and as a signal that you take guardrails seriously — but not, alone, proof you can harden a cluster. Nobody has ever been hired on a KCSA. Plenty have used it to make the next exam much easier.

Three next moves. For security depth: CKA first (a hard prerequisite), then CKS — hands-on, and the one that changes how people read your CV. For platform engineering: CNPA for the map — its Observability & Security module is the closest overlap with this curriculum — then CNPE, where everything here is worth a direct 15% in its Security & Policy Enforcement domain. For developer-adjacent work, CKAD pairs neatly — half of KCSA’s workload competencies are things a developer sets in their own manifests.

The durable takeaway isn’t the badge. It’s the habit of asking, about every feature you ship: what does an attacker gain if this is misconfigured, and which layer does the fix belong to? That question survives every curriculum revision. The full map of what to take, and in what order, is on the certifications hub.