KCSA

KCSA Exam Details

Domain Weight Breakdown

About the KCSA Certification

The Kubernetes and Cloud Native Security Associate (KCSA) is a pre-professional, knowledge-based certification from the Linux Foundation and CNCF. It validates a candidate's foundational understanding of security concepts within Kubernetes and cloud native ecosystems. This is a theory-based exam (no hands-on labs) that covers the security aspects of the 4C's of cloud native security (Cloud, Cluster, Container, Code), Kubernetes threat modeling, supply chain security, platform hardening, and compliance frameworks.

The KCSA is positioned as a stepping stone toward the CKS (Certified Kubernetes Security Specialist) which is performance-based. Candidates should have a basic understanding of Kubernetes architecture and operations before attempting the KCSA. The exam heavily tests security concepts applied to Kubernetes rather than hands-on implementation.

Exam Tips

The KCSA is knowledge-based with no hands-on component. Focus on understanding security concepts and how they apply to Kubernetes environments. The two largest domains, Cluster Component Security and Kubernetes Security Fundamentals, together account for 44% of the exam. Study the 4C's security model thoroughly. Know the STRIDE and MITRE ATT&CK frameworks at a conceptual level. Understand RBAC, Network Policies, Pod Security Standards, and admission controllers conceptually. Review supply chain security topics including image signing, SBOM, and vulnerability scanning.

The 4C's of Cloud Native Security

Cloud native security is built in layers, each depending on the security of the layer beneath it. This is known as the 4C's model: Cloud, Cluster, Container, and Code. Security at each layer must be addressed independently because a vulnerability at any level can compromise the entire stack.

Defense in Depth

Defense in depth is a security strategy that employs multiple layers of security controls so that if one layer fails, additional layers continue to provide protection. In Kubernetes, this means combining authentication, authorization, admission control, network policies, pod security, runtime security, and audit logging. No single control is sufficient on its own. Each layer reduces the attack surface and limits the blast radius of a potential breach.

Zero Trust Architecture

Zero Trust is a security model based on the principle of "never trust, always verify." In cloud native environments, this means no implicit trust is granted based on network location, identity, or previous authentication. Every request must be authenticated, authorized, and encrypted regardless of origin.

Shared Responsibility Model

In managed Kubernetes services (EKS, GKE, AKS), the cloud provider secures the control plane infrastructure while the customer is responsible for securing workloads, RBAC configuration, network policies, container images, and application code. In self-managed clusters, the customer is responsible for the entire stack including control plane hardening, etcd security, and certificate management. Understanding this boundary is critical for determining who owns which security controls.

Exam tip: The 4C's model is foundational for the KCSA exam. Remember that security must be addressed at each layer independently because a secure cluster cannot compensate for vulnerable application code, and secure code cannot overcome a compromised cluster. The exam tests your understanding of what controls belong to which layer.

API Server Security

The kube-apiserver is the most critical component to secure since all cluster operations flow through it. Every request passes through three stages: authentication, authorization, and admission control. Securing the API server is the single most important step in cluster hardening.

etcd Security

etcd stores all cluster state including Secrets. Compromising etcd means compromising the entire cluster. Critical security measures include encrypting client-to-server and peer-to-peer communication with TLS, enabling encryption at rest for Secrets, restricting network access to etcd (only API server should communicate with it), and performing regular encrypted backups stored securely off-cluster.

Kubelet Security

The kubelet runs on every node and has powerful capabilities: it can read Secrets, execute commands in containers, and manage pod lifecycle. Key hardening steps include enabling authentication and authorization on the kubelet API, disabling anonymous access, rotating kubelet certificates, and using the NodeRestriction admission plugin to limit what each kubelet can do.

Control Plane Communication Security

All control plane communication should be encrypted with TLS using certificates signed by the cluster CA. The PKI infrastructure includes separate certificate pairs for the API server, etcd, kubelet, and front proxy. Certificate rotation should be automated using kubeadm certs renew or cert-manager. The API server communicates with kubelets for logs, exec, and port-forward operations, which must also be secured with TLS and proper authentication.

Kubernetes Audit Logging

Audit logs record all requests to the API server, providing a chronological record of activities. The audit policy defines what events to record and at what level of detail.

Exam tip: Audit logs are essential for security incident investigation, compliance, and detecting unauthorized access. Know the four audit levels and understand that RequestResponse is the most detailed but also the most resource-intensive. Audit logs should be shipped to a centralized, tamper-proof log storage system.

RBAC (Role-Based Access Control)

RBAC controls who can perform what actions on which resources in the cluster. It follows the principle of least privilege: grant only the minimum permissions necessary for each role. RBAC consists of four resource types that define permissions and bind them to subjects.

RBAC Best Practices: Avoid cluster-admin bindings for regular users. Use namespace-scoped Roles instead of ClusterRoles when possible. Never bind roles to the default ServiceAccount. Regularly audit RBAC configurations using tools like kubectl auth can-i and rbac-lookup. Avoid wildcards (*) in verbs and resources.

Pod Security Standards (PSS)

Pod Security Standards define three levels of security policies for pods, enforced via the Pod Security Admission controller (replacement for deprecated PodSecurityPolicy). Standards are applied at the namespace level using labels.

Network Policies

NetworkPolicies are Kubernetes resources that control pod-to-pod traffic at L3/L4. By default, all pods can communicate with all other pods (flat network). Once a NetworkPolicy selects a pod, all traffic not explicitly allowed by any policy is denied. Policies are additive (union of all matching rules applies).

Best Practice: Start with a default-deny-all policy in each namespace, then explicitly allow required communication paths. The CNI plugin must support NetworkPolicies (Calico, Cilium, Weave do; Flannel does not). For L7 policies (HTTP methods, paths), use Cilium NetworkPolicies or service mesh authorization.

Secrets Management

Admission Controllers

Admission controllers intercept API requests after authentication and authorization but before persistence. They can validate (accept/reject) or mutate (modify) requests. Policy engines extend admission control with custom rules.

Exam tip: Understand the flow: Authentication → Authorization (RBAC) → Admission Control (mutating then validating webhooks) → Persist to etcd. Know that admission controllers can both modify resources (mutating) and reject them (validating). Important built-in controllers include NodeRestriction, PodSecurity, ResourceQuota, and LimitRanger.

STRIDE Threat Model

STRIDE is a threat modeling framework used to categorize security threats. When applied to Kubernetes, it helps systematically identify potential attack vectors across the platform.

Common Kubernetes Attack Vectors

Container Security Best Practices

Runtime Security

Exam tip: Know that Falco monitors runtime behavior (detection) while Seccomp, AppArmor, and SELinux enforce restrictions (prevention). Falco uses rules written in YAML to detect suspicious activities. The MITRE ATT&CK framework maps threat tactics and techniques specific to containers and Kubernetes.

Supply Chain Security

Supply chain security protects the entire software delivery pipeline from source code to running containers. This includes verifying the integrity of source code, dependencies, build processes, container images, and deployment configurations.

CIS Kubernetes Benchmark

The Center for Internet Security (CIS) Kubernetes Benchmark provides prescriptive security configuration guidelines for Kubernetes clusters. It covers control plane components, worker nodes, policies, and managed services with specific checks and remediation steps. The benchmark is divided into sections covering the API server, controller manager, scheduler, etcd, kubelet, and policies.

NSA/CISA Kubernetes Hardening Guide

The NSA and CISA jointly published a Kubernetes Hardening Guide that provides actionable security recommendations organized into key areas.

MITRE ATT&CK for Containers

The MITRE ATT&CK framework maps adversary tactics and techniques. The Containers matrix extends this to container and Kubernetes environments with specific techniques at each stage of an attack.

Compliance Standards Relevant to Kubernetes

Security Scanning & Continuous Compliance

Exam tip: For the KCSA, understand the purpose and scope of CIS Benchmarks, NSA-CISA Hardening Guide, and MITRE ATT&CK at a conceptual level. Know that kube-bench checks CIS compliance, and Kubescape checks multiple frameworks. Remember that compliance is not a one-time activity but requires continuous scanning, monitoring, and remediation as part of the DevSecOps lifecycle.