598 lines
31 KiB
Markdown
598 lines
31 KiB
Markdown
# 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-26
|
|
|
|
| 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.
|
|
|
|
## 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
|
|
|
|
`CS-02.Q1` in progress as Lesson 0036: run a kube-bench-based CIS review and separate automated findings from manual checks across kube-apiserver, etcd, kubelet, and CoreDNS.
|
|
|
|
---
|
|
|
|
## 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.
|