KCSA — Kubernetes & Cloud Native Security Associate

⭐ Where to Start

If you only read one section first, read this. Here's the exact order to move through this guide and the wider material so a week is enough.

📋 Exam Facts & Logistics

Domain Weights (memorize these)

🗓️ 7-Day Study Plan

⚙️ Kubernetes Core Refresher

You must be fluent in the architecture before security makes sense. A Kubernetes cluster = Control Plane + Worker Nodes.

Domain 1 — Overview of Cloud Native Security (14%)

The 4Cs of Cloud Native Security

Defense-in-depth layered model. Each outer layer's security depends on the layers inside it; you cannot secure inner layers by only securing outer ones.

Cloud Provider & Infrastructure Security

• Shared Responsibility Model — the provider secures the cloud infrastructure; you secure what you run in it (workloads, config, IAM, data).
• Use provider IAM with least privilege; avoid long-lived static credentials — prefer workload identity / IRSA / instance roles.
• Restrict access to node metadata endpoints (e.g., 169.254.169.254) — a classic SSRF/credential-theft target.
• Encrypt data at rest and in transit; isolate the cluster network (private nodes, restricted control-plane endpoint).

Controls & Frameworks

Security controls are grouped as preventive, detective, and corrective/responsive. Kubernetes-relevant frameworks:

• CIS Kubernetes Benchmark — hardening checklist for cluster components (checked by kube-bench).
• NIST SP 800-190 (container security) & the Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).
• MITRE ATT&CK for Containers — adversary tactics/techniques mapped to containers/K8s.

Isolation Techniques

Artifact Repository & Image Security

• Pull only from trusted registries; use private registries with authentication.
• Scan images for vulnerabilities (Trivy, Clair, Grype) — pre-deploy and continuously.
• Sign & verify images (Sigstore/cosign, Notary/TUF) to guarantee provenance and integrity.
• Use minimal base images (distroless, Alpine) → smaller attack surface.
• Pin images by digest (@sha256:…), not just mutable :latest tags.
• Enforce at admission (only allow signed/scanned images) via admission controllers / OPA / Kyverno.

Workload & Application Code Security

• SAST (static analysis of source), DAST (dynamic testing of running app), SCA (dependency/CVE scanning).
• Never hard-code secrets in code or images; encrypt communications (TLS/mTLS).
• Follow least privilege in the app; validate all input; manage dependencies.

Domain 2 — Kubernetes Cluster Component Security (22%)

The biggest domain (tied with D3). Know each component, the threat it faces, and how to harden it.

API Server

• The central management point; every request is Authenticated → Authorized → passed through Admission Controllers → validated/persisted.
• Harden: enable TLS everywhere; disable anonymous auth (--anonymous-auth=false); use strong AuthN (certs/OIDC); enable RBAC (--authorization-mode=Node,RBAC); enable audit logging; restrict who can reach it (network/firewall).
• Never expose the API server publicly without restriction; avoid the insecure port (removed in modern versions).

Controller Manager & Scheduler

• kube-controller-manager runs reconciliation loops; secure with --use-service-account-credentials=true, bind to localhost, TLS.
• kube-scheduler places Pods; secure its endpoint (bind to localhost, disable profiling in prod). Neither should be exposed externally.
• Both authenticate to the API server with their own certificates/kubeconfig.

Kubelet

• Node agent — powerful: it can run containers and expose pod data. A high-value attack target.
• Harden: --anonymous-auth=false; require authN (--authorization-mode=Webhook, not AlwaysAllow); rotate certificates (--rotate-certificates); protect the read-only port (10255, should be disabled) and the authenticated port (10250).
• Use NodeRestriction admission plugin so a kubelet can only modify its own node/pods.

Container Runtime & kube-proxy

• Runtime (containerd/CRI-O via CRI) — keep patched; use seccomp, AppArmor/SELinux, read-only rootfs, drop capabilities. Consider gVisor/Kata for stronger isolation.
• kube-proxy — programs iptables/IPVS for Services. Secure its config; it should not run with more privilege than needed.

Pod Security

• Use securityContext: runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, drop all capabilities then add only what's needed.
• runAsUser: 0 means the container runs as root (UID 0) — avoid it; set a non-zero UID or runAsNonRoot: true.
• Avoid privileged: true, hostNetwork, hostPID, hostIPC, and hostPath mounts — these break isolation.
• Apply seccomp profiles (RuntimeDefault) and AppArmor.

etcd

• Enable TLS for client-to-server and peer-to-peer communication.
• Enable encryption at rest for secrets (EncryptionConfiguration; ideally with a KMS provider).
• Restrict access: only the API server should talk to etcd; firewall its ports (2379/2380).
• Back up etcd regularly and secure the backups.

Container Networking, Client Security & Storage

• Networking (CNI) — the CNI plugin implements pod networking; NetworkPolicy enforcement requires a policy-capable CNI (Calico, Cilium). Encrypt pod traffic where needed (WireGuard/IPsec/mTLS).
• Client security — protect kubeconfig files and client certs; use short-lived credentials/OIDC; never share admin kubeconfig.
• Storage — encrypt volumes at rest; control access with StorageClasses; be wary of hostPath (host filesystem access = escape risk).

Domain 3 — Kubernetes Security Fundamentals (22%)

Pod Security Standards (PSS) & Pod Security Admission (PSA)

PSS replaced the deprecated PodSecurityPolicy (PSP) (removed in v1.25). Three cumulative profiles:

Pod Security Admission is the built-in admission controller (v1.25+) that enforces PSS at the namespace level via labels, in three modes:

• enforce — reject violating pods.
• audit — allow but log violations to the audit log.
• warn — allow but return a user-facing warning.

apiVersion: v1
kind: Namespace
metadata:
  name: my-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Authentication (AuthN)

"Who are you?" Kubernetes has no user objects — users are external. Methods:

• X.509 client certificates — CN (Common Name) = username, O (Organization) = group. A cert with O=system:masters grants full cluster-admin access — this group is hard-wired to the built-in cluster-admin superuser, so protecting the cluster CA is critical.
• Bearer tokens — ServiceAccount tokens (JWTs, for in-cluster workloads), static tokens (discouraged).
• OIDC — integrate with external identity providers (Okta, Azure AD, Google).
• Authentication webhooks / proxies.

ServiceAccounts = identity for Pods/processes. Every namespace has a default SA; disable auto-mount when not needed (automountServiceAccountToken: false). Modern tokens are short-lived & audience-bound (projected tokens).

Authorization (AuthZ)

"What are you allowed to do?" Modes: RBAC (default/most common), ABAC, Node, Webhook. Checked after AuthN.

RBAC objects

Subjects = Users, Groups, ServiceAccounts. Verbs = get, list, watch, create, update, patch, delete. RBAC is additive/allow-only — there are no deny rules; a request is denied unless explicitly allowed.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { namespace: dev, name: pod-reader }
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

The full request pipeline

Request → [Authentication] → [Authorization (RBAC)] → [Admission Controllers
             (Mutating → Validating)] → [Object persisted to etcd]

Secrets

• Secrets store sensitive data; by default only base64-encoded in etcd — encoding ≠ encryption.
• Enable encryption at rest (EncryptionConfiguration, ideally KMS-backed).
• Limit access via RBAC (few subjects should get/list secrets).
• Prefer mounting as files over env vars (env vars leak into logs/child processes).
• Consider external secret managers (Vault, AWS Secrets Manager, External Secrets Operator).

Isolation & Segmentation

Combine namespaces + RBAC + NetworkPolicy + ResourceQuota/LimitRange + node isolation (taints/tolerations) + runtime sandboxing for multi-tenancy.

Audit Logging

• API server audit logs record who did what, when, and the result — essential for detection & forensics.
• Configured via an audit policy with levels: None, Metadata, Request, RequestResponse.
• Stages: RequestReceived, ResponseStarted, ResponseComplete, Panic.

Network Policy

• Namespaced resource controlling ingress and egress at L3/L4 (IP/port), by pod/namespace selectors.
• Default: all traffic is allowed. Once any NetworkPolicy selects a pod, that pod becomes default-deny for the direction(s) specified — only explicitly allowed traffic passes.
• Requires a CNI that enforces policy (Calico, Cilium, Weave). Best practice: apply a default-deny-all policy, then allow needed flows.

# Default deny all ingress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: prod }
spec:
  podSelector: {}          # selects all pods
  policyTypes: ["Ingress"] # no ingress rules = deny all ingress

Domain 4 — Kubernetes Threat Model (16%)

Based on the CNCF/K8s threat model and STRIDE thinking. Know the trust boundaries and each attack category.

Trust Boundaries & Data Flow

Key boundaries: internet ↔ API server; API server ↔ etcd; control plane ↔ nodes; node ↔ pod; container ↔ host; pod ↔ pod. Data crossing a boundary is where controls (authN, TLS, RBAC, policy) must sit.

STRIDE mapped to Kubernetes

The main threat categories (from the K8s threat model)

• Persistence — attacker maintains foothold: backdoor DaemonSets, cronjobs, malicious admission webhooks, added credentials. Mitigate with monitoring, immutable infra, admission control.
• Denial of Service — resource exhaustion of nodes/control plane/etcd. Mitigate with quotas, limits, API priority & fairness.
• Malicious code execution & compromised containers — RCE, cryptomining, container escape. Mitigate with image scanning, runtime security (Falco), seccomp/AppArmor, non-root, read-only FS.
• Attacker on the network — lateral movement, sniffing, MITM. Mitigate with NetworkPolicy (default-deny), mTLS/service mesh, encryption.
• Access to sensitive data — stealing secrets/etcd/tokens. Mitigate with encryption at rest, RBAC, disabling SA token auto-mount, secret managers.
• Privilege escalation — pod→node→cluster. Mitigate with Pod Security Standards, drop capabilities, no privileged containers, NodeRestriction.

Domain 5 — Platform Security (16%)

Supply Chain Security

Securing everything from source code → build → artifact → deploy.

• SLSA (Supply-chain Levels for Software Artifacts) — framework of increasing integrity guarantees for the build pipeline.
• SBOM (Software Bill of Materials) — inventory of components/dependencies (SPDX, CycloneDX). Enables CVE tracking.
• Provenance & signing — Sigstore/cosign sign artifacts; in-toto attestations record how they were built.
• Verify at admission — only deploy signed, attested, scanned images.

Image Repository

Use trusted, access-controlled registries; scan on push; sign images; enforce immutability; apply retention/quarantine policies for vulnerable images.

Observability

• Logs (audit + app), metrics, traces — the three pillars. Common CNCF stack: Prometheus (metrics), Loki (logs), Jaeger (traces); Grafana visualizes.
• Runtime security monitoring — Falco (detects anomalous syscalls/behavior via eBPF/kernel), Tetragon.
• Centralize and alert; monitoring is a detective control.

Service Mesh

• Adds a sidecar proxy (Envoy) layer for mTLS, traffic management, and fine-grained authZ between services — zero-trust networking.
• Examples: Istio, Linkerd. Provides encryption in transit, identity-based policy, and observability without changing app code.

PKI & Certificates

• Kubernetes runs its own PKI/CA: components authenticate with X.509 certs signed by the cluster CA.
• etcd, kubelet, API server, controller-manager, scheduler all use TLS certs.
• Rotate certs regularly; protect the CA key; the CertificateSigningRequest (CSR) API issues certs. cert-manager automates certificate lifecycle.

Connectivity

Encrypt all traffic (TLS/mTLS), use NetworkPolicy for segmentation, secure ingress (WAF, TLS termination), and control egress to prevent data exfiltration.

Admission Control

• Admission controllers intercept requests after authN/authZ, before persistence. Two types: Mutating (modify) then Validating (accept/reject).
• Built-in examples: NodeRestriction, PodSecurity, ResourceQuota, AlwaysPullImages, LimitRanger.
• Extensible via webhooks: policy engines OPA/Gatekeeper and Kyverno enforce custom policies (e.g., "no :latest tag", "must have resource limits", "only signed images").

Domain 6 — Compliance & Security Frameworks (10%)

Compliance Frameworks

Threat-Modelling Frameworks

• STRIDE — Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation of privilege (Microsoft; per-threat-type).
• MITRE ATT&CK for Containers — real-world adversary tactics & techniques.
• OWASP Kubernetes Top Ten — the ten most common/impactful Kubernetes security risks (e.g. insecure workload configs, supply-chain vulns, over-permissive RBAC, missing network segmentation); a handy prioritization checklist.
• OCTAVE — risk-based, organization-focused threat assessment methodology.
• PASTA, DREAD, Attack Trees — other modelling approaches (recognize the names).

Supply-Chain Compliance

SLSA levels, SBOM generation/verification, provenance attestations, and signing (Sigstore) demonstrate a trustworthy software supply chain — increasingly required for compliance.

Automation & Tooling

Compliance is enforced continuously, not manually:

• kube-bench — CIS Benchmark checks.
• kube-hunter — penetration-testing / attack-surface discovery.
• Trivy / Grype / Clair — image & config vulnerability scanning.
• OPA/Gatekeeper, Kyverno — policy-as-code enforcement.
• Falco — runtime threat detection.
• Checkov / kubescape / kubeaudit — IaC & manifest security scanning.

🧰 Security Tools Cheat Sheet

🃏 Flashcards

📝 80 Practice Questions

Domain 1 — Cloud Native Security Overview

Domain 2 — Cluster Component Security

Domain 3 — Security Fundamentals

Domain 4 — Threat Model

Domain 5 — Platform Security

Domain 6 — Compliance & Frameworks

Mixed / Scenario

🏦 Mock Question Bank — 206 Questions (Interactive Quiz)

⚡ Final Quick-Reference (last-minute cram)

🔗 Authoritative Resource Links

KCSA Study Guide · Single-file HTML · Good luck on your exam! 🚀
Save this file anywhere and open in any browser — works fully offline.