Domain 1: Overview of Cloud Native Security
- The 4Cs of Cloud Native Security are Cloud, Cluster, Container, and Code - layered outermost to innermost, where each layer secures the layer inside it.
- Cloud is the outermost layer; if the cloud account or IAM is compromised, all inner layers (Cluster, Container, Code) inherit the exposure.
- A strong Cloud layer cannot compensate for weak Cluster, Container, or Code layers - every layer must be secured independently.
- Defense in depth means applying multiple independent layers of security so a single control failure or bypass does not lead to full compromise.
- Shift-left security moves checks earlier in the lifecycle (code review, build, CI) so vulnerabilities and misconfigurations are caught before reaching production, when remediation is cheap.
- Shift-left CI practices include SAST scanning, dependency/SCA checking, IaC scanning, and container image scanning during pull requests.
- Admission control acts as a runtime backstop: even with shift-left CI checks, an admission controller evaluates every workload centrally before it is scheduled.
- A cluster-wide guardrail that must apply uniformly to all workloads belongs at the Cluster layer, enforced via an admission controller (Pod Security Admission or OPA/Gatekeeper).
- The Container layer addresses image and runtime concerns: minimal base images, image scanning, non-root users, read-only root filesystems, and dropping Linux capabilities.
- Least privilege means granting no permissions by default, then adding only the specific rights a workload demonstrably needs.
- Observability (logging, metrics, tracing) provides telemetry to detect incidents and drive response, complementing preventive controls.
- Immutable infrastructure makes deviations detectable and reduces persistent attack surface; kubectl exec breaks immutability and can create audit gaps.
- Cost controls (right-sizing, autoscaling, spot instances) must not remove essential security controls like isolation, RBAC, and scanning.
- ResourceQuota and LimitRange applied per namespace cap resource consumption by tenant, supporting multi-tenant isolation.
Domain 2: Kubernetes Cluster Component Security
- The kube-apiserver and etcd are the two highest-priority control-plane components to secure, because compromising either yields broad control over the entire cluster.
- etcd is the sole persistent store for all cluster state including Secrets; its compromise (or a stolen backup) exposes the whole cluster.
- By default Secrets are stored in etcd base64-encoded, not encrypted; enable encryption at rest via the kube-apiserver --encryption-provider-config flag (AES-CBC, AES-GCM, or a KMS provider).
- etcd should be reachable only by the API server, secured with mutual TLS (--client-cert-auth=true, --trusted-ca-file, --cert-file, --key-file), with no direct workload access.
- The kube-apiserver is the central policy enforcement point: every request passes through authentication, then authorization (RBAC), then admission control.
- Set --anonymous-auth=false so unauthenticated requests are rejected rather than mapped to the system:anonymous identity.
- The system:masters group bypasses RBAC entirely, granting unconditional cluster-admin-equivalent access that cannot be scoped, audited per-permission, or easily revoked without rotating CA trust.
- The kubelet API exposes privileged endpoints (exec, logs, /run); harden it with --anonymous-auth=false and --authorization-mode=Webhook so the API server authorizes kubelet API calls.
- If kubelet authorization is set to AlwaysAllow, anonymous or unauthorized callers can invoke privileged endpoints; Webhook mode must be used instead.
- The NodeRestriction admission plugin (--enable-admission-plugins=NodeRestriction) limits each kubelet to modifying only its own node and pods bound to it - but it only constrains requests already attributed to the Node authorizer, so Node authorization mode must also be enabled.
- Enable API server audit logging with --audit-policy-file and --audit-log-path to record who did what and when.
- Protect static pod manifests with strict file permissions (chmod 600 /etc/kubernetes/manifests/kube-apiserver.yaml) since they run with control-plane privileges.
- Check control-plane certificate expiration with kubeadm certs check-expiration to avoid outages and ensure timely rotation.
- The insecure-port (a nonzero --insecure-port) bypassed authentication and authorization entirely; it was deprecated and fully removed in modern Kubernetes (since v1.20).
Domain 3: Kubernetes Security Fundamentals
- RBAC is the primary authorization mechanism; follow least privilege by granting only the verbs (get, list, create, delete) on only the resources a subject genuinely needs.
- Test effective permissions with kubectl auth can-i, e.g. kubectl auth can-i --list --as=system:serviceaccount:web:app-sa or kubectl auth can-i create deployments --as=dev@corp -n web.
- Bind a ClusterRole to a ServiceAccount in a namespace with a RoleBinding, e.g. kubectl create rolebinding deployer-view --clusterrole=view --serviceaccount=ci:deployer -n ci.
- The Pod Security Standards define exactly three levels: privileged (no restrictions), baseline (blocks known escalation vectors like hostNetwork, hostPID, privileged), and restricted (strongest, enforces non-root and dropped capabilities).
- Enforce a Pod Security Standard per namespace with a label, e.g. kubectl label ns payments pod-security.kubernetes.io/enforce=restricted.
- A default-deny NetworkPolicy uses an empty podSelector {} with a policyType but no rules: spec: { podSelector: {}, policyTypes: [Ingress] } drops all ingress until a more specific policy allows it.
- NetworkPolicies are additive and require a CNI plugin that enforces them; when egress is restricted, you must add an explicit egress allow to cluster DNS (CoreDNS) on UDP/TCP 53.
- Secrets are base64-encoded in etcd by default, not encrypted; protect them with least-privilege RBAC on get/list and encryption-at-rest.
- Create a Secret imperatively with kubectl create secret generic db-cred --from-literal=user=admin --from-literal=pass=s3cret.
- Kubernetes auto-mounts a ServiceAccount token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token; set automountServiceAccountToken: false when the pod never calls the API.
- A hardening securityContext uses runAsNonRoot: true, runAsUser: 1000, allowPrivilegeEscalation: false, and capabilities.drop: [ALL] (re-adding only what is needed, e.g. NET_BIND_SERVICE).
- readOnlyRootFilesystem: true makes the container root filesystem immutable; legitimate writes must go to explicitly mounted emptyDir or other volumes.
- Pull images only from trusted, controlled registries (e.g. Harbor, AWS ECR, GCP Artifact Registry), ideally with signature verification (Cosign/Notary) and scanning before admission.
- Privileged: true and hostNetwork: true are dangerous pod settings; restricted Pod Security blocks them along with host namespaces and privilege escalation.
Domain 4: Kubernetes Threat Model
- STRIDE is a threat-modeling methodology categorizing threats as Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
- Repudiation threats involve destroying or polluting logs to undermine the ability to attribute actions; tamper-resistant audit logs counter this.
- A supply-chain attack targets how software is built and delivered - pulling a tampered image (embedded malware, backdoored dependencies, known CVEs) introduces attacker code directly into running workloads.
- Two of the most common Kubernetes attack vectors are supply-chain compromise via malicious images and exposed, unauthenticated management interfaces (dashboard or API endpoint).
- privileged: true drops nearly all capability restrictions and grants host-level access, making container escape and node compromise trivial.
- Mounting the container runtime socket (/run/containerd/containerd.sock or /var/run/docker.sock) into a pod lets it create arbitrary privileged containers - a direct escape-to-node path.
- Mounting the host's /proc or using hostPath can expose node-level files (kubelet credentials, other pods' Secrets), enabling escape to the node.
- hostNetwork pods share the node's network identity and can reach the node-local cloud metadata service (e.g. 169.254.169.254) to steal the node's IAM credentials.
- Lateral movement (per MITRE ATT&CK for Containers) is an attacker's progression from an initial compromised pod to other systems - scanning the cluster network, reaching other workloads, or escalating.
- Pod create permission combined with hostPath mounts can expose node files and enable escape, so RBAC must restrict who can create pods with sensitive mounts.
- RBAC normally blocks creating or binding roles with privileges you do not already hold; the escalate and bind verbs are special permissions that allow this and must be tightly controlled.
- Mitigate compromised-image risk by signing artifacts in a hardened pipeline and verifying signatures at admission so only attested builds run.
- Reduce blast radius by scoping each ServiceAccount with least-privilege RBAC and using short-lived, audience-bound projected tokens instead of long-lived shared credentials.
- Disabled API server audit logging and no runtime detection of shells/exec inside containers leave post-compromise behavior undetected; enable both to investigate incidents quickly.
Domain 5: Platform Security
- Linux namespaces (pid, net, mnt, ipc, uts, user) isolate each container's view of processes, network, filesystem, and IPC; cgroups enforce CPU, memory, and I/O limits.
- Seccomp uses a BPF filter to restrict which system calls a container's processes may make, limiting what an attacker can do even after compromising the application.
- The restricted Pod Security Standard requires a seccomp profile of RuntimeDefault or Localhost; Unconfined is disallowed and admission rejects such pods.
- Apply a custom seccomp profile with seccompProfile: { type: Localhost, localhostProfile: profiles/audit.json }; RuntimeDefault is the recommended preventive baseline.
- Image scanning tools (Trivy, Grype, Snyk) compare image-layer packages against CVE databases (NVD, OSV, vendor advisories); scan at build time, push time, and continuously in the registry.
- Fail a CI build on serious findings, e.g. trivy image --severity HIGH,CRITICAL --exit-code 1 myrepo/app:1.0.
- An SBOM (Software Bill of Materials) lists an image's components so they can be quickly matched against newly disclosed CVEs; generate one with trivy image --format cyclonedx --output sbom.json myrepo/app:1.0.
- Distroless and minimal base images strip the shell, package manager, and debugging tools, shrinking the attack surface and reducing the number of CVEs.
- Falco is a CNCF runtime security tool that uses eBPF (or a kernel module) to monitor syscalls in real time and alert on suspicious behavior such as a shell spawned inside a container.
- Sandboxed runtimes like gVisor (handler runsc) and Kata Containers provide a stronger isolation boundary at some performance cost, selected via a RuntimeClass and spec.runtimeClassName.
- Define a RuntimeClass with handler: runsc and reference it with spec.runtimeClassName: gvisor to run a pod under gVisor.
- Verify image signatures at admission with Cosign, e.g. cosign verify --certificate-identity=ci@corp.com --certificate-oidc-issuer=https://token.actions.githubusercontent.com myrepo/app:1.0.
- Pod Security Admission (built-in) enforces the Pod Security Standards via namespace labels; pair it with a policy-as-code engine like Kyverno or OPA Gatekeeper for richer rules.
- Prefer validation (reject non-conforming pods) as the authoritative guardrail; use mutation cautiously, since silently mutating pods can mask misconfigurations - a non-root violation surfaces as a CreateContainerError when the kubelet detects UID 0.
Domain 6: Compliance and Security Frameworks
- The CIS Kubernetes Benchmark is a community-consensus set of prescriptive, testable hardening recommendations covering API server flags, etcd, kubelet, RBAC, network policies, and pod security.
- kube-bench is an open-source Aqua Security tool that automates CIS Kubernetes Benchmark checks and produces a pass/fail report with remediation guidance.
- Run kube-bench as a scheduled cluster Job and in CI/CD, exporting results to a centralized dashboard for trend tracking; deploy it with kubectl apply -f the project's job.yaml.
- On managed clusters (EKS, GKE, AKS), control-plane checks may not apply because the provider hides those components; focus on node/worker and policy checks you actually control.
- Compliance frameworks like PCI DSS (cardholder data), HIPAA (health data), and SOC 2 (service orgs) mandate specific controls and require auditable evidence they operate effectively.
- API server audit logging records the authenticated principal, verb, resource, namespace, source IP, timestamp, and outcome, providing a non-repudiation trail for accountability and investigations.
- An audit policy file is referenced by --audit-policy-file and its rules are evaluated top-down; the first matching rule wins, so rule order matters (a None rule for secrets drops those events).
- Audit levels are None, Metadata (request metadata only), Request (metadata plus request body), and RequestResponse (metadata plus request and response bodies).
- A Metadata-level rule matching group "" and resources ["secrets"] logs that Secrets were accessed without recording their contents.
- The audit log stage indicates at which point in request processing the event was recorded (e.g. RequestReceived, ResponseComplete), helping reconstruct a request's full lifecycle.
- Logs stored only on the node can be tampered with or deleted by an attacker who compromises it; ship audit logs promptly to an external, append-only/immutable store such as a SIEM.
- Retain logs in a tamper-resistant store for a defined period so past incidents can be investigated and audit requirements satisfied.
- Detect over-privileged access to Secrets by auditing ClusterRoles/bindings granting get/list on secrets (kubectl get clusterrolebindings -o wide) and testing with kubectl auth can-i --list --as=....
- Policy-as-code engines like Kyverno and OPA Gatekeeper run as validating admission webhooks with background audit reporting, providing continuous compliance enforcement and visibility.
KCSA exam tips
- Memorize the 4Cs in order (Cloud, Cluster, Container, Code) and remember each layer secures the one inside it - many questions hinge on placing a control at the correct layer.
- Know the three Pod Security Standards levels (privileged, baseline, restricted) and exactly what restricted enforces: non-root, drop ALL capabilities, no privilege escalation, and a RuntimeDefault/Localhost seccomp profile.
- Be able to read kube-apiserver and kubelet flags at a glance: --anonymous-auth=false, --authorization-mode=Webhook, --encryption-provider-config, --audit-policy-file, and NodeRestriction.
- Recognize the classic escape vectors (privileged: true, runtime socket mount, hostPath, hostNetwork reaching metadata service) and the STRIDE category each threat maps to.
- Distinguish tools by purpose: kube-bench (CIS benchmark), Trivy/Grype (image scanning + SBOM), Cosign (signature verification at admission), Falco (runtime detection), Kyverno/Gatekeeper (policy-as-code).
Study guide FAQ
How hard is the KCSA and what background do I need?
KCSA is an associate-level, multiple-choice exam (no hands-on labs, unlike CKS), so it tests conceptual understanding rather than live cluster work. A basic familiarity with Kubernetes objects and kubectl - roughly the level of KCNA or early CKA study - is enough to start; you do not need the CKA or CKS first.
Is the KCSA the same as the CKS?
No. KCSA is a foundational, knowledge-based multiple-choice exam validating that you understand cloud native security concepts. The CKS (Certified Kubernetes Security Specialist) is an advanced, performance-based exam requiring you to configure and harden real clusters, and it requires an active CKA as a prerequisite. KCSA is a good stepping stone toward the CKS.
Why does the exam stress that Secrets are 'encoded, not encrypted'?
By default Kubernetes stores Secret data in etcd as base64, which is trivially reversible. Anyone with etcd access, an etcd backup, or RBAC to run kubectl get secret -o yaml can read the values. Real protection requires enabling encryption at rest (--encryption-provider-config, ideally with a KMS provider) plus least-privilege RBAC on get/list of secrets - a frequently tested point.
Which security tools should I know by name for the exam?
Expect to identify kube-bench (CIS Kubernetes Benchmark checks), Trivy/Grype/Snyk (image scanning and SBOM generation), Cosign (image signing and signature verification), Falco (eBPF-based runtime threat detection), Pod Security Admission (built-in PSS enforcement), and Kyverno or OPA Gatekeeper (policy-as-code admission control). gVisor and Kata Containers come up as sandboxed runtimes selected via RuntimeClass.