cks-final/CKS-SYLLABUS-CHECKLIST.md

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

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

1.2 CIS benchmark review

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

1.3 Ingress TLS

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

1.4 Node metadata and endpoint protection

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

1.5 Platform binary verification

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

2. Cluster Hardening — 15%

2.1 Least-privilege RBAC

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

2.2 Service-account safety

• Disable token automounting at ServiceAccount and/or Pod level.
• Create dedicated ServiceAccounts per workload.
• Grant the smallest required RBAC permissions.
• Understand projected, time-bound ServiceAccount tokens and TokenRequest.
• Detect use of default ServiceAccounts and unnecessary API credentials.
• 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)