1. Prüfungsziel

Die Prüfung weist nach, dass du Kubernetes-Risiken strukturiert bewerten, Workloads härten, Policies formulieren und Incident Response dokumentieren kannst. Der Schwerpunkt liegt auf Threat Modeling, API Server und Control Plane, RBAC, ServiceAccounts, Pod Security Standards, SecurityContext, NetworkPolicy, Supply Chain, Admission Control, Secrets Security, Runtime Detection, Compliance Evidence und Incident Response.

Nach der Prüfung soll erkennbar sein, dass du:

• Kubernetes-Angriffsflächen nach API, Nodes, Workloads, Netzwerk, Secrets und Supply Chain trennst,
• RBAC-Rechte und Privilege-Escalation-Pfade erkennst,
• ServiceAccount-Token-Automount bewusst reduzierst,
• Pod Security Standards und SecurityContext praktisch bewertest,
• NetworkPolicies mit Default Deny, DNS und App-Erlaubnissen formulierst,
• Image-Herkunft, Tag, Digest, Scan, SBOM und Signaturstatus bewertest,
• Admission Policies in Audit-/Warn-/Enforce-Modus einordnest,
• Secret-Flows und Rotation realistisch beschreibst,
• Runtime-Signale und Audit-Evidence in Reaktionen übersetzt,
• Incident Response für kompromittierten Pod und Secret Leak belastbar dokumentierst.

2. Voraussetzungen und erlaubte Hilfsmittel

Du brauchst:

• einen Lab-Cluster,
• kubectl,
• Rechte zum Erstellen von Namespaces, ServiceAccounts, RBAC, NetworkPolicies und Test-Workloads,
• optional Kyverno, OPA Gatekeeper oder ValidatingAdmissionPolicy,
• optional Trivy, Grype, Cosign oder vergleichbare Supply-Chain-Werkzeuge,
• optional Falco, Tetragon, Tracee oder vergleichbare Runtime-Signale.

Erlaubt sind:

• offizielle Kubernetes-Dokumentation,
• Workshop-Unterlagen,
• eigene Notizen,
• Security-Checklisten und interne Policy-Vorlagen,
• kubectl auth can-i, kubectl describe, Events, Logs und Policy Reports.

Nicht erlaubt sind:

• produktive Secrets oder Kundendaten,
• echte Registry- oder Cloud-Zugangsdaten,
• destruktive Node- oder Clusteroperationen ohne Lab-Freigabe,
• absichtliche Exfiltration oder Angriffshandlungen außerhalb des Labs,
• Änderungen an produktiven Clustern.

Empfohlener Namespace:

export NS=exam-security

3. Ausgangsszenario

Eine Beispiel-App checkout-api läuft im Namespace shop-prod. Im Review fällt auf:

• Das Deployment nutzt den ServiceAccount checkout-sa.
• Es gibt ein Secret payment-api-token.
• Das Image kommt aus einer privaten Registry.
• Eine GitOps-Pipeline synchronisiert Manifeste.
• Ein Runtime-Alarm meldet eine unerwartete Shell im Pod.
• Ein altes Manifest enthält privileged: true und einen hostPath-Mount.
• NetworkPolicies sind unvollständig.
• Der Secret-Rotation-Pfad ist nicht dokumentiert.
• Die Security-Abteilung verlangt Evidence und Stop-Kriterien für Produktion.

Du arbeitest im Lab-Namespace exam-security. Du sollst kein echtes shop-prod verändern, sondern die Risiken, Kontrollen und Incident-Maßnahmen anhand reproduzierbarer Beispiele und Dokumente nachweisen.

4. Erwartete Abgabe

Gib am Ende einen Ordner oder ein Archiv mit folgenden Dateien ab:

04-advanced-security-abgabe/
  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

Falls bestimmte Tools im Lab nicht vorhanden sind, dokumentiere dies und liefere eine fachlich korrekte Ersatzbewertung. Beispiel: Wenn Cosign nicht verfügbar ist, dokumentierst du, welche Signaturprüfung erforderlich wäre und welches Stop-Kriterium gelten würde.

5. Teil A: Security-Fachfragen

Beantworte die Fragen mit Bezug zum Szenario.

1. Welche zentralen Angriffsflächen hat Kubernetes?
2. Wie greifen Authentication, Authorization und Admission Control ineinander?
3. Welche Risiken entstehen durch privileged: true, hostPath, hostNetwork, hostPID und hostIPC?
4. Warum sind ServiceAccounts und automatisch gemountete Tokens sicherheitsrelevant?
5. Welche RBAC-Verben oder Ressourcen sind besonders gefährlich und warum?
6. Was leisten Pod Security Standards privileged, baseline und restricted?
7. Welche SecurityContext-Felder erwartest du bei einem gehärteten Workload?
8. Warum reduziert NetworkPolicy Lateral Movement, ersetzt aber keine Verschlüsselung?
9. Warum ist DNS-Egress bei Default-Deny-Policies ein eigener Punkt?
10. Welche Supply-Chain-Kontrollen erwartest du für produktive Images?
11. Warum sind Kubernetes Secrets trotz Base64 nicht ausreichend geschützt?
12. Welche Informationen gehören in eine belastbare Incident-Evidence?
13. Was ist der Unterschied zwischen Prävention, Detection und Response?
14. Warum brauchen Policy-Ausnahmen Owner, Begründung und Ablaufdatum?
15. Welche Sofortmaßnahmen sind bei kompromittiertem Pod und Secret Leak erforderlich?

6. Teil B: Threat Model und RBAC-Audit

Aufgabe B1: Threat Model

Erstelle threat-model.md für checkout-api.

Pflichtabschnitte:

1. Assets und Schutzwert,
2. Trust Boundaries,
3. Angriffsflächen,
4. Missbrauchsszenarien,
5. vorhandene Kontrollen,
6. fehlende Kontrollen,
7. Stop-Kriterien,
8. Evidence.

Mindest-Assets:

Aufgabe B2: RBAC-Audit

Erstelle im Lab zwei ServiceAccounts:

• app-sa,
• overprivileged-sa.

app-sa soll nur minimale Leserechte auf ConfigMaps erhalten.
overprivileged-sa soll absichtlich riskante Rechte bekommen, zum Beispiel auf Secrets oder RoleBindings.

Prüfe effektive Rechte mit kubectl auth can-i.

Pflichtnachweise 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

Dokumentiere:

• welche Rechte akzeptabel sind,
• welche Rechte kritisch sind,
• welcher Eskalationspfad möglich wäre,
• wie der Fix aussieht.

Aufgabe B3: ServiceAccount Token-Automount

Erstelle serviceaccount-token-review.md.

Aufgabe:

1. Erstelle ein Deployment no-api-app.
2. Setze automountServiceAccountToken: false.
3. Prüfe im Pod, ob ein Token automatisch gemountet wurde.
4. Erkläre, wann ein Workload Kubernetes-API-Zugriff braucht und wann nicht.

7. Teil C: Workload-, Netzwerk- und Supply-Chain-Hardening

Aufgabe C1: Pod Security Restricted

1. Setze im Lab-Namespace Pod-Security-Labels für restricted in enforce, audit und warn.
2. Versuche einen unsicheren Pod mit privileged: true zu erstellen.
3. Dokumentiere die Ablehnung.
4. Erstelle einen gehärteten Pod oder ein gehärtetes Deployment, das Restricted-Anforderungen erfüllt.

Erwartete Härtungskriterien:

• runAsNonRoot: true,
• definierter nicht-root User,
• allowPrivilegeEscalation: false,
• readOnlyRootFilesystem: true,
• capabilities.drop: [ALL],
• seccompProfile: RuntimeDefault,
• keine Host-Namespace-Nutzung,
• kein unkontrollierter hostPath,
• Schreibpfad nur über emptyDir oder dediziertes Volume.

Aufgabe C2: Hardened Deployment

Erstelle hardened-deployment.yml für eine ungefährliche Beispielanwendung.

Das Manifest muss enthalten:

• Namespace exam-security,
• ServiceAccount ohne unnötigen API-Token,
• Pod- und Container-SecurityContext,
• Ressourcen-Requests und Limits,
• Readiness Probe, falls fachlich passend,
• eindeutige Labels owner, environment, app,
• keine echten Secrets.

Aufgabe C3: NetworkPolicy

Erstelle networkpolicies.yml mit:

1. Default Deny für Ingress und Egress,
2. DNS-Egress-Erlaubnis,
3. Erlaubnis von frontend zu backend auf TCP-Port 8080,
4. Blockade sonstigen Egress,
5. Hinweis, ob das CNI NetworkPolicies durchsetzt.

Dokumentiere produktive Zusatzfragen:

• Muss der Pod die Kubernetes API erreichen?
• Muss der Pod Registry-, Logging-, Monitoring- oder externe API-Ziele erreichen?
• Gibt es feste externe Ziele oder nur freie Internet-Egress-Regeln?
• Wie wird IPv6 oder Dual-Stack berücksichtigt?

Aufgabe C4: Supply-Chain-Review

Erstelle supply-chain-review.md für ein Beispielimage.

Pflichtfelder:

• Registry,
• Repository,
• Tag,
• Digest,
• Pull Policy,
• ImagePullSecret,
• CVE-Scan-Ergebnis oder erwarteter Scan-Prozess,
• SBOM-Status,
• Signaturstatus,
• Build-Provenance,
• Admission-Anforderung,
• Stop-Kriterium.

Mindestens diese Stop-Kriterien müssen bewertet werden:

• latest ohne Digest in Produktion,
• Image aus nicht erlaubter Registry,
• Critical CVE ohne Ausnahme,
• fehlende Signatur bei produktiven Workloads,
• Pull Secret ohne Owner oder Rotation.

Aufgabe C5: Admission Policy

Erstelle admission-policy.md.

Wähle mindestens zwei Policy-Ziele:

1. Required Labels owner, environment, cost-center,
2. Verbot von privileged: true,
3. Pflicht für runAsNonRoot: true,
4. Pflicht für Resource Requests und Limits,
5. nur erlaubte Registries.

Beschreibe für jede Policy:

• Ziel,
• Scope,
• Audit-/Warn-/Enforce-Modus,
• Beispielverstoß,
• Ausnahmeprozess,
• Rollback-Pfad bei Policy-Fehler.

Du kannst Kyverno, OPA Gatekeeper oder ValidatingAdmissionPolicy verwenden. Wenn keines dieser Werkzeuge verfügbar ist, beschreibe die Policy fachlich mit Pseudomanifest und Betriebsmodus.

8. Teil D: Secrets, Detection, Compliance und Incident Response

Aufgabe D1: Secrets Security und Rotation

Erstelle secrets-review.md mit:

1. Secret-Inventar,
2. Zugriff über RBAC,
3. Mount-Art im Pod,
4. Risiko in Logs, Events, Images und Backups,
5. etcd-/Backup-Risiko,
6. Rotation-Pfad,
7. Vergleich Kubernetes Secret, External Secrets, CSI Secret Store, Sealed Secrets und SOPS,
8. Incident-Maßnahme bei Leak.

Wichtig: Verwende keine echten Secrets. Beispielwerte müssen eindeutig als Beispielwerte erkennbar sein.

Aufgabe D2: Runtime Detection und Audit-Signale

Erstelle runtime-detection.md.

Definiere erwartete Signale und Reaktionen für:

Aufgabe D3: Compliance Evidence

Erstelle compliance-evidence.md mit mindestens fünf Befunden:

1. Namespace ohne Pod-Security-Label,
2. ServiceAccount mit zu breiten Rechten,
3. Pod ohne Requests/Limits,
4. Secret ohne Rotation-Hinweis,
5. Workload ohne NetworkPolicy.

Für jeden Befund dokumentierst du:

• Zeitpunkt,
• Ressource,
• Risiko,
• Nachweis,
• Owner,
• Fix,
• Ausnahme mit Ablaufdatum oder Remediation-Frist,
• Nachtest.

Aufgabe D4: Incident-Runbook

Erstelle incident-runbook.md für kompromittierten Pod und Secret Leak.

Pflichtabschnitte:

1. Triage,
2. Isolation,
3. Evidence-Sicherung,
4. Containment,
5. Secret- und Token-Rotation,
6. Image- und CI-Prüfung,
7. Rebuild und Redeploy,
8. Kommunikation,
9. Lessons Learned,
10. Policy-Nachschärfung.

Pflicht-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

Dokumentiere außerdem, wann ein Pod nicht sofort gelöscht werden sollte, weil Evidence gesichert werden muss.

9. Bewertung

Bewertungsskala:

10. K.-o.-Kriterien

Die Prüfung gilt unabhängig von der Punktzahl als nicht bestanden, wenn eines dieser Kriterien zutrifft:

• Es werden echte Secrets, Tokens, privaten Schlüssel oder produktive Zugangsdaten verwendet.
• Es werden produktive Cluster oder Namespaces verändert.
• Ein privileged Workload oder hostPath-Zugriff wird als unkritisch dargestellt.
• Ein ServiceAccount mit Secret-Lesezugriff oder RoleBinding-Erstellung wird nicht als Risiko erkannt.
• Incident Response löscht Evidence vorschnell und enthält keine Sicherungsstrategie.
• NetworkPolicy wird als Verschlüsselung dargestellt.
• Supply-Chain-Review ignoriert Registry, Digest, CVE-Scan, SBOM und Signatur vollständig.
• Admission Policies werden ohne Audit-/Enforce-Strategie und ohne Ausnahmeprozess beschrieben.

11. Prüfer-Checkliste