# CKS Mastery Syllabus and Checklist

Baseline: official six-domain curriculum for the current CKS exam. The Linux Foundation currently advertises a two-hour, performance-based command-line exam. Before exam day, re-check the official page for the Kubernetes version and environment changes.

Status key: `[ ]` not assessed, `[~]` learning/remediation, `[x]` satisfactory on a fresh first attempt.

## 0. Exam fluency and prerequisites

- [ ] Switch and verify `kubectl` contexts before every task.
- [ ] SSH to the designated host and distinguish the base node from task hosts.
- [ ] Use `kubectl explain`, imperative generators, dry-run YAML, JSONPath, and `yq` efficiently.
- [ ] Edit YAML safely with Vim/Nano and validate before applying.
- [ ] Inspect static Pod manifests and wait for control-plane recovery.
- [ ] Use `crictl`, `systemctl`, `journalctl`, `ss`, `ps`, `find`, `openssl`, `sha256sum`/`sha512sum`, and text-processing tools.
- [ ] Back up files before mutation and verify every requested outcome.
- [ ] Search permitted documentation quickly without external search results.
- [ ] Apply time management: read all requirements, prioritize by weight, verify, and move on.

## 1. Cluster Setup — 15%

### 1.1 NetworkPolicy and cluster-level network restriction

- [x] Explain default-allow behavior and policy isolation triggers.
- [x] Build namespace default-deny ingress, egress, and combined policies.
- [x] Select exact sources/destinations with `podSelector` and `namespaceSelector`.
- [x] Combine selectors correctly (AND within one peer; OR across peer entries).
- [x] Allow DNS with the minimum necessary egress.
- [x] Restrict ports and protocols without accidentally widening peer access.
- [x] Use `ipBlock` and `except`, including cloud metadata endpoint protection.
- [x] Account for reply traffic and CNI NetworkPolicy support.
- [x] Test allowed and denied flows from representative Pods.

### 1.2 CIS benchmark review

- [x] Run `kube-bench` for the correct node/component/configuration.
- [x] Interpret PASS, FAIL, WARN, and manual checks.
- [x] Map a failed control to kube-apiserver, controller-manager, scheduler, etcd, or kubelet configuration.
- [x] Remediate static Pod flags without breaking YAML or mounts.
- [x] Remediate kubelet configuration/systemd arguments and restart safely.
- [x] Verify component health and rerun the targeted benchmark check.

### 1.3 Ingress TLS

- [x] Inspect certificate subject/SAN, issuer, dates, and key/cert correspondence.
- [x] Create a TLS Secret in the correct namespace.
- [x] Configure `ingressClassName`, TLS hosts, rules, paths, path types, Services, and ports.
- [x] Distinguish TLS termination from upstream/mTLS encryption.
- [x] Verify HTTPS routing, SNI/Host behavior, certificate presentation, and HTTP exposure.

### 1.4 Node metadata and endpoint protection

- [x] Identify link-local metadata endpoints and the associated credential risk.
- [x] Block workload access to metadata while preserving required egress.
- [x] Recognize host-network and CNI limitations in the threat model.
- [x] Minimize exposure of kubelet, etcd, API server, dashboards, and other management endpoints.
- [x] Verify externally listening sockets and authentication requirements.

### 1.5 Platform binary verification

- [x] Determine the exact version and architecture required.
- [x] Download binaries and official checksum material from trusted locations.
- [x] Verify SHA-256/SHA-512 checksums before installation.
- [x] Detect mismatch and refuse deployment of unverified artifacts.
- [x] Check installed binary location/version and preserve permissions/ownership.

## 2. Cluster Hardening — 15%

### 2.1 Least-privilege RBAC

- [x] Enumerate effective permissions with `kubectl auth can-i`, including impersonation.
- [x] Trace RoleBinding/ClusterRoleBinding subjects to Role/ClusterRole rules.
- [x] Distinguish namespaced and cluster-scoped resources.
- [x] Create minimal verbs, API groups, resources, subresources, and `resourceNames` rules.
- [x] Choose RoleBinding versus ClusterRoleBinding without unintended cluster-wide access.
- [x] Detect wildcards, privilege escalation, bind, impersonate, and secret-reading risks.
- [x] Repair overprivileged existing bindings while preserving required access.
- [x] Validate allowed and forbidden operations as the target identity.

### 2.2 Service-account safety

- [x] Disable token automounting at ServiceAccount and/or Pod level.
- [x] Create dedicated ServiceAccounts per workload.
- [x] Grant the smallest required RBAC permissions.
- [x] Understand projected, time-bound ServiceAccount tokens and TokenRequest.
- [x] Detect use of default ServiceAccounts and unnecessary API credentials.
- [x] Verify token absence/presence and effective permissions.

### 2.3 Restrict Kubernetes API access

- [ ] Harden API server authentication and anonymous access.
- [ ] Configure and reason about authorization modes and admission plugins.
- [ ] Protect API server network exposure and insecure endpoints.
- [ ] Protect kubeconfig files, client certificates, and bootstrap credentials.
- [ ] Inspect certificate identity/group mapping and expiration.
- [ ] Verify API access from authorized and unauthorized identities/locations.

### 2.4 Secure Kubernetes upgrades

- [ ] Read the version-skew policy and choose a supported upgrade path.
- [ ] Upgrade kubeadm control plane components in the safe order.
- [ ] Drain/uncordon and upgrade worker nodes safely.
- [ ] Preserve configuration and verify node/control-plane health.
- [ ] Recognize security risk from unsupported or vulnerable versions.

## 3. System Hardening — 10%

### 3.1 Minimize host OS footprint

- [ ] Inventory running services, packages, processes, sockets, and startup units.
- [ ] Disable/remove unnecessary services and packages without harming Kubernetes.
- [ ] Reduce installed tooling and writable/executable attack surface.
- [ ] Verify removed exposure and required component health.

### 3.2 Least-privilege host identity and access

- [ ] Inspect users, groups, sudo rules, file ownership, and sensitive permissions.
- [ ] Restrict Kubernetes PKI, kubeconfigs, manifests, etcd data, and logs.
- [ ] Avoid running services as root where unnecessary.
- [ ] Recognize Linux capabilities and remove unnecessary capabilities.

### 3.3 Minimize external network access

- [ ] Enumerate listening TCP/UDP ports and owning processes.
- [ ] Distinguish required Kubernetes ports by node role.
- [ ] Stop/disable unauthorized listeners and validate closure.
- [ ] Apply host firewall controls where appropriate without partitioning the cluster.

### 3.4 Kernel hardening: seccomp and AppArmor

- [ ] Inspect seccomp/AppArmor availability and loaded profiles on the scheduled node.
- [ ] Apply `RuntimeDefault` and Localhost seccomp profiles with current API fields.
- [ ] Write/load an AppArmor profile and attach it with current API fields.
- [ ] Distinguish enforce, complain, unconfined, RuntimeDefault, and Localhost behavior.
- [ ] Schedule workloads only where required local profiles exist.
- [ ] Trigger a forbidden action and verify enforcement via status/logs.

## 4. Minimize Microservice Vulnerabilities — 20%

### 4.1 Pod Security Standards and security contexts

- [ ] Distinguish Privileged, Baseline, and Restricted Pod Security Standards.
- [ ] Configure Pod Security Admission namespace labels for enforce/audit/warn and versions.
- [ ] Set non-root UID/GID, `runAsNonRoot`, and filesystem group deliberately.
- [ ] Disable privilege escalation and privileged mode.
- [ ] Drop all capabilities and add back only the minimum required.
- [ ] Set `readOnlyRootFilesystem` and provide minimal writable volumes.
- [ ] Restrict host namespaces, hostPath, host ports, proc mounts, devices, and unsafe sysctls.
- [ ] Validate admission behavior and runtime identity/capabilities.

### 4.2 Secret management and encryption at rest

- [ ] Avoid secrets in images, command arguments, environment dumps, and plain manifests.
- [ ] Create and consume Secrets with minimal exposure and RBAC.
- [ ] Mount Secret volumes read-only and understand update behavior.
- [ ] Inspect the API server encryption configuration and provider order.
- [ ] Configure authenticated encryption plus an intentional fallback provider.
- [ ] Mount the encryption configuration into the API server safely.
- [ ] Re-encrypt existing Secrets and verify ciphertext directly in etcd.
- [ ] Rotate keys/providers without making existing data unreadable.

### 4.3 Workload isolation and multi-tenancy

- [ ] Combine namespaces, RBAC, NetworkPolicy, quotas/limits, and Pod Security Admission.
- [ ] Identify cross-tenant risks from nodes, volumes, credentials, and cluster-scoped resources.
- [ ] Configure RuntimeClass for sandboxed runtimes such as gVisor/Kata when present.
- [ ] Apply RuntimeClass scheduling/overhead concepts where required.
- [ ] Verify the sandbox runtime rather than trusting Pod status alone.

### 4.4 Pod-to-Pod encryption

- [ ] Distinguish NetworkPolicy authorization from encryption in transit.
- [ ] Identify when Cilium WireGuard/IPsec or Istio mTLS is appropriate.
- [ ] Inspect encryption/mTLS status using tools supplied by the environment.
- [ ] Configure or repair workload participation and policies as requested.
- [ ] Verify encrypted traffic and avoid claiming encryption from policy alone.

## 5. Supply Chain Security — 20%

### 5.1 Minimal and reproducible images

- [ ] Review Dockerfiles for oversized/untrusted bases, extra packages, shells, secrets, and root execution.
- [ ] Use minimal/distroless/multi-stage patterns appropriate to the workload.
- [ ] Pin images by digest or controlled version and understand mutability tradeoffs.
- [ ] Set a non-root user and minimize filesystem permissions/capabilities.
- [ ] Build and functionally test a hardened replacement image.

### 5.2 Supply-chain understanding and SBOM

- [ ] Map source, dependencies, build runner, registry, deployment, and runtime trust boundaries.
- [ ] Generate and inspect an SBOM with `bom` in the required format.
- [ ] Find unexpected/vulnerable components in an SBOM.
- [ ] Protect CI credentials and use isolated/ephemeral build workers.
- [ ] Recognize provenance, attestations, artifact repositories, and dependency pinning.

### 5.3 Artifact and registry policy

- [ ] Restrict permitted registries/repositories without bypass gaps.
- [ ] Understand signature/attestation verification at admission.
- [ ] Configure or repair supplied admission policy/webhook material.
- [ ] Use fail-closed behavior when explicitly required and evaluate availability tradeoffs.
- [ ] Test both allowed and denied images and inspect admission errors.

### 5.4 Static workload and image analysis

- [ ] Run Kubesec/KubeLinter or supplied static analyzers against manifests.
- [ ] Interpret findings and remediate the manifest, not merely silence the tool.
- [ ] Scan images with Trivy using requested severity and vulnerability filters.
- [ ] Distinguish OS-package and application-dependency vulnerabilities.
- [ ] Select a compliant image while preserving workload function.
- [ ] Record evidence of scan result and deployed digest/tag.

## 6. Monitoring, Logging, and Runtime Security — 20%

### 6.1 Behavioral analytics and Falco

- [ ] Locate Falco configuration, rule files, service, and output logs.
- [ ] Understand rule, condition, output, priority, tags, macros, and lists.
- [ ] Use supported event fields to scope host/container/Kubernetes activity.
- [ ] Create a precise custom rule with low false-positive risk.
- [ ] Reload/restart safely, generate the event, and verify the alert.

### 6.2 Threat detection across infrastructure and workloads

- [ ] Investigate suspicious processes, shells, files, sockets, users, and containers.
- [ ] Correlate Kubernetes objects with container-runtime/process information.
- [ ] Detect crypto-mining, reverse shells, credential access, persistence, and unexpected tooling patterns.
- [ ] Preserve evidence and avoid destroying the signal before recording it.

### 6.3 Attack investigation and attribution

- [ ] Build a timeline from audit, runtime, host, and workload evidence.
- [ ] Identify initial access, execution, persistence, privilege escalation, credential access, lateral movement, and impact.
- [ ] Find the responsible identity, source address, user agent, object, command, and affected workload.
- [ ] Write exact requested findings to the required path/format.

### 6.4 Runtime immutability

- [ ] Enforce read-only root filesystems and provide only necessary writable mounts.
- [ ] Prevent privilege escalation and remove mutation tooling/capabilities.
- [ ] Understand immutable tags versus image digests and runtime filesystem immutability.
- [ ] Verify application health and failed unauthorized writes.

### 6.5 Kubernetes audit logging

- [ ] Write ordered audit-policy rules with appropriate levels and stages.
- [ ] Scope users, groups, verbs, namespaces, resources, subresources, and non-resource URLs.
- [ ] Configure API server audit policy/log flags and host mounts.
- [ ] Set log rotation parameters and file permissions.
- [ ] Recover the API server and verify audit event generation.
- [ ] Query audit JSON efficiently to answer forensic questions.

## 7. Legacy awareness — not a current mastery gate

- [ ] Recognize PodSecurityPolicy as removed and translate old exercises to Pod Security Admission/security contexts.
- [ ] Recognize deprecated annotations or beta API versions and rewrite them using current fields/APIs.
- [ ] Treat community-repository exam prices, versions, weights, and question counts as historical unless confirmed officially.

## Progress summary

- Current domain: Cluster Hardening
- Current topic: Restrict Kubernetes API access
- Active question: CKS-020
- Topic first-attempt mastery streak: 0
- Completed mastery topics: 7 (Service-account safety completed with direct assistance; verification was skipped)