CKS-Lessons/learning-records/0004-retrieval-profile-through-lesson-13.md

Retrieval profile through Lessons 1–13

Demonstrated strengths

• Can produce and prove basic NetworkPolicy, namespace-scoped RBAC, workload hardening, Pod Security Admission, and ServiceAccount-token controls.
• Understands least-privilege RBAC after correction: namespace-scoped RoleBinding, pods/log as a subresource, and resourceNames for a single ConfigMap.
• Can apply RuntimeDefault seccomp, non-root execution, capability dropping, read-only roots, targeted emptyDir writable paths, and selective Secret-key projection.
• Understands the difference between an image tag and digest, and the roles of a ValidatingAdmissionPolicy versus its binding after a worked example.
• Correctly reconstructed the audit-event sequence: RBAC escalation, Secret access, then Pod exec.
• Completed the audit-policy design after correction: stage omission, ordered specific rules, Secret RequestResponse logging, RBAC API-group selection, and a Metadata catch-all.
• Completed kubelet endpoint hardening: anonymous authentication disabled, webhook authentication and authorization enabled, read-only port disabled, kernel defaults protected, and certificate rotation enabled.
• Completed TLS Ingress configuration after schema corrections: v1 Service backend uses singular service, TLS host aligns with the rule host, and route semantics distinguish Prefix from Exact.
• Completed a namespace-scoped tenant-isolation admission policy: a normal Pod is admitted, host networking is denied in the tenant namespace, and the same request remains permitted outside the binding scope.
• Completed Secrets encryption-at-rest configuration: a 32-byte base64 AES-CBC key is first for Secret writes, with identity retained only as the final read fallback.
• Completed a Pod Security Admission migration: all enforce/audit/warn labels and version pins were set, the existing legacy Pod remained running, a compliant replacement became Ready, and a non-compliant new Pod was rejected.
• Completed kube-apiserver static-Pod hardening: anonymous access disabled, Node/RBAC authorization selected, ServiceAccount lookup enabled, profiling disabled, and an explicit audit-log path configured while preserving required API-server flags.
• Completed focused RBAC remediation independently: narrowed an existing Role so its ServiceAccount retains ConfigMap read/watch access but cannot read Secrets or create ConfigMaps.
• Completed the first supplemental Istio security drill independently: namespace-wide PeerAuthentication uses the current v1 API and strict mTLS without an unnecessary selector or port exception.
• Completed supplemental Istio workload authorization after incremental review: an ALLOW policy selects only payments-api, grants only the exact web-mesh/frontend principal, and limits it to port 8080.
• Completed node-metadata egress isolation after one correction: a single frontend egress policy permits only the payments API on TCP 8080 and CoreDNS on TCP/UDP 53, leaving metadata and other internet access denied.
• Completed SBOM generation and interpretation: produced a pinned-image CycloneDX JSON inventory with Syft and correctly distinguished component inventory from vulnerability or deployment-safety proof.

Retrieval gaps to keep drilling

• SecurityContext field placement: allowPrivilegeEscalation and readOnlyRootFilesystem are container-level; seccomp, UID, and Pod-wide AppArmor can be Pod-level.
• Exact API field spelling: automountServiceAccountToken; YAML schema errors should be checked with server-side or client dry runs early.
• Secret projections: items requires both key and path; mount the volume directory rather than treating it as a single file path.
• NetworkPolicy composition and scope: policies are additive; use a separate default deny and selector-scoped exceptions. Default-deny egress also requires an explicit CoreDNS allowance for Service-name resolution.
• Runtime investigation: name the principal rather than audit IDs, and distinguish observed malicious actions from containment steps. First revoke the escalation path, then isolate the workload and rotate exposed credentials.
• Validating Admission Policy CEL and binding scope need further independent practice; Lesson 13 required a reference solution.
• Audit-policy resource spelling and groups required retrieval help: RBAC uses rbac.authorization.k8s.io; the resources are plural, including clusterroles and clusterrolebindings.
• Kubelet configuration requires careful schema recall: authorization is top-level, the kind is KubeletConfiguration, and readOnlyPort: 0 disables rather than configures the legacy endpoint.
• Ingress v1 schema and nesting need continued retrieval practice: Service backend is singular; multiple paths belong under http.paths; use Exact only for a precise path match.
• CEL admission policy practice exposed a key optional-field pattern: test the parent (has(c.securityContext)) before reading a child (c.securityContext.privileged); CEL short-circuiting prevents evaluation errors.
• Encryption-provider ordering and key generation required assistance: AES-CBC keys must decode to 32 bytes; generate random bytes before base64 encoding and keep identity last.
• Pod Security Admission retrieval required iterative correction: policy configuration belongs in Namespace labels (not Pod annotations), all mode labels need fixed version values, and security-context enum spelling is case-sensitive.
• API-server flag review shows good preservation discipline; reinforce the operational meaning of service-account-lookup=true as token revocation/validation protection.
• Continue using focused, one-concept practical drills before returning to multi-control configurations; this format is better calibrated for current retrieval confidence.

Environment limitation

Lesson 11 AppArmor could not execute: the Docker Desktop / WSL2 kernel reports AppArmor disabled. The structured Kubernetes API fields were valid, but any RuntimeDefault AppArmor Pod is rejected by the kubelet. Keep AppArmor as a manifest-reading skill here; test enforcement later on an AppArmor-enabled Linux host.

Coaching adjustment

Future lessons should remain from-scratch with only fixtures or requirements, emphasize exact API schemas and verification before applying, and revisit the retrieval gaps above in mixed scenarios.