265 lines
14 KiB
Markdown
265 lines
14 KiB
Markdown
# 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)
|