KCSA-Prüfungsvorbereitung

Cloud, Cluster, Container und Code bilden vier miteinander verbundene Sicherheitsgrenzen. Sie ordnen Verantwortlichkeiten von Cloud-Anbieter, Plattformteam und Anwendungsteam ein und vergleichen dazu IAM, Netzwerksegmentierung, Images und Workload-Konfiguration nach ihren Schutzaufgaben. An einer vorbereiteten Architektur markieren Sie Annahmen, vorhandene Kontrollen und offene Prüfungen in allen vier Schichten.

Ein Scanbefund ist noch keine Freigabe für ein Container-Image. Sie scannen vorbereitete Images mit Trivy, ordnen CVE-Befunde nach Kontext und vergleichen erlaubte Base Images. Anschließend prüfen Sie mit Cosign eine Signatur und grenzen Registry-Kontrollen, Signaturvertrauen und verbleibende Laufzeitrisiken im Lab anhand ihrer jeweiligen Schutzgrenzen voneinander ab.

API-Server, etcd, Controller Manager und Scheduler bilden zentrale Vertrauensgrenzen der Control Plane. Sie untersuchen Authentifizierung, Autorisierung, TLS und Encryption at Rest und ordnen Schlüsselverwaltung sowie administrative Zugriffsrechte fachlich ein. Eine vorbereitete Konfiguration zeigt gemeinsam für die Laborumgebung nachvollziehbar, warum einzelne Flags nie das gesamte Sicherheitsmodell ersetzen.

Auf Worker Nodes treffen Kubelet, Container Runtime und Netzwerkpfad aufeinander. Sie prüfen Kubelet-Authentifizierung und -Autorisierung, ausgewählte containerd-Einstellungen und die Rolle von kube-proxy im Servicepfad. An einer vorbereiteten Node-Konfiguration ordnen Sie Befunde im Team einer konkreten Schutzmaßnahme oder einer offenen Betriebsentscheidung zum Schutz der Node zu.

Container Networking, Storage und Client Security schützen unterschiedliche Zugriffswege: den Datenpfad zwischen Pods, persistente Daten und den administrativen Clusterzugang. In einem vorbereiteten Szenario verfolgen Sie eine Pod-Verbindung, prüfen StorageClass und Claim auf Provisionierungs- und Zugriffsgrenzen und verwenden einen kubeconfig-Kontext, dessen Identität per RBAC auf notwendige Rechte begrenzt ist. Die Auswertung zeigt, welcher Schutzmechanismus an welcher Grenze wirkt.

Kubernetes definiert mit den Pod Security Standards drei Profile: Privileged, Baseline und Restricted. Sie konfigurieren Pod Security Admission im Cluster und testen, wie die Modi enforce, audit und warn auf nicht konforme Pods reagieren. Im Lab vergleichen Sie die Profile an vorbereiteten Workloads und planen eine schrittweise Einführung.

Wer darf was im Cluster? Sie vergleichen X.509-Zertifikate, Bearer Tokens und OIDC als Authentifizierungswege und erstellen anschließend RBAC-Rollen sowie RoleBindings. An einer überbreiten ClusterRole und der Gruppe system:masters untersuchen Sie im vorbereiteten Laborcluster gemeinsam, wie Identität, Geltungsbereich und die konkrete Bindung zu unnötigen Rechten führen.

Kubernetes Secrets sind API-Objekte; Base64-Kodierung schützt ihren Inhalt nicht, Encryption at Rest dagegen den in etcd gespeicherten Rohwert. In einer vorbereiteten Control Plane konfigurieren Sie Encryption at Rest und untersuchen das Zusammenspiel mit Namespace-Isolation und Audit Logging. Dabei beobachten Sie, wie Speicherschutz, RBAC-Bindungen und Audit-Policy unterschiedliche Grenzen abdecken.

Ohne eine sie auswählende NetworkPolicy sind Pods für die jeweilige Richtung standardmäßig nicht isoliert; die Durchsetzung setzt ein unterstützendes Netzwerk-Plugin voraus. Für vorbereitete Workloads entwickeln Sie eine Default-Deny-Strategie und öffnen gezielt Ingress- und Egress-Pfade. In einem Microservice-Szenario beobachten Sie, wie Policy-Auswahl, Netzwerk-Plugin und Verbindungstests zusammenspielen.

Wo liegen die Trust Boundaries in einem Kubernetes-Cluster, und wie kann sich ein Angreifer nach einem initialen Zugriff weiterbewegen? Sie analysieren vorbereitete Bedrohungsszenarien zu Privilege Escalation über überprivilegierte Service Accounts, Malicious Code Execution durch manipulierte Container-Images und Lateral Movement im Cluster-Netzwerk. Anschließend ordnen Sie Persistence als eigene Angriffsstufe getrennt ein und beziehen RBAC, NetworkPolicy und Pod Security auf die jeweiligen Angriffsvektoren.

Falco verarbeitet Laufzeitereignisse aus konfigurierten Event Sources und wertet sie gegen Regeln aus. Das DevNinjas Dojo, unsere Cloud-Lernumgebung, stellt den Lerncluster bereit, in dem Sie Falco mit Helm installieren und die Verarbeitung eines Ereignisses anhand einer vorhandenen Regel bis zum Alert untersuchen. Die Übung trennt Installation, Event Source, Regel-Matching und Ausgabe voneinander, ohne vollständigen Falco-Betrieb vorwegzunehmen.

Admission Control kann passende API-Anfragen vor der Persistierung ablehnen oder verändern. Sie installieren OPA Gatekeeper mit Helm, erstellen ein ConstraintTemplate und ein Constraint und prüfen deren Wirkung an vorbereiteten Workloads. Anschließend ordnen Sie Rego und den Durchsetzungspunkt ein und vergleichen das Modell mit Kyvernos YAML-basiertem Policy-Ansatz, ohne beide Implementierungen gleichzusetzen.

Schutzmaßnahmen in der Softwarelieferkette beantworten andere Fragen als Transportverschlüsselung im Cluster. Sie lesen eine vorbereitete SBOM, prüfen mit Cosign die Signatur eines Images und ordnen Inhalt, Signatur und Vertrauensanker dem Lieferweg zu. Anschließend grenzen Sie PKI, TLS/mTLS und Service Mesh als Schutz des Kommunikationswegs ab, ohne beide Sicherheitsbereiche gleichzusetzen.

Ein technischer Check beweist noch keine vollständige Compliance. Sie ordnen ausgewählte Anforderungen aus NIST, PCI DSS und Datenschutzkontexten konkreten Kubernetes-Kontrollen zu und dokumentieren offene organisatorische Nachweise. Mit kube-bench vergleichen Sie die Laborumgebung mit CIS-Empfehlungen und grenzen diesen Befund von STRIDE und OCTAVE als Threat-Modelling-Ansätzen ab.

Die KCSA ist eine online beaufsichtigte Multiple-Choice-Prüfung mit 90 Minuten Bearbeitungszeit. Sie gewichten die sechs Domänen, markieren persönliche Unsicherheiten und lösen Beispielfragen aus allen Bereichen. Danach ordnen Sie offene Themen und Zeitmanagement dem eigenen weiteren Lernpfad zu; die Übung ersetzt weder eigenständige Wiederholung noch eine Aussage über individuelle Prüfungsreife.