KCSA — The Kubernetes and Cloud Native Security Associate Cheatsheet.

KCSA tests whether you can reason about cloud native security before operating security tools under pressure. It is a 90-minute, online, proctored, multiple-choice exam with no prerequisite. Current domains: Cloud Native Security 14% · Cluster Component Security 22% · Kubernetes Security Fundamentals 22% · Threat Model 16% · Platform Security 16% · Compliance & Frameworks 10%. Think in trust boundaries, identities, data flows and layered controls.

0. Exam map and the security reasoning loop

Domain	Weight	Anchor question
Overview of Cloud Native Security	14%	Which of the 4Cs owns this risk?
Cluster Component Security	22%	Which component, credential or endpoint is exposed?
Kubernetes Security Fundamentals	22%	Which identity, policy or admission control applies?
Kubernetes Threat Model	16%	What boundary is crossed and what is the attack outcome?
Platform Security	16%	Which supply-chain, network or PKI control reduces the risk?
Compliance & Frameworks	10%	Which framework defines, measures or automates the control?

1. Asset: what needs protection—API, etcd data, image, credential, node, workload?
2. Actor: user, compromised Pod, malicious image, insider, external attacker?
3. Boundary: registry→cluster, user→API, Pod→Pod, Pod→node, node→cloud metadata?
4. Control: prevent, detect, respond or recover?
5. Layer: apply the control as close to the risk as possible, with defense in depth.

1. The 4Cs of cloud native security

The 4Cs are nested: Cloud → Cluster → Container → Code. A weakness in an outer layer can invalidate inner controls, so securing application code cannot compensate for a publicly exposed control plane or compromised node.

Layer	Typical risks	Representative controls
Cloud	Overbroad IAM, public networks, metadata theft	Least privilege, private endpoints, workload identity, encryption
Cluster	Weak API access, unsafe kubelet/etcd, missing segmentation	RBAC, admission, CIS hardening, NetworkPolicy, audit
Container	Root, capabilities, writable filesystem, vulnerable image	Restricted security context, scanning, signing, sandboxing
Code	Injection, secrets in source, unsafe dependencies	SAST/SCA, secure SDLC, secret scanning, patching

2. Kubernetes component security

Component	Sensitive surface	Secure posture
API server	Primary control-plane entry point	Strong authn, least-privilege authz, admission, TLS, audit, private reachability
etcd	Entire cluster state, including Secret objects	Mutual TLS, restricted network access, encryption at rest, protected backups
kubelet	Node workload control and logs/exec APIs	Disable anonymous access, webhook authz, restrict port/network exposure
scheduler/controllers	Powerful kubeconfigs and service accounts	Protect credentials, use minimal authorization, bind secure endpoints
container runtime	Image execution and host boundary	Patch runtime, restrict socket, use runtime isolation where needed
kube-proxy/CNI	Cluster dataplane	Protect configuration, enforce segmentation, observe flows
client	kubeconfig, tokens and local plugins	Protect files, use short-lived credentials, distrust unknown kubeconfigs

A kubeconfig can reference credential plugins and remote data; treat an untrusted kubeconfig like executable content. Client certificates, bearer tokens and service-account tokens are credentials—not harmless configuration.

3. Authentication, authorization and admission

The request pipeline is ordered: authenticate identity → authorize action → run admission → persist state. Each stage answers a different question.

• Authentication: Who are you? Certificates, OIDC tokens, service-account tokens.
• Authorization: May you perform this verb on this resource? Usually RBAC.
• Admission: Is the requested object acceptable, and should it be mutated? Built-in or webhook controllers.
• Audit: What request occurred, who made it and how was it handled?

# authorization checks expose effective privilege
kubectl auth can-i create deployments -n team --as=jane
kubectl auth can-i --list --as=system:serviceaccount:team:builder -n team

# inspect bindings and workload identity
kubectl get rolebindings,clusterrolebindings -A
kubectl get serviceaccount -A
kubectl get pod app -o jsonpath='{.spec.serviceAccountName}'

4. Pod, Secret and network security

Pod Security Standards

Profile	Intent
Privileged	Unrestricted; appropriate only for deliberately trusted system workloads
Baseline	Blocks known privilege escalation while remaining broadly compatible
Restricted	Strong hardening: non-root, seccomp, capability and volume constraints

Pod Security Admission applies profiles by namespace labels in enforce, audit and warn modes. Roll out with warn/audit first, fix workloads, then enforce.

securityContext:
  runAsNonRoot: true
  seccompProfile: { type: RuntimeDefault }
containers:
- name: app
  securityContext:
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
    capabilities: { drop: ["ALL"] }

Secrets

• Base64 is encoding, not encryption. Enable encryption at rest and protect encryption keys.
• Prefer workload identity or short-lived external secret delivery over long-lived static keys.
• Restrict get/list/watch on Secrets; list can expose every Secret in scope.
• Do not log Secret values, bake them into images or commit them to Git.

Isolation and NetworkPolicy

NetworkPolicy is allow-list policy for selected Pods. A Pod becomes isolated for a direction when a policy selects it for that direction. Policies are additive: traffic allowed by any applicable rule remains allowed. Enforcement requires a capable CNI.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: team }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

5. Kubernetes threat model

Threat	Example path	Primary defenses
Persistence	Malicious DaemonSet, webhook or stolen credential	Admission, RBAC, audit, immutable delivery
Denial of service	Resource exhaustion or API flooding	Quotas, limits, priority, rate controls, capacity
Malicious code execution	Compromised image or application RCE	Signed/scanned images, restricted runtime, segmentation
Attacker on network	Sniffing, lateral movement, spoofed service	TLS/mTLS, NetworkPolicy, identity-aware service mesh
Sensitive-data access	Reading Secrets, volumes or etcd	RBAC, encryption, key management, audit
Privilege escalation	Host mount, privileged Pod, dangerous capability	Restricted PSS, seccomp/AppArmor, policy admission

A useful threat model maps trust boundaries and data flows: user→API server, API server→etcd, scheduler/controller→API, kubelet→runtime, Pod→Service, Pod→node kernel, cluster→cloud APIs, CI→registry→admission→runtime.

6. Supply-chain and image security

The software supply chain spans source, dependencies, build system, artifact, registry, deployment policy and runtime. Controls must preserve provenance across the chain.

1. Source: protected branches, reviews, signed commits where appropriate, secret scanning.
2. Dependencies: lockfiles, SCA, trusted sources and timely patching.
3. Build: isolated, reproducible, least-privilege CI with protected credentials.
4. Artifact: minimal non-root image, SBOM, vulnerability scan and signature/attestation.
5. Registry: authentication, immutable tags or digest pinning, retention and audit.
6. Admission: require trusted provenance, allowed registries and acceptable policy.
7. Runtime: detect drift and behavior that build-time scanning cannot see.

7. Platform security: PKI, mesh and observability

• PKI/TLS authenticates endpoints and protects data in transit. Rotate certificates and protect private keys.
• Service mesh can provide workload identity, mTLS, authorization and traffic telemetry; it does not fix insecure application logic.
• Admission policy prevents unsafe configuration before it enters the cluster.
• Observability combines Kubernetes audit, workload logs, network flow data, metrics and runtime events.
• Image repository controls limit who can push/pull, preserve immutability and record provenance.

8. Compliance and security frameworks

Framework/control	Purpose
CIS Benchmarks	Prescriptive secure-configuration checks for Kubernetes and hosts
NIST Cybersecurity Framework	Organizes outcomes across Govern, Identify, Protect, Detect, Respond, Recover
MITRE ATT&CK	Models adversary tactics and techniques; includes container-relevant behavior
STRIDE	Threat modeling: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege
SLSA	Supply-chain integrity and build provenance framework
SBOM	Inventory of software components; evidence input, not a security verdict

Compliance asks whether required controls are defined and evidenced. Security asks whether risk is actually reduced. Automate policy and evidence collection, but keep human ownership of exceptions, risk decisions and incident response.

9. Control types, zero trust and incident readiness

Control type	Purpose	Kubernetes example
Preventive	Stop an unsafe action	Admission rejects privileged Pod; RBAC denies Secret read
Detective	Reveal suspicious or non-compliant behavior	Audit log, runtime alert, drift scan
Corrective	Remove or repair a discovered weakness	Rotate token, patch image, remove binding
Recovery	Restore trusted service and data	Tested etcd backup, redeploy from signed artifacts
Compensating	Reduce risk when the preferred control is infeasible	Isolate a legacy workload while remediation is pending

Zero trust means no identity or network location is trusted implicitly. Authenticate explicitly, authorize narrowly, encrypt where required, continuously evaluate signals and assume breach. In Kubernetes that becomes workload identity, short-lived credentials, default-deny segmentation, policy at admission, and runtime observation.

Incident readiness must exist before compromise. Know where audit and workload logs live, synchronize time, protect log integrity, define credential-rotation paths, keep tested backups, and preserve evidence. Recovery from an untrusted image or node should use known-good immutable artifacts—not manual repair inside the compromised container.

10. Isolation strength and tenant boundaries

Isolation is a spectrum. Choose strength based on trust:

1. Process/container controls: namespaces, cgroups, seccomp, AppArmor, capabilities.
2. Pod and namespace controls: PSS/PSA, quotas, RBAC, NetworkPolicy and separate identities.
3. Sandboxed runtime: adds a stronger userspace/kernel boundary for less-trusted workloads.
4. Virtual machine or separate cluster/account: stronger boundary for hostile multi-tenancy or regulatory separation.

A namespace is useful administrative scope but shares the control plane, nodes and often cluster-scoped resources. Hard multi-tenancy requires combined identity, network, admission, resource, data and runtime boundaries—and sometimes separate clusters.

11. Rapid scenario checks

• Need to stop privileged Pods before persistence? Admission policy / Pod Security Admission.
• Need to know whether jane may read Secrets? kubectl auth can-i / authorization review.
• Need to prove an image came from trusted CI? Verify signature and provenance attestation.
• Need to find who deleted a Secret? Kubernetes audit logs.
• Need to limit a compromised frontend's lateral movement? NetworkPolicy plus least-privilege identity.
• Need to harden a node process? Host controls such as least privilege, AppArmor/seccomp and reduced services—not an application ConfigMap.
• Need confidentiality between workloads? TLS/mTLS; NetworkPolicy alone controls reachability, not encryption.

12. Common exam traps and study order

• Confusing authentication, authorization and admission.
• Treating namespaces as sufficient tenant isolation.
• Calling base64-encoded Secrets encrypted.
• Assuming a NetworkPolicy encrypts traffic or works without CNI enforcement.
• Equating image scanning with signature verification.
• Using a detect control when the question asks to prevent admission.
• Choosing one magic security product instead of layered controls at different boundaries.

Study in this order: request pipeline and RBAC → component trust boundaries → Pod/Secret/network security → threat scenarios → supply chain → PKI/mesh/observability → compliance frameworks. For every control, be able to name what it prevents, what it detects, and what it cannot do.

Official sources & freshness

This guide was checked against the official Linux Foundation exam page and CNCF curriculum on 19 July 2026. Exam versions and policies can change; re-check the source page before booking.

• Linux Foundation — KCSA certification and current domains
• CNCF — open certification curricula
• CNCF — Kubestronaut requirements and renewal FAQ