KCSA cheat sheet

The 4C model nests Cloud, Cluster, Container, and Code; each layer inherits the trust of the layer beneath it, so a compromised cloud provider defeats cluster-level controls.

The 4C model originates from the CNCF/Kubernetes community threat-modeling work; it is not a certification standard and carries no audit authority.

Cloud layer controls are provider-scoped: IAM, network fabric, hypervisor isolation, managed control plane availability, and physical security.

Cluster layer covers control plane components, node OS hardening, network policy, and RBAC; Code layer covers application dependencies, secrets in images, and supply chain.

Shared responsibility is split by service model: IaaS leaves OS and runtime to the customer, managed Kubernetes moves control plane patching to the provider.

Defense in depth means no single layer is trusted alone; a pod-level control does not substitute for node or network segmentation.

Cloud native security assumes ephemeral workloads and API-driven change, so controls must be automated and identity-based rather than host-based.

The CIA triad maps to Kubernetes controls: confidentiality via RBAC and encryption, integrity via admission and image signing, availability via quotas and PDBs.

kube-apiserver is the only component that talks to etcd; all other control plane components reach the API through it, so restricting etcd access to apiserver is the key hardening step.

etcd should use TLS for peer and client traffic and, where supported, encryption at rest via EncryptionConfiguration with aescbc, aesgcm, or a KMS provider.

kubelet exposes an HTTPS API on port 10250; anonymous authentication must be disabled and authorization delegated to the API server via webhook mode.

kubelet read-only port 10255 is deprecated and should be disabled; it served unauthenticated metrics and pod information.

kube-scheduler and kube-controller-manager bind to localhost by default; enabling anonymous or unauthenticated access on these endpoints exposes cluster state.

The API server should set --authorization-mode=Node,RBAC, --anonymous-auth=false, and a restricted --enable-admission-plugins list including NodeRestriction.

NodeRestriction admission limits what a kubelet can read or modify to its own Node object and its own pods, reducing blast radius of a compromised node.

Container runtime sockets (containerd, CRI-O) on a node are root-equivalent; mounting them into a pod grants host compromise.

Control plane ports: apiserver 6443, etcd 2379/2380, kubelet 10250, scheduler and controller-manager 10257/10259 with authn/authz.

RBAC is additive and allow-only; there is no deny rule, so permissions must be granted narrowly with Role/RoleBinding (namespaced) or ClusterRole/ClusterRoleBinding (cluster-wide).

A ServiceAccount token is a JWT mounted into the pod; automountServiceAccountToken: false removes it where the workload does not call the API.

Pod Security Standards define three profiles: Privileged (unrestricted), Baseline (blocks known escalations), and Restricted (hardened, non-root, seccomp, dropped capabilities).

Pod Security Admission enforces PSS per namespace via labels: pod-security.kubernetes.io/enforce, audit, and warn, each with a version label.

NetworkPolicy is default-allow until a policy selects the pod; once selected, traffic is denied except what the policy explicitly allows, and egress requires policyTypes.

Secrets are base64-encoded, not encrypted, by default; etcd encryption at rest and RBAC restriction on secret reads are required for confidentiality.

Admission controllers such as OPA Gatekeeper, Kyverno, and ValidatingAdmissionPolicy enforce policy before objects persist to etcd.

securityContext fields that matter: runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false, capabilities.drop: [ALL], seccompProfile.

STRIDE categories (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) are applied per trust boundary: node, pod, container, network.

The Kubernetes threat model defines actors: external attacker, compromised container, compromised node, malicious insider with API access, and supply chain attacker.

MITRE ATT&CK for Containers maps techniques such as exposed dashboards, hostPath mounts, privileged containers, and cloud metadata API access.

A pod with hostPath or privileged: true can escape to the node; combined with a mounted service account token it enables cluster-level privilege escalation.

Instance metadata endpoints (169.254.169.254) are a common credential-theft target; blocking them with NetworkPolicy egress rules or IMDSv2 limits exposure.

Lateral movement typically follows stolen service account tokens or overly broad ClusterRoles; audit logs and admission logs are the primary detection sources.

Supply chain threats include typosquatted images, unsigned images, and compromised CI credentials; image signing with cosign/sigstore and digest pinning mitigate.

Denial-of-service vectors include unbounded resource requests without LimitRange/ResourceQuota and unauthenticated API server access.

Image security: pin by digest, scan with Trivy or Grype, sign with cosign, and enforce with admission (e.g., verify signature and reject latest tag).

Supply chain integrity uses SBOMs (SPDX, CycloneDX) and SLSA provenance to attest how an artifact was built.

Runtime security tools (Falco, Tetragon) detect syscall and behavior anomalies such as shell in container or unexpected process execution.

Host and node hardening: minimal OS (e.g., Bottlerocket, Talos), CIS benchmark scanning with kube-bench, and disabling unused kernel modules and services.

Secrets management: external secret stores (Vault, cloud KMS) via CSI driver or External Secrets Operator reduce plaintext secret persistence in etcd.

Network segmentation uses CNI-enforced NetworkPolicy plus service mesh mTLS for workload identity and encrypted east-west traffic.

CI/CD pipeline security: least-privilege build credentials, ephemeral runners, signed artifacts, and admission checks that reject unsigned images.

Audit logging at the API server with a defined policy level (Metadata, Request, RequestResponse) and retention is the primary forensic control.

CIS Kubernetes Benchmark provides configuration checks; kube-bench automates them for control plane and nodes.

NIST SP 800-190 covers container security; NIST SP 800-53 and 800-207 (zero trust) are commonly mapped as control catalogs.

PCI DSS, HIPAA, SOC 2, and ISO/IEC 27001 are organizational compliance frameworks; Kubernetes controls are mapped to them, not certified by Kubernetes itself.

NSA/CISA Kubernetes Hardening Guide recommends pod security, network separation, audit logging, and restricting deprecated features.

The Kubernetes conformance program certifies API behavior, not security posture; passing conformance does not imply compliance.

Compliance evidence for Kubernetes typically comes from audit logs, admission policy reports, image scan results, and configuration scans.

Zero trust (NIST SP 800-207) aligns with Kubernetes by treating every workload identity as untrusted until authenticated and authorized.

Regulatory data residency affects cluster region choice; encryption at rest and key custody (KMS) are common audit evidence items.