Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der KCSA-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Architektur einer ganzheitlichen Cloud-nativen Sicherheitsstrategie.
Implementieren Sie Sicherheitskontrollen über die 4Cs hinweg: Cloud (Grundlage), Cluster, Container und Code.
Warum: Ein Kompromiss in einer äußeren Schicht (z. B. Cloud) untergräbt die Sicherheit aller inneren Schichten. Sicherheit ist nur so stark wie ihr schwächstes Glied.
Schutz vor Single-Point-Sicherheitsausfällen.
Implementieren Sie mehrere, sich überschneidende Sicherheitskontrollen auf verschiedenen Ebenen (z. B. NetworkPolicies, RBAC, Security Contexts).
Warum: Wenn eine Kontrolle fehlschlägt oder umgangen wird, bieten andere Ebenen weiterhin Schutz, was die Schwierigkeit für Angreifer erhöht.
Sicherung des Netzwerkverkehrs in einer Umgebung, in der der Netzwerkstandort keine vertrauenswürdige Grenze darstellt.
Implementieren Sie ein "niemals vertrauen, immer überprüfen"-Modell. Authentifizieren und autorisieren Sie jede Anfrage, typischerweise unter Verwendung eines Service Meshs für mTLS.
Warum: Geht davon aus, dass Bedrohungen sowohl innerhalb als auch außerhalb des Netzwerks existieren können, wodurch implizites Vertrauen basierend auf der Netzwerkposition eliminiert wird.
Begrenzung des Ausmaßes eines kompromittierten Identität oder Komponente.
Gewähren Sie allen Subjekten (Benutzern, Service Accounts, Nodes) nur die minimalen Berechtigungen, die zur Ausführung ihrer Funktion erforderlich sind.
Warum: Reduziert den potenziellen Schaden, den ein Angreifer mit gestohlenen Anmeldeinformationen verursachen kann.
Reduzierung der Kosten und Auswirkungen von Sicherheitslücken.
Integrieren Sie automatisierte Sicherheitsscans (SAST, SCA, Image Scanning) und Policy-Prüfungen in die frühen Phasen der CI/CD-Pipeline.
Warum: Findet und behebt Schwachstellen früher im Entwicklungslebenszyklus, wenn deren Behebung am kostengünstigsten ist.
Schutz sensibler Clusterdaten (insbesondere Secrets), falls der etcd-Speicher kompromittiert wird.
Verwenden Sie auf dem kube-apiserver `--encryption-provider-config`, um die Verschlüsselung ruhender Ressourcen zu aktivieren, bevor sie in etcd gespeichert werden.
Warum: Standardmäßig sind Kubernetes Secrets in etcd nur Base64-kodiert. Dies bietet eine echte Verschlüsselung auf der Festplatte.
Verhindern von unautorisiertem Zugriff und Abhören der etcd-Kommunikation.
Konfigurieren Sie etcd mit mTLS für die Client- (`--client-cert-auth`) und Peer- (`--peer-client-cert-auth`) Kommunikation.
Warum: Stellt sicher, dass nur authentifizierte Komponenten (apiserver, andere etcd-Mitglieder) mit etcd kommunizieren können und der Datenverkehr verschlüsselt ist.
Verhindern von unauthentifiziertem Zugriff auf den Kubernetes API server.
Setzen Sie das Flag `--anonymous-auth=false`. Verwenden Sie starke Authentifizierungsmethoden wie OIDC oder x509-Zertifikate.
Warum: Deaktiviert den `system:anonymous`-Benutzer und zwingt alle Anfragen, authentifiziert und gegen eine bestimmte Identität protokolliert zu werden.
Anforderung, alle Änderungen und Zugriffsversuche für Sicherheit und Compliance zu verfolgen.
Aktivieren Sie das API server Audit Logging mit `--audit-policy-file` und senden Sie die Logs an ein externes, unveränderliches Logging-System.
Warum: Bietet eine wesentliche, manipulationssichere Spur für Incident-Untersuchungen, Threat Hunting und Compliance-Audits.
Reduzierung der Angriffsfläche von Worker Nodes.
Setzen Sie die kubelet-Flags: `--anonymous-auth=false`, `--authorization-mode=Webhook` und `--read-only-port=0`.
Warum: Dies erzwingt, dass alle Anfragen an die kubelet-API vom API server authentifiziert und autorisiert werden und deaktiviert den unsicheren, unauthentifizierten Read-Only-Port.
Verhindern von Informationslecks aus Control Plane Komponenten.
Setzen Sie das Flag `--profiling=false` für kube-apiserver, kube-controller-manager und kube-scheduler in der Produktion.
Warum: Profiling-Endpunkte können interne Leistungsdaten und Systemdetails offenlegen, die einem Angreifer bei der Aufklärung helfen könnten.
Schutz der Control Plane Komponenten vor unautorisiertem Netzwerkzugriff.
Verwenden Sie Firewall-Regeln (Cloud Security Groups, iptables), um den Zugriff auf die API server (6443) und etcd (2379) Ports nur auf vertrauenswürdige Quellen zu beschränken.
Warum: Netzwerkbasierte Zugriffskontrolle ist eine grundlegende Verteidigungsebene, die Angreifer daran hindert, sensible Komponenten-APIs überhaupt zu erreichen.
Erteilen von Berechtigungen an Benutzer oder Anwendungen.
Verwenden Sie `Roles` mit Namespace gegenüber `ClusterRoles`. Erteilen Sie spezifische Verben (`get`, `list`) anstelle von Wildcards (`*`).
Warum: Folgt dem Prinzip der geringsten Berechtigung und beschränkt den Umfang der Berechtigungen auf das Notwendige innerhalb eines bestimmten Namespace.
Ein Pod muss nicht mit der Kubernetes API kommunizieren.
Setzen Sie `automountServiceAccountToken: false` im Pod-Spec oder im ServiceAccount selbst.
Warum: Verhindert die Offenlegung unnötiger Anmeldeinformationen im Pod und reduziert die Angriffsfläche, wenn der Pod kompromittiert wird.
Erzwingen einer grundlegenden Sicherheitslage für alle Pods in einem Namespace.
Verwenden Sie den integrierten `PodSecurity` Admission Controller, indem Sie Namespace-Labels wie `pod-security.kubernetes.io/enforce: baseline` anwenden.
Warum: Bietet eine standardisierte, integrierte Methode, um riskante Pod-Konfigurationen (wie privilegierte Container) ohne Tools von Drittanbietern zu verhindern.
Härten der individuellen Container-Sicherheit zur Verhinderung von Privilegieneskalation.
Setzen Sie im Pod-Spec die `securityContext`-Felder: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`.
Warum: Diese Kontrollen verhindern das Ausführen als Root, blockieren Mechanismen zur Erlangung neuer Privilegien und machen das Container-Dateisystem unveränderlich, was die Auswirkungen einer Kompromittierung drastisch reduziert.
Implementierung eines Zero-Trust-Netzwerkmodells innerhalb des Clusters.
Wenden Sie eine Default-Deny NetworkPolicy auf jeden Namespace an, die alle Pods (`podSelector: {}`) auswählt und eine leere Ingress-/Egress-Regelliste hat.
Warum: Kubernetes-Networking ist standardmäßig auf "erlauben" gesetzt. Diese Policy kehrt das Modell zu "standardmäßig verweigern" um und zwingt Entwickler, den erforderlichen Traffic explizit zu erlauben.
Zulassen des Datenverkehrs nur zwischen bestimmten Anwendungsschichten (z. B. Web-zu-API).
Erstellen Sie NetworkPolicies, die `podSelector` und `namespaceSelector` verwenden, um granulare Ingress- und Egress-Regeln basierend auf Labels zu definieren.
Warum: Verhindert laterale Bewegung durch Angreifer, indem sichergestellt wird, dass ein kompromittierter Pod nur mit explizit autorisierten Peers kommunizieren kann.
Ein Benutzer benötigt die Berechtigung, `kubectl exec` in Container zum Debugging auszuführen.
Erteilen Sie das `create`-Verb für die `pods/exec`-Unterressource in der relevanten Role oder ClusterRole.
Warum: Die `exec`-Aktion wird unintuitiv durch das `create`-Verb gesteuert, da sie eine neue Exec-Sitzung erstellt. Dies ist ein häufiger Punkt der Verwirrung.
Ein Angreifer erhält Zugriff auf einen Container und versucht, den Host Node zu kompromittieren.
Verbieten Sie privilegierte Container (`securityContext.privileged: false`), Host-Namespaces (`hostNetwork`, `hostPID`) und das Mounten des Docker-Sockets.
Warum: Diese Konfigurationen durchbrechen effektiv die Container-Isolation und geben einem kompromittierten Container Root-Zugriff auf den Host.
Verhindern der Bereitstellung von Container-Images mit bekannten Schwachstellen oder bösartigem Code.
Implementieren Sie Image Scanning (z. B. Trivy) und Image-Signaturprüfung (z. B. Cosign) in der CI/CD-Pipeline und über Admission Control.
Warum: Bietet einen Defense-in-Depth-Ansatz: Das Scannen erkennt bekannte Schwachstellen, während die Signierung die Integrität und Herkunft des Images überprüft.
Ein Angreifer hat einen Pod kompromittiert und versucht, auf andere Pods im Cluster zuzugreifen.
Implementieren Sie Default-Deny NetworkPolicies und erstellen Sie spezifische Allow-Regeln nur für die erforderliche Pod-zu-Pod-Kommunikation.
Warum: Beschränkt die "Sichtlinie" eines Angreifers von einem kompromittierten Pod, indem die Sicherheitsverletzung eingedämmt und deren Ausbreitung verhindert wird.
Verhindern, dass ein kompromittierter Pod Cloud IAM-Anmeldeinformationen vom Instance-Metadaten-Service stiehlt.
Wenden Sie eine Default-Deny Egress NetworkPolicy an, die den Datenverkehr zur Metadaten-IP (z. B. `169.254.169.254/32`) explizit blockiert.
Warum: Dies ist ein häufiger Angriffspfad in Cloud-Umgebungen. Das Blockieren dieses Egress-Pfades mindert das Risiko des Diebstahls von IAM-Anmeldeinformationen aus Pods.
Schutz vor Denial-of-Service- oder Cryptojacking-Angriffen, die Node-Ressourcen erschöpfen.
Wenden Sie `ResourceQuota`-Objekte auf Namespaces an, um die gesamte Ressourcennutzung zu begrenzen, und `LimitRange`-Objekte, um Grenzwerte für einzelne Pods durchzusetzen.
Warum: Stellt sicher, dass kein einzelner Tenant oder Workload andere Ressourcen entziehen kann, was Stabilität gewährleistet und Missbrauch verhindert.
Ein Angreifer versucht, langfristigen Zugriff auf einen kompromittierten Cluster aufrechtzuerhalten.
Überwachen Sie die Erstellung unerwarteter `DaemonSets`, `CronJobs` oder privilegierter Pods. Beschränken Sie die Berechtigungen zur Erstellung dieser Ressourcen.
Warum: Angreifer verwenden diese Workload-Typen, um sicherzustellen, dass ihr bösartiger Code persistent ausgeführt wird, selbst wenn ein Node oder Pod neu gestartet wird.
Sicherstellen, dass Container-Images vor der Bereitstellung frei von bekannten Schwachstellen sind.
Integrieren Sie einen Image Scanner wie Trivy, Clair oder Grype in die CI/CD-Pipeline, um Images zu scannen und den Build fehlschlagen zu lassen, wenn kritische Schwachstellen gefunden werden.
Warum: Automatisiert die Schwachstellen-Erkennung frühzeitig ("Shift Left") und verhindert, dass anfälliger Code in die Produktion gelangt.
Sicherstellen, dass nur vertrauenswürdige, unveränderte Container-Images im Cluster bereitgestellt werden.
Signieren Sie Images mit einem Tool wie Cosign in der CI-Pipeline. Verwenden Sie einen Validating Admission Controller (z. B. Kyverno, Gatekeeper), um die Signatur zum Zeitpunkt der Bereitstellung zu überprüfen.
Warum: Bietet kryptographischen Nachweis der Image-Integrität (es wurde nicht manipuliert) und der Herkunft (es stammt aus einer vertrauenswürdigen Quelle).
Erkennung bösartiger Aktivitäten innerhalb eines laufenden Containers (z. B. Shell gestartet, Zugriff auf sensible Dateien).
Stellen Sie ein Laufzeit-Sicherheitstool wie Falco bereit, das eBPF verwendet, um Syscalls zu überwachen und bei verdächtigem Verhalten basierend auf einem definierten Regelsatz zu alarmieren.
Warum: Bietet Einblick in Laufzeitaktivitäten, die statisches Scannen und Admission Control nicht erfassen können. Es ist entscheidend für die Erkennung aktiver Sicherheitsverletzungen.
Durchsetzen von benutzerdefinierten, organisationsspezifischen Sicherheitsrichtlinien (z. B. "alle Images müssen aus unserem Unternehmens-Registry stammen").
Verwenden Sie eine Policy Engine wie OPA Gatekeeper oder Kyverno als Validating Admission Controller, um in Rego oder YAML geschriebene Policies durchzusetzen.
Warum: Ermöglicht eine flexible, deklarative und automatisierte Durchsetzung von Sicherheitsrichtlinien, die über die integrierten Kontrollen von Kubernetes hinausgehen.
Verschlüsselung und Authentifizierung des gesamten Service-to-Service-Verkehrs innerhalb des Clusters.
Implementieren Sie ein Service Mesh (z. B. Istio, Linkerd), um automatisch Mutual TLS (mTLS) für alle gemeshten Services bereitzustellen.
Warum: Erreicht Zero-Trust-Networking, indem sichergestellt wird, dass der gesamte In-Cluster-Datenverkehr verschlüsselt ist und Services die Identität des jeweils anderen gegenseitig überprüfen.
Ausführen von nicht vertrauenswürdigen oder Multi-Tenant-Workloads, die eine stärkere Isolation als Standard-Container erfordern.
Verwenden Sie eine Sandboxed Container Runtime wie gVisor oder Kata Containers, die eine zusätzliche Isolationsschicht zwischen dem Container und dem Host-Kernel bereitstellen.
Warum: Reduziert die Angriffsfläche des Host-Kernels und erschwert die Container-Flucht erheblich.
Feingranulare Kontrolle über die Berechtigungen eines Containers auf Kernel-Ebene.
Verwenden Sie Seccomp-Profile, um erlaubte Syscalls zu filtern, und AppArmor/SELinux-Profile, um Mandatory Access Controls (MAC) für den Datei- und Netzwerkzugriff durchzusetzen.
Warum: Diese Linux-nativen Sicherheitsfunktionen bieten eine tiefe Verteidigungsebene, die einschränkt, was ein kompromittierter Container-Prozess grundsätzlich tun kann.
Reduzierung der Angriffsfläche innerhalb eines Container-Images.
Erstellen Sie Anwendungs-Images unter Verwendung minimaler oder "distroless" Basis-Images, die nur die Anwendung und deren direkte Abhängigkeiten enthalten.
Warum: Entfernt Shells, Paketmanager und andere Dienstprogramme, die für die Produktion unnötig sind und von einem Angreifer nach einer Kompromittierung genutzt werden könnten.
Überprüfen, ob ein Kubernetes-Cluster gemäß bewährten Sicherheitspraktiken konfiguriert ist.
Führen Sie regelmäßig `kube-bench` aus, ein automatisiertes Tool, das den Cluster anhand des CIS Kubernetes Benchmark überprüft.
Warum: Bietet eine standardisierte, umfassende und automatisierte Methode zur Überprüfung der Cluster-Sicherheitsposition und zur Identifizierung von Fehlkonfigurationen.
Ein Cluster muss Kreditkartendaten gemäß PCI DSS verarbeiten und speichern.
Verwenden Sie NetworkPolicies zur Netzwerksegmentierung, um die Cardholder Data Environment (CDE) zu isolieren, und aktivieren Sie die Verschlüsselung ruhender Daten für etcd.
Warum: Diese Kontrollen entsprechen direkt den PCI DSS-Anforderungen für Netzwerksegmentierung (Anforderung 1) und Schutz gespeicherter Kartendaten (Anforderung 3).
Ein Cluster verarbeitet Protected Health Information (PHI) und muss HIPAA-konform sein.
Implementieren Sie striktes RBAC, aktivieren Sie umfassendes Audit Logging und stellen Sie sicher, dass Daten sowohl ruhend als auch während der Übertragung verschlüsselt sind.
Warum: Diese Kontrollen adressieren die technischen Schutzmaßnahmen von HIPAA für Zugriffskontrolle, Audit-Kontrollen und Übertragungssicherheit.
Sicherstellen, dass Audit-Logs für Compliance und Forensik erhalten bleiben, selbst wenn der Cluster kompromittiert wird.
Konfigurieren Sie den API server so, dass Audit-Logs an ein externes, einmal beschreibbares/unveränderliches Logging-Backend gestreamt werden (z. B. ein SIEM oder ein gesperrter Cloud-Speicher-Bucket).
Warum: Verhindert, dass ein Angreifer mit Cluster-Admin-Berechtigungen seine Spuren verwischt, indem er lokale Audit-Logs ändert oder löscht.