1. Assessment Goal

This assessment verifies that you can assess Kubernetes risks structurally, harden workloads, formulate policies and document incident response. The focus is on threat modeling, API Server and Control Plane, RBAC, ServiceAccounts, Pod Security Standards, SecurityContext, NetworkPolicy, supply chain, Admission Control, Secrets Security, Runtime Detection, Compliance Evidence and Incident Response.

After the assessment it should be clear that you can:

• separate Kubernetes attack surfaces into API, nodes, workloads, network, Secrets and supply chain,
• identify RBAC permissions and privilege-escalation paths,
• deliberately reduce ServiceAccount token automounting,
• practically assess Pod Security Standards and SecurityContext,
• formulate NetworkPolicies with default deny, DNS and application allowances,
• evaluate image origin, tag, digest, scan, SBOM and signature status,
• classify Admission Policies in audit/warn/enforce mode,
• describe Secret flows and rotation realistically,
• translate runtime signals and audit evidence into responses,
• document incident response for a compromised Pod and a Secret leak.

2. Prerequisites and Allowed Resources

You need:

• a lab cluster,
• kubectl,
• permissions to create Namespaces, ServiceAccounts, RBAC, NetworkPolicies and test workloads,
• optionally Kyverno, OPA Gatekeeper or ValidatingAdmissionPolicy,
• optionally Trivy, Grype, Cosign or comparable supply-chain tools,
• optionally Falco, Tetragon, Tracee or comparable runtime signals.

Allowed resources:

• official Kubernetes documentation,
• workshop materials,
• your own notes,
• security checklists and internal policy templates,
• kubectl auth can-i, kubectl describe, events, logs and policy reports.

Not allowed:

• production Secrets or customer data,
• real registry or cloud credentials,
• destructive node or cluster operations without lab approval,
• deliberate exfiltration or attack actions outside the lab,
• changes to production clusters.

Recommended namespace:

export NS=exam-security

3. Scenario

A sample app checkout-api runs in namespace shop-prod. The review finds:

• The Deployment uses ServiceAccount checkout-sa.
• There is a Secret payment-api-token.
• The image comes from a private registry.
• A GitOps pipeline synchronizes manifests.
• A runtime alert reports an unexpected shell in the Pod.
• An old manifest contains privileged: true and a hostPath mount.
• NetworkPolicies are incomplete.
• The Secret rotation path is not documented.
• The security department requires evidence and production stop criteria.

You work in lab namespace exam-security. You must not modify the real shop-prod; instead, prove risks, controls and incident measures through reproducible examples and documents.

4. Expected Submission

Submit a folder or archive with these files:

04-advanced-security-submission/
  answers.md
  threat-model.md
  rbac-review.md
  serviceaccount-token-review.md
  pod-security-review.md
  hardened-deployment.yml
  networkpolicies.yml
  supply-chain-review.md
  admission-policy.md
  secrets-review.md
  runtime-detection.md
  compliance-evidence.md
  incident-runbook.md
  evidence/
    can-i.txt
    events.txt
    policy-results.txt
    logs-summary.txt
  cleanup.md

If specific tools are not available in the lab, document that and provide a technically correct substitute assessment. Example: If Cosign is not available, document which signature verification would be required in production and which stop criterion would apply.

5. Part A: Security Questions

Answer the questions with reference to the scenario.

1. What are the central attack surfaces of Kubernetes?
2. How do Authentication, Authorization and Admission Control interact?
3. Which risks arise from privileged: true, hostPath, hostNetwork, hostPID and hostIPC?
4. Why are ServiceAccounts and automatically mounted tokens security-relevant?
5. Which RBAC verbs or resources are particularly dangerous and why?
6. What do Pod Security Standards privileged, baseline and restricted provide?
7. Which SecurityContext fields do you expect for a hardened workload?
8. Why does NetworkPolicy reduce lateral movement but not replace encryption?
9. Why is DNS egress a separate point in default-deny policies?
10. Which supply-chain controls do you expect for production images?
11. Why are Kubernetes Secrets insufficiently protected despite Base64?
12. Which information belongs in reliable incident evidence?
13. What is the difference between prevention, detection and response?
14. Why do policy exceptions require owner, justification and expiry date?
15. Which immediate measures are required for a compromised Pod and Secret leak?

6. Part B: Threat Model and RBAC Audit

Task B1: Threat model

Create threat-model.md for checkout-api.

Required sections:

1. assets and protection value,
2. trust boundaries,
3. attack surfaces,
4. abuse scenarios,
5. existing controls,
6. missing controls,
7. stop criteria,
8. evidence.

Minimum assets:

Task B2: RBAC audit

Create two ServiceAccounts in the lab:

• app-sa,
• overprivileged-sa.

app-sa should receive only minimal read permissions on ConfigMaps.
overprivileged-sa should intentionally receive risky permissions, for example on Secrets or RoleBindings.

Check effective permissions with kubectl auth can-i.

Required evidence in evidence/can-i.txt:

kubectl auth can-i get configmaps --as system:serviceaccount:exam-security:app-sa -n exam-security
kubectl auth can-i get secrets --as system:serviceaccount:exam-security:app-sa -n exam-security
kubectl auth can-i get secrets --as system:serviceaccount:exam-security:overprivileged-sa -n exam-security
kubectl auth can-i create rolebindings --as system:serviceaccount:exam-security:overprivileged-sa -n exam-security

Document:

• which permissions are acceptable,
• which permissions are critical,
• which escalation path would be possible,
• what the fix looks like.

Task B3: ServiceAccount token automount

Create serviceaccount-token-review.md.

Tasks:

1. Create a Deployment no-api-app.
2. Set automountServiceAccountToken: false.
3. Check in the Pod whether a token was automatically mounted.
4. Explain when a workload needs Kubernetes API access and when it does not.

7. Part C: Workload, Network and Supply-Chain Hardening

Task C1: Pod Security Restricted

1. Set Pod Security labels for restricted in enforce, audit and warn on the lab namespace.
2. Try to create an unsafe Pod with privileged: true.
3. Document the rejection.
4. Create a hardened Pod or Deployment that meets Restricted requirements.

Expected hardening criteria:

• runAsNonRoot: true,
• defined non-root user,
• allowPrivilegeEscalation: false,
• readOnlyRootFilesystem: true,
• capabilities.drop: [ALL],
• seccompProfile: RuntimeDefault,
• no host namespace usage,
• no uncontrolled hostPath,
• writable path only through emptyDir or a dedicated volume.

Task C2: Hardened Deployment

Create hardened-deployment.yml for a safe example application.

The manifest must contain:

• namespace exam-security,
• ServiceAccount without unnecessary API token,
• Pod and container SecurityContext,
• resource Requests and Limits,
• Readiness Probe where technically meaningful,
• clear labels owner, environment, app,
• no real Secrets.

Task C3: NetworkPolicy

Create networkpolicies.yml with:

1. default deny for Ingress and Egress,
2. DNS egress allowance,
3. allowance from frontend to backend on TCP port 8080,
4. blocking of all other egress,
5. note whether the CNI enforces NetworkPolicies.

Document production follow-up questions:

• Does the Pod need to reach the Kubernetes API?
• Does the Pod need registry, logging, monitoring or external API destinations?
• Are there fixed external targets or only unrestricted internet egress rules?
• How is IPv6 or dual-stack considered?

Task C4: Supply-chain review

Create supply-chain-review.md for an example image.

Required fields:

• registry,
• repository,
• tag,
• digest,
• Pull Policy,
• ImagePullSecret,
• CVE scan result or expected scan process,
• SBOM status,
• signature status,
• build provenance,
• admission requirement,
• stop criterion.

At least these stop criteria must be evaluated:

• latest without digest in production,
• image from an unapproved registry,
• critical CVE without exception,
• missing signature for production workloads,
• Pull Secret without owner or rotation.

Task C5: Admission policy

Create admission-policy.md.

Choose at least two policy goals:

1. required labels owner, environment, cost-center,
2. prohibit privileged: true,
3. require runAsNonRoot: true,
4. require resource Requests and Limits,
5. only approved registries.

For each policy describe:

• goal,
• scope,
• audit/warn/enforce mode,
• example violation,
• exception process,
• rollback path if the policy is wrong.

You may use Kyverno, OPA Gatekeeper or ValidatingAdmissionPolicy. If none of these tools is available, describe the policy technically with pseudomanifest and operational mode.

8. Part D: Secrets, Detection, Compliance and Incident Response

Task D1: Secrets Security and rotation

Create secrets-review.md with:

1. Secret inventory,
2. access through RBAC,
3. mount type in the Pod,
4. risk in logs, events, images and backups,
5. etcd/backup risk,
6. rotation path,
7. comparison of Kubernetes Secret, External Secrets, CSI Secret Store, Sealed Secrets and SOPS,
8. incident measure in case of a leak.

Important: Do not use real Secrets. Example values must be clearly recognizable as example values.

Task D2: Runtime detection and audit signals

Create runtime-detection.md.

Define expected signals and responses for:

Task D3: Compliance evidence

Create compliance-evidence.md with at least five findings:

1. namespace without Pod Security label,
2. ServiceAccount with overly broad permissions,
3. Pod without Requests/Limits,
4. Secret without rotation note,
5. workload without NetworkPolicy.

For each finding document:

• time,
• resource,
• risk,
• evidence,
• owner,
• fix,
• exception with expiry date or remediation deadline,
• retest.

Task D4: Incident runbook

Create incident-runbook.md for a compromised Pod and Secret leak.

Required sections:

1. triage,
2. isolation,
3. evidence preservation,
4. containment,
5. Secret and token rotation,
6. image and CI check,
7. rebuild and redeploy,
8. communication,
9. lessons learned,
10. policy hardening.

Required evidence:

kubectl get pod <pod> -n <namespace> -o wide
kubectl get pod <pod> -n <namespace> -o yaml
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --all-containers
kubectl logs <pod> -n <namespace> --all-containers --previous
kubectl get sa,role,rolebinding -n <namespace>
kubectl auth can-i get secrets --as system:serviceaccount:<namespace>:<serviceaccount> -n <namespace>
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp

Also document when a Pod may be deleted immediately and when it should first be isolated for evidence reasons.

9. Grading

10. Knockout Criteria

The assessment fails regardless of point score if:

• real Secrets, customer data or production contexts are used,
• destructive actions are performed outside the lab,
• a production-like workload is allowed to run privileged without documented exception,
• Secret read permissions are accepted without technical need,
• incident evidence is destroyed before basic capture,
• the candidate cannot explain why Base64 is not encryption,
• no stop criteria for production are defined.

11. Examiner Checklist

• Threat model separates API, node, workload, network, Secrets and supply chain.
• kubectl auth can-i evidence exists for both ServiceAccounts.
• Token automount is disabled for a workload without API need.
• Pod Security Restricted is labelled and unsafe Pod rejection is documented.
• Hardened Deployment contains non-root, seccomp, dropped capabilities and read-only root filesystem.
• NetworkPolicies include default deny, DNS and application allowance.
• Supply-chain review covers registry, digest, scan, SBOM, signature and stop criteria.
• Admission policies have audit/warn/enforce mode, exceptions and rollback path.
• Secrets review includes RBAC, mount, rotation, backups and leak response.
• Runtime detection and compliance evidence are actionable.
• Incident runbook covers triage, isolation, evidence, rotation, rebuild and policy improvement.