# 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.