# CKS Mastery Checklist Canonical progress record for CKS preparation. Update this file after every graded task so another computer or agent can resume without relying on chat history. ## Dashboard Last updated: 2026-08-27 | Domain | Weight | Hero | Training | Not started | Total | |---|---:|---:|---:|---:|---:| | Cluster Setup | 15% | 0 | 5 | 0 | 5 | | Cluster Hardening | 15% | 0 | 3 | 1 | 4 | | System Hardening | 10% | 0 | 2 | 2 | 4 | | Minimize Microservice Vulnerabilities | 20% | 0 | 4 | 0 | 4 | | Supply Chain Security | 20% | 0 | 3 | 1 | 4 | | Monitoring, Logging and Runtime Security | 20% | 0 | 5 | 0 | 5 | | **Total** | **100%** | **0** | **22** | **4** | **26** | The syllabus supplied for this program contains 26 tracked topics. ## Status Legend - `[ ] NOT STARTED`: no dedicated practical evidence. - `[~] TRAINING`: relevant lessons exist, but the Hero gate is incomplete. - `[x] HERO`: tool drill, timed capstone, evidence, and cold retest all passed. - `BLOCKED`: environment prevents practice; record the exact limitation and use a valid alternate environment. ## Hero Gate A topic becomes Hero only when every item is checked: - [ ] Tool drill completed using the topic's primary operational tools. - [ ] Original capstone completed at exam difficulty or harder within its time limit. - [ ] Verification evidence saved: commands plus meaningful output, not YAML alone. - [ ] No critical security or scope error remains after review. - [ ] Cold retest passed in a later session without stepwise prompting. - [ ] Evidence paths and date added to this checklist. Minor syntax corrections during training are expected. A cold retest fails when the solution needs field-by-field coaching, grants excess privilege, breaks required behavior, omits proof, or changes resources outside scope. ## Exam-Simulation Rules - Every graded question is a Linux command-line lab on a designated host or Kubernetes context. - Prompts specify an end state; the learner changes files, resources, processes, or policies to reach it. - Deliverables are the resulting state plus short command/output evidence. Essays, prose tables, PowerShell parsing, and multiple-choice answers are not graded tasks. - Tools are used directly when the syllabus names them. A scanner task requires running the scanner and changing the system, not writing about scanner theory. - Harder-than-exam means more interacting controls, realistic faults, or a tighter time limit. It does not mean more literature questions. - When the current computer lacks the required Linux/Kubernetes environment, mark the task environment-blocked and use a Linux lab; do not replace it with a written substitute. ## Resume Protocol 1. Read `MISSION.md`, `NOTES.md`, the newest learning record, and this file. 2. Show the dashboard and list Hero, Training, Not Started, and Blocked topics. 3. Continue `Next task` unless the learner selects another topic. 4. Save each answer under `lab/`, each lesson under `lessons/`, and durable insight under `learning-records/`. 5. After grading, update status, Hero-gate boxes, evidence, attempt log, dashboard counts, and `Next task`. 6. Show the learner the updated done-versus-remaining summary. ## Next Task Finish the one-time local lab installation after Windows restarts, then run `CS-02.Q1` as revised Lesson 0036 on `kind-cks-lab`. Do not use the learner's Kubernetes v1.36 production cluster: kube-bench v0.16.0 has automatic version mappings only through v1.34. ## Local Lab Environment Status: `WINDOWS RESTART REQUIRED` - Platform: Ubuntu 24.04 on WSL2, Docker Engine, two-node Kind cluster, and Calico. - Kubernetes: pinned to v1.34.0; kube-bench: pinned to v0.16.0. - Cluster and context: `cks-lab` / `kind-cks-lab`. - Kubeconfig: `/opt/cks-lab/kubeconfig`; it is never merged with a production config. - Setup and recovery files: `lab-environment/`. - Resume after restart: run `lab-environment\\02-install-and-build.ps1`, then `lab-environment\\verify-lab.ps1`. - Lesson scope: use Kind nodes for Kubernetes tasks and the disposable Ubuntu WSL2 VM for host/kernel hardening tasks. --- ## Cluster Setup - 15% ### CS-01 - Use network security policies to restrict cluster-level access Status: `[~] TRAINING` Tools: `kubectl`, NetworkPolicy API, `curl`/`wget`, temporary test Pods, CNI policy observability where available. Prior evidence: Lessons 0002, 0008, 0029, and 0034. The learner can build default-deny and selector-scoped ingress/egress policies, include CoreDNS, and combine Namespace and Pod selectors. Question bank: - `CS-01.Q1` - Given five namespaces and six traffic requirements, produce the minimum additive policy set and prove every allowed and denied flow with disposable client Pods. - `CS-01.Q2` - Repair a policy where split peer items accidentally OR namespace and Pod selectors; demonstrate the over-permitted flow before and denial after. - `CS-01.Q3` - Isolate control-plane and node endpoints from an application namespace while preserving DNS and one internal API dependency. - `CS-01.Q4` - Hard capstone: troubleshoot a syntactically valid policy that has no effect because of selectors, CNI behavior, or existing additive policies; submit packet-flow evidence. Hero-specific acceptance: prove ingress and egress outcomes, explain additive policy behavior, and avoid wildcard peers, IP-based shortcuts, or accidental DNS failure. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### CS-02 - Use CIS benchmarks to review Kubernetes components Status: `[~] TRAINING` Tools: `kube-bench`, `systemctl`, `ps`, `grep`, `kubectl`, static manifests, kubelet config, CoreDNS ConfigMap. Prior evidence: Lessons 0015, 0022, 0028, and 0035 cover kubelet and kube-apiserver manually. Dedicated kube-bench, etcd, and CoreDNS review evidence is missing. Question bank: - `CS-02.Q1` - Run `kube-bench` for control-plane and node checks; classify PASS, FAIL, WARN, and manual checks without blindly applying recommendations. - `CS-02.Q2` - Harden an etcd static manifest: client certificate authentication, peer TLS, trusted CAs, ownership, and metrics exposure; preserve cluster membership flags. - `CS-02.Q3` - Review kubelet flags plus `KubeletConfiguration`, reconcile conflicting settings, and verify the effective running process. - `CS-02.Q4` - Review CoreDNS deployment, ServiceAccount, RBAC, ConfigMap, image, and security context; distinguish CIS-relevant component configuration from workload hardening. - `CS-02.Q5` - Hard capstone: given kube-bench output containing false positives and manual checks, remediate only proven failures across API server, etcd, kubelet, and CoreDNS. Hero-specific acceptance: correlate scanner output with effective configuration and preserve required component behavior. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### CS-03 - Properly set up Ingress with TLS Status: `[~] TRAINING` Tools: `openssl`, `kubectl`, Ingress API, TLS Secrets, `curl -vk`, `openssl s_client`. Prior evidence: Lesson 0016. Ingress v1 nesting and host alignment required correction; live certificate inspection needs more practice. Question bank: - `CS-03.Q1` - Generate a certificate and key, create a TLS Secret, configure v1 Ingress, and verify hostname, chain, and backend routing. - `CS-03.Q2` - Repair mismatched rule host, TLS host, Secret namespace, backend schema, and path type without changing the Service. - `CS-03.Q3` - Use `openssl s_client` and `curl --resolve` to distinguish certificate, DNS, Ingress, and backend failures. - `CS-03.Q4` - Hard capstone: migrate two HTTP routes to TLS with separate hostnames and prove that plaintext behavior matches stated redirect requirements. Hero-specific acceptance: certificate identity, Secret scope, route semantics, and end-to-end TLS evidence must all be correct. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### CS-04 - Protect node metadata and endpoints Status: `[~] TRAINING` Tools: NetworkPolicy, `curl`, cloud metadata addresses, CNI policy tools, workload identity controls, `ss`, `systemctl`, kubelet configuration, client certificates. Prior evidence: Lessons 0015, 0028, and 0029 cover link-local metadata isolation plus kubelet anonymous auth, webhook modes, read-only port, and certificate rotation. Question bank: - `CS-04.Q1` - Demonstrate metadata reachability from a disposable Pod, then deny it without breaking required internal egress. - `CS-04.Q2` - Compare broad `ipBlock` denial with positive egress allowlisting and explain residual paths through proxies or host networking. - `CS-04.Q3` - Harden a cloud workload using both network isolation and workload identity rather than static cloud credentials. - `CS-04.Q4` - Hard capstone: contain metadata access for selected tenants while preserving DNS, API-server access, and one external HTTPS destination. - `CS-04.Q5` - Enumerate listening Kubernetes node endpoints and identify which require authentication, authorization, or removal. - `CS-04.Q6` - Harden kubelet config and prove anonymous requests fail while authorized health and management paths remain functional. - `CS-04.Q7` - Review metrics, health, debug, and read-only ports; distinguish binding exposure from application-layer authorization. - `CS-04.Q8` - Hard capstone: remediate metadata, kubelet, and node-firewall exposure together, then prove effective endpoint behavior. Hero-specific acceptance: show before-and-after metadata requests, verify listening sockets and authenticated endpoint behavior, and identify NetworkPolicy limitations for host-network or unsupported CNI cases. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### CS-05 - Verify platform binaries before deploying Status: `[~] TRAINING` Tools: `sha256sum`/`Get-FileHash`, signed checksum files, `gpg`, release metadata, package-manager verification. Prior evidence: Lesson 0019 verifies pinned Kubernetes binaries against checksums. Question bank: - `CS-05.Q1` - Download a pinned Kubernetes binary and official checksum, verify it, and record provenance. - `CS-05.Q2` - Detect a tampered binary among valid artifacts without executing any candidate. - `CS-05.Q3` - Verify a signed checksum manifest with GPG, then verify the binary against that trusted manifest. - `CS-05.Q4` - Hard capstone: build a repeatable verification chain for kubelet, kubectl, and a security scanner, including failure handling. Hero-specific acceptance: pin versions, verify the trust root, fail closed on mismatch, and save exact commands and hashes. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest --- ## Cluster Hardening - 15% ### CH-01 - Use RBAC to minimize exposure Status: `[~] TRAINING` Tools: `kubectl auth can-i`, `kubectl auth reconcile`, RBAC API, impersonation flags, structured manifest inspection. Prior evidence: Lessons 0003, 0009, and 0024. Namespace scope, subresources, `resourceNames`, and negative permission tests are established strengths after correction. Question bank: - `CH-01.Q1` - Replace a wildcard Role with the smallest verbs, API groups, resources, subresources, and named resources that satisfy a workload. - `CH-01.Q2` - Find privilege-escalation paths involving bind, escalate, impersonate, token creation, and workload creation. - `CH-01.Q3` - Prove positive and negative permissions using impersonation for users, groups, and ServiceAccounts. - `CH-01.Q4` - Hard capstone: remediate overlapping RoleBindings and ClusterRoleBindings without breaking one required cross-namespace workflow. Hero-specific acceptance: no wildcard privilege, every required permission proven, and every prohibited permission denied. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### CH-02 - Exercise caution with ServiceAccounts Status: `[~] TRAINING` Tools: `kubectl`, TokenRequest API, projected ServiceAccount tokens, RBAC, Pod inspection. Prior evidence: Lessons 0007 and 0034 cover automount suppression and least privilege. Question bank: - `CH-02.Q1` - Disable the default token for a namespace and enable a short-lived projected token only for one container with a fixed audience. - `CH-02.Q2` - Replace use of the default ServiceAccount with a dedicated identity and minimal Role/RoleBinding. - `CH-02.Q3` - Inspect a Pod for legacy Secret-based tokens, projected tokens, audiences, expiration, and unintended mounts. - `CH-02.Q4` - Hard capstone: preserve one API-calling sidecar while preventing every other container from receiving cluster credentials. Hero-specific acceptance: token exposure and RBAC authority must both be minimized and verified. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### CH-03 - Restrict access to the Kubernetes API Status: `[~] TRAINING` Tools: kube-apiserver flags, authentication and authorization config, admission plugins, firewall/listener inspection, audit logs. Prior evidence: Lessons 0022 and 0035 cover anonymous auth, Node/RBAC authorization, ServiceAccount lookup, profiling, NodeRestriction, and audit integration. Question bank: - `CH-03.Q1` - Harden an API-server static manifest while preserving certificates, etcd, ServiceAccount signing, and admission configuration. - `CH-03.Q2` - Restrict network reachability to the secure API endpoint and prove unauthorized and authorized outcomes. - `CH-03.Q3` - Identify dangerous authentication files, anonymous paths, permissive authorization, and insecure profiling/debug exposure. - `CH-03.Q4` - Hard capstone: reconcile flags with structured authentication/authorization configuration and verify the effective process. Hero-specific acceptance: preserve control-plane availability and prove both network and request-layer restrictions. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### CH-04 - Upgrade Kubernetes to avoid vulnerabilities Status: `[ ] NOT STARTED` Tools: `kubeadm`, `kubectl drain`, `apt`/`dnf`, package holds, version-skew policy, release notes. Prior evidence: none dedicated. Question bank: - `CH-04.Q1` - Inspect current versions, choose a supported target using version-skew rules, and produce the control-plane upgrade plan. - `CH-04.Q2` - Upgrade `kubeadm`, run `kubeadm upgrade plan`, apply the selected version, then upgrade kubelet and kubectl safely. - `CH-04.Q3` - Drain, upgrade, restart, and uncordon a worker while preserving workload availability. - `CH-04.Q4` - Hard capstone: recover from a partially completed upgrade with mismatched kubeadm, kubelet, and API-server versions. Hero-specific acceptance: version selection, node ordering, drain behavior, package holds, health verification, and rollback reasoning must be demonstrated. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest --- ## System Hardening - 10% ### SH-01 - Minimize host OS footprint Status: `[ ] NOT STARTED` Tools: `systemctl`, `ss`, `ps`, package manager, filesystem permissions, system logs. Prior evidence: none dedicated. Question bank: - `SH-01.Q1` - Inventory installed packages, running services, listening sockets, and scheduled jobs on a Kubernetes node. - `SH-01.Q2` - Disable and remove unnecessary services without disrupting kubelet, runtime, networking, storage, or time synchronization. - `SH-01.Q3` - Review sensitive Kubernetes directories and correct unsafe ownership or permissions. - `SH-01.Q4` - Hard capstone: reduce an intentionally bloated node image and prove cluster health plus reduced attack surface. Hero-specific acceptance: every removal needs a dependency justification and post-change node-health evidence. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### SH-02 - Use least-privilege host identity and access management Status: `[ ] NOT STARTED` Tools: Linux users/groups, `sudo`, SSH configuration, systemd unit identity, file capabilities, ownership and modes. Prior evidence: Kubernetes RBAC experience exists, but host IAM has no dedicated practical evidence. Question bank: - `SH-02.Q1` - Replace shared root access with named accounts and narrowly scoped sudo commands. - `SH-02.Q2` - Run a node service under a dedicated non-login account with minimal filesystem access. - `SH-02.Q3` - Audit SSH root login, password authentication, authorized keys, group membership, and sudoers fragments. - `SH-02.Q4` - Hard capstone: contain a compromised maintenance account without breaking kubelet or container runtime operation. Hero-specific acceptance: prove denied privilege escalation and preserved operational access using audit-friendly named identities. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### SH-03 - Minimize external network access Status: `[~] TRAINING` Tools: `ss`, `nft`/`iptables`, cloud firewall/security groups, host firewall, `curl`, `nc`, NetworkPolicy. Prior evidence: Lessons 0015, 0029, and 0034 cover workload and kubelet exposure; host-firewall evidence is missing. Question bank: - `SH-03.Q1` - Enumerate listeners and map each socket to process, interface, required clients, and authentication control. - `SH-03.Q2` - Restrict node management ports to an administration CIDR while preserving cluster traffic. - `SH-03.Q3` - Distinguish host firewall, cloud firewall, Service exposure, and NetworkPolicy responsibilities. - `SH-03.Q4` - Hard capstone: reduce external exposure across a node, NodePort Service, and host-network workload, then prove allowed and denied paths. Hero-specific acceptance: evidence must cover effective listeners and remote reachability from both permitted and prohibited sources. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### SH-04 - Use AppArmor and seccomp appropriately Status: `[~] TRAINING` Tools: `apparmor_parser`, `aa-status`, AppArmor profiles, seccomp profiles, Pod securityContext, runtime events. Prior evidence: Lessons 0004, 0011, and 0033. AppArmor enforcement was blocked by the Docker Desktop/WSL2 kernel; seccomp manifest work is established. Question bank: - `SH-04.Q1` - Create, load, and enforce an AppArmor profile that permits required reads but denies a sensitive write. - `SH-04.Q2` - Apply `RuntimeDefault` seccomp and diagnose a workload that requires a narrowly justified custom profile. - `SH-04.Q3` - Compare Pod-level and container-level profile scope and prove enforcement with an attempted forbidden operation. - `SH-04.Q4` - Hard capstone: harden a multi-container workload with different profiles and debug a node/profile-name mismatch. Hero-specific acceptance: must run on an AppArmor-enabled Linux host for AppArmor Hero; manifest-only evidence remains Training. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest --- ## Minimize Microservice Vulnerabilities - 20% ### MM-01 - Use appropriate Pod Security Standards Status: `[~] TRAINING` Tools: Pod Security Admission labels, PSS documentation, dry runs, admission output, workload security contexts. Prior evidence: Lessons 0005, 0021, 0031, 0033, and 0034. Question bank: - `MM-01.Q1` - Classify workloads against Privileged, Baseline, and Restricted, identifying every violating field. - `MM-01.Q2` - Migrate a namespace through warn, audit, and enforce with pinned policy versions and no avoidable outage. - `MM-01.Q3` - Remediate a Deployment to Restricted while preserving required writable paths and network binding. - `MM-01.Q4` - Hard capstone: manage exemptions and mixed legacy workloads without weakening the entire namespace. Hero-specific acceptance: prove admitted compliant workloads and rejected noncompliant workloads at the correct scope. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### MM-02 - Manage Kubernetes Secrets Status: `[~] TRAINING` Tools: Secret API, projected volumes, encryption configuration, RBAC, `etcdctl`, rotation workflow. Prior evidence: Lessons 0010, 0018, and 0032 cover selective projection, encryption at rest, exposure investigation, and rotation reasoning. Question bank: - `MM-02.Q1` - Project only one Secret key into one container with correct file mode and no environment-variable exposure. - `MM-02.Q2` - Configure encryption at rest, rewrite existing Secrets, and prove ciphertext in etcd plus readable API behavior. - `MM-02.Q3` - Identify Secret exposure through RBAC, Pod specs, logs, shell history, and mounted tokens; remediate each path. - `MM-02.Q4` - Hard capstone: rotate an accessed external credential across producers and consumers without retaining the old value. Hero-specific acceptance: minimize distribution, prove storage encryption, and demonstrate actual credential invalidation. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### MM-03 - Implement isolation and multi-tenancy Status: `[~] TRAINING` Tools: namespaces, RBAC, quotas, NetworkPolicy, Pod Security Admission, admission policy, RuntimeClass/sandboxed runtime. Prior evidence: Lessons 0017, 0031, and 0034 cover scoped admission and workload/network isolation. Sandboxed runtime evidence is missing. Question bank: - `MM-03.Q1` - Build a tenant namespace baseline combining RBAC, quotas, PSS, default-deny networking, and dedicated ServiceAccounts. - `MM-03.Q2` - Prevent host namespace, privileged, hostPath, and unsafe capability use with correctly scoped admission logic. - `MM-03.Q3` - Configure and select a sandboxed RuntimeClass, then verify the effective runtime handler. - `MM-03.Q4` - Hard capstone: isolate two tenants while preserving one explicitly shared service and administrative break-glass path. Hero-specific acceptance: prove cross-tenant denials at API, network, storage, and runtime boundaries. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### MM-04 - Implement Pod-to-Pod encryption Status: `[~] TRAINING` Tools: Cilium CLI/status, WireGuard status, Istio `istioctl`, PeerAuthentication, AuthorizationPolicy, traffic capture where allowed. Prior evidence: Lessons 0023, 0025, and 0026 cover Cilium WireGuard, Istio strict mTLS, and workload authorization. Question bank: - `MM-04.Q1` - Enable Cilium WireGuard and prove node encryption status plus encrypted Pod traffic. - `MM-04.Q2` - Enforce namespace-wide Istio STRICT mTLS and identify workloads that fail because they lack sidecars. - `MM-04.Q3` - Pair mTLS with AuthorizationPolicy so encryption does not become mistaken for authorization. - `MM-04.Q4` - Hard capstone: diagnose mixed plaintext/encrypted traffic across namespaces and prove the final data path. Hero-specific acceptance: use implementation-specific status tools and traffic evidence, not policy YAML alone. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest --- ## Supply Chain Security - 20% ### SC-01 - Minimize base image footprint Status: `[ ] NOT STARTED` Tools: Docker/BuildKit, multi-stage builds, distroless or minimal images, Trivy, Dive where available. Prior evidence: no dedicated image-rebuild and comparison task. Question bank: - `SC-01.Q1` - Convert a development image into a multi-stage production build with no compiler or package manager in the final stage. - `SC-01.Q2` - Compare package count, size, users, shell availability, and vulnerability results before and after minimization. - `SC-01.Q3` - Run the final image as non-root with a read-only root filesystem and explicit writable paths. - `SC-01.Q4` - Hard capstone: minimize an image without breaking TLS roots, timezone data, health checks, or runtime dependencies. Hero-specific acceptance: quantitative before/after evidence plus successful runtime behavior is required. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### SC-02 - Understand the supply chain Status: `[~] TRAINING` Tools: Syft, CycloneDX/SPDX, CI logs, artifact repositories, provenance/attestations, dependency metadata. Prior evidence: Lesson 0030 generates and interprets a CycloneDX SBOM with Syft. Question bank: - `SC-02.Q1` - Generate CycloneDX and SPDX SBOMs with Syft and compare component identity and relationships. - `SC-02.Q2` - Trace a deployed digest back through registry metadata, build job, source revision, and SBOM. - `SC-02.Q3` - Use an SBOM to answer impact from a newly disclosed component vulnerability without claiming exploitability. - `SC-02.Q4` - Hard capstone: investigate a mismatched SBOM, image digest, and deployment reference and identify the broken provenance link. Hero-specific acceptance: distinguish inventory, vulnerability, provenance, signature, and deployment policy evidence. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### SC-03 - Secure permitted registries and validate artifacts Status: `[~] TRAINING` Tools: Cosign, container registry, image digests, admission policy, public-key or keyless verification, attestations. Prior evidence: Lessons 0013 and 0019 cover digest enforcement and artifact checksum verification. Cosign signing and verification are missing. Question bank: - `SC-03.Q1` - Sign a pinned image digest with Cosign and verify it using the intended trust identity. - `SC-03.Q2` - Enforce an allowed registry and immutable digest policy across regular, init, and ephemeral containers. - `SC-03.Q3` - Validate an SBOM or provenance attestation and reject a signature from the wrong identity or repository. - `SC-03.Q4` - Hard capstone: admit only correctly signed images from permitted registries while preserving an audited break-glass process. Hero-specific acceptance: verification must bind identity, repository, and digest; signature presence alone is insufficient. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### SC-04 - Perform static analysis of workloads and images Status: `[~] TRAINING` Tools: Kubesec, KubeLinter, Trivy config/image, scanner exit codes, CI integration. Prior evidence: Lesson 0027 uses Trivy configuration scanning. Kubesec, KubeLinter, and Trivy image scanning remain unpracticed. Question bank: - `SC-04.Q1` - Scan the same manifest with Kubesec, KubeLinter, and Trivy; normalize overlapping and tool-specific findings. - `SC-04.Q2` - Scan a pinned image with Trivy, prioritize exploitable/runtime-relevant findings, and avoid equating count with risk. - `SC-04.Q3` - Configure CI to fail on a justified severity/fixability policy while preserving machine-readable reports. - `SC-04.Q4` - Hard capstone: remediate manifest and image findings, rerun every scanner, and explain accepted residual risk and false positives. Hero-specific acceptance: use at least three named tools, preserve raw reports, and distinguish configuration from package-vulnerability results. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest --- ## Monitoring, Logging and Runtime Security - 20% ### MR-01 - Perform behavioral analytics Status: `[~] TRAINING` Tools: Falco, rule files, JSON output, baseline comparison, process/network telemetry. Prior evidence: Lesson 0020 covers runtime shell detection with Falco-style evidence. Question bank: - `MR-01.Q1` - Establish a workload behavior baseline and identify process, file, and network deviations. - `MR-01.Q2` - Write and test a Falco rule for an interactive shell or sensitive file access inside a container. - `MR-01.Q3` - Tune a noisy rule using workload identity and syscall context without hiding real attacks. - `MR-01.Q4` - Hard capstone: correlate multiple low-confidence events into one high-confidence malicious sequence. Hero-specific acceptance: provide triggering and non-triggering tests plus a justified noise-control strategy. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### MR-02 - Detect threats across infrastructure, apps, networks, data, users, and workloads Status: `[~] TRAINING` Tools: Falco, audit logs, host logs, NetworkPolicy/CNI flow logs, application logs, identity events, file-integrity evidence. Prior evidence: Lessons 0012, 0020, and 0032 cover API and runtime signals; full cross-layer correlation is missing. Question bank: - `MR-02.Q1` - Map one signal source and one high-value detection to each of the six threat surfaces. - `MR-02.Q2` - Detect suspicious node login, privileged workload creation, lateral network movement, Secret access, and runtime execution. - `MR-02.Q3` - Separate preventive controls from detective evidence and identify blind spots in each layer. - `MR-02.Q4` - Hard capstone: correlate host, Kubernetes, network, and application telemetry into one defensible incident timeline. Hero-specific acceptance: identify principal, asset, action, outcome, source, and timestamp from more than one telemetry layer. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### MR-03 - Investigate phases of attack and bad actors Status: `[~] TRAINING` Tools: `jq`/PowerShell JSON parsing, audit logs, Falco events, Pod and RBAC inspection, timeline notes. Prior evidence: Lessons 0012 and 0032 reconstruct escalation, Secret access, and exec activity with ordered containment. Question bank: - `MR-03.Q1` - Reconstruct initial access, privilege escalation, discovery, credential access, execution, and persistence from mixed logs. - `MR-03.Q2` - Distinguish rejected attempts from successful actions using response codes and runtime outcomes. - `MR-03.Q3` - Pivot by authenticated principal, source IP, workload identity, resource, and time without using audit IDs as identities. - `MR-03.Q4` - Hard capstone: produce a concise incident report with evidence, confidence, blast radius, and ordered containment. Hero-specific acceptance: include the exact structured query command and cite the event evidence for every conclusion. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### MR-04 - Ensure container immutability at runtime Status: `[~] TRAINING` Tools: securityContext, read-only root filesystem, volumes, image digests, admission policy, Falco/file-integrity checks. Prior evidence: Lessons 0006, 0013, 0033, and 0034 cover immutable images and read-only roots with explicit writable volumes. Question bank: - `MR-04.Q1` - Harden a workload with read-only roots and discover every required writable runtime path empirically. - `MR-04.Q2` - Enforce digest-only image references and prove mutable-tag rejection. - `MR-04.Q3` - Detect executable creation or package installation inside a running container and contain it. - `MR-04.Q4` - Hard capstone: combine preventive admission, runtime filesystem controls, and behavioral detection without breaking the application. Hero-specific acceptance: prove immutable image identity, failed root writes, allowed explicit writes, and runtime alert behavior. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest ### MR-05 - Use Kubernetes audit logs to monitor access Status: `[~] TRAINING` Tools: audit Policy, kube-apiserver flags and mounts, `jq`, log rotation, event correlation. Prior evidence: Lessons 0012, 0014, 0032, and 0035 cover policy design, persistent logging, filtering, and incident reconstruction. Question bank: - `MR-05.Q1` - Design an ordered audit policy for Secrets, RBAC changes, Pod exec, authentication failures, and a Metadata catch-all. - `MR-05.Q2` - Configure file-backend persistence and rotation in a kube-apiserver static Pod and prove the effective process flags. - `MR-05.Q3` - Write structured queries for principal, source, verb, resource, response code, and time windows. - `MR-05.Q4` - Hard capstone: diagnose missing events caused by rule ordering, level choice, omitted stages, path mounts, or log rotation. Hero-specific acceptance: prove event generation end to end from API request through persisted log and structured query. Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest --- ## Attempt Log Append one row after every graded attempt. | Date | Task | Topic | Time | Result | Critical errors | Evidence | Next action | |---|---|---|---:|---|---:|---|---| | 2026-08-26 | Lesson 0035 | CH-03 / MR-05 | Not recorded | Training pass | 0 after review | `lab/lesson-35-kube-apiserver-answer.yaml`, `lab/lesson-35-audit-policy.yaml` | Cold retest later | | 2026-08-26 | Lesson 0034 | CS-01 / MM-01 | Not recorded | Training pass | 0 after review | `lab/lesson-34-answer.yaml` | Cold retest later | | 2026-08-25 | Lesson 0032 | MR-03 | Not recorded | Training; evidence incomplete | 0 substantive; command omitted | `lab/lesson-32-answer.md` | Require structured query next time | ## Current Summary Hero topics: none yet. Training topics: CS-01, CS-02, CS-03, CS-04, CS-05, CH-01, CH-02, CH-03, SH-03, SH-04, MM-01, MM-02, MM-03, MM-04, SC-02, SC-03, SC-04, MR-01, MR-02, MR-03, MR-04, MR-05. Not started: CH-04, SH-01, SH-02, SC-01. Blocked: AppArmor runtime enforcement on the current Docker Desktop/WSL2 kernel. Use an AppArmor-enabled Linux host for the Hero attempt.