Kubernetes: Grenzen tatsächlich durchsetzen
Grenzen zwischen Workloads und Verwaltungszugängen überprüfen.
Der Prüfauftrag
Prüfhilfe für autorisierte Cluster-Verantwortliche. Vor Änderungen Abhängigkeiten, Kubernetes-Version, Betriebssystem und CNI-Verhalten erfassen; zunächst in einer geeigneten Testumgebung prüfen.
Am Ende hast du:Eine dokumentierte Erstprüfung mit nachvollziehbaren Nachweisen und einer Liste offener Maßnahmen.
Beweisen statt vermuten.
In einem Test-Namespace die freigegebene Verbindungsmatrix prüfen: benötigte Verbindungen funktionieren, eine ausdrücklich gesperrte Verbindung scheitert.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Cluster, Namespaces, Workloads und Verantwortliche inventarisieren; öffentlich erreichbare Verwaltungszugänge prüfen und auf erforderliche Zugriffswege begrenzen.
So belegst du es: Inventar, Netzfreigaben und dokumentierte Erreichbarkeitsprüfung von API, kubelet und etcd.
Nachweis und nächsten Schritt notieren
RBAC nach Aufgaben beschränken; cluster-admin, Wildcards und Rechte für Rollenänderungen, Secrets oder Workload-Erstellung gezielt überprüfen.
So belegst du es: Role-/Binding-Export und positive sowie negative Berechtigungstests für repräsentative Identitäten.
Nachweis und nächsten Schritt notieren
Eigene ServiceAccounts je Anwendung verwenden; automatisch eingebundene API-Tokens deaktivieren, wenn der Workload sie nicht benötigt.
So belegst du es: ServiceAccount-Zuordnung und geprüfte Pod-Spezifikationen ohne unnötige Token-Mounts.
Nachweis und nächsten Schritt notieren
Nachweisen, dass das eingesetzte CNI die verwendeten NetworkPolicies tatsächlich durchsetzt; vorhandene Policies vollständig erfassen.
So belegst du es: CNI-Dokumentation und reproduzierbare Verbindungsversuche statt lediglich vorhandener YAML-Dateien.
Nachweis und nächsten Schritt notieren
Ingress und Egress schrittweise auf benötigte Verbindungen begrenzen; erforderliches DNS und Betriebsverkehr ausdrücklich berücksichtigen.
So belegst du es: Verbindungsmatrix mit erlaubten und gesperrten Pfaden einschließlich benötigter TCP-/UDP-Verbindungen.
Nachweis und nächsten Schritt notieren
Überlappende Freigaben prüfen: NetworkPolicies sind additiv. Eine breit erlaubende Policy wird durch eine zusätzliche Default-Deny-Policy nicht aufgehoben.
So belegst du es: Gesamtauswertung der auf einen Pod wirkenden Regeln und negative Gegenproben.
Nachweis und nächsten Schritt notieren
Passende Pod-Security-Standards zunächst mit Warn-/Audit-Auswertung prüfen und kontrolliert durchsetzen; Ausnahmen begründen und terminieren.
So belegst du es: Namespace-Konfiguration, Admission-Ergebnisse, Ausnahmeliste und Nachweis abgewiesener Test-Pods.
Nachweis und nächsten Schritt notieren
Linux-Workloads soweit kompatibel ohne root, ohne Privilege Escalation und mit geeignetem Seccomp-Profil betreiben; zusätzliche Capabilities minimieren.
So belegst du es: SecurityContext, Laufzeitprüfung und begründete Abweichungen für unvermeidbare Sonderfälle.
Nachweis und nächsten Schritt notieren
Nicht benötigte Hostzugriffe und Cloud-Metadatenzugriffe unterbinden; Administrator-Aktionen und relevante Konfigurationsänderungen nachvollziehbar protokollieren.
So belegst du es: Pod-/Netzprüfungen und auffindbare Audit-Ereignisse mit geschütztem Zugriff.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
NetworkPolicies ersetzen keine Anwendungsautorisierung und verschlüsseln Verkehr nicht automatisch. Wirkung und Sonderfälle hängen vom CNI und Netzpfad ab. Pod-Security-Anforderungen unterscheiden sich teilweise nach Betriebssystem und Version. Nicht ungeprüft Default-Deny in Produktion aktivieren; die Checkliste bescheinigt keine vollständige Cluster-Sicherheit.
Kubernetes: Security Checklist ↗Kubernetes: RBAC Good Practices ↗Kubernetes: Network Policies ↗Kubernetes: Pod Security Standards ↗Prüfbericht / Selbsteinschätzung
Kubernetes: Grenzen tatsächlich durchsetzen · v2026.11 · 10.11.2026 ·
0/9 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Cluster, Namespaces, Workloads und Verantwortliche inventarisieren; öffentlich erreichbare Verwaltungszugänge prüfen und auf erforderliche Zugriffswege begrenzen.
Status: Offen
Erwarteter Nachweis: Inventar, Netzfreigaben und dokumentierte Erreichbarkeitsprüfung von API, kubelet und etcd.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. RBAC nach Aufgaben beschränken; cluster-admin, Wildcards und Rechte für Rollenänderungen, Secrets oder Workload-Erstellung gezielt überprüfen.
Status: Offen
Erwarteter Nachweis: Role-/Binding-Export und positive sowie negative Berechtigungstests für repräsentative Identitäten.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Eigene ServiceAccounts je Anwendung verwenden; automatisch eingebundene API-Tokens deaktivieren, wenn der Workload sie nicht benötigt.
Status: Offen
Erwarteter Nachweis: ServiceAccount-Zuordnung und geprüfte Pod-Spezifikationen ohne unnötige Token-Mounts.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Nachweisen, dass das eingesetzte CNI die verwendeten NetworkPolicies tatsächlich durchsetzt; vorhandene Policies vollständig erfassen.
Status: Offen
Erwarteter Nachweis: CNI-Dokumentation und reproduzierbare Verbindungsversuche statt lediglich vorhandener YAML-Dateien.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Ingress und Egress schrittweise auf benötigte Verbindungen begrenzen; erforderliches DNS und Betriebsverkehr ausdrücklich berücksichtigen.
Status: Offen
Erwarteter Nachweis: Verbindungsmatrix mit erlaubten und gesperrten Pfaden einschließlich benötigter TCP-/UDP-Verbindungen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Überlappende Freigaben prüfen: NetworkPolicies sind additiv. Eine breit erlaubende Policy wird durch eine zusätzliche Default-Deny-Policy nicht aufgehoben.
Status: Offen
Erwarteter Nachweis: Gesamtauswertung der auf einen Pod wirkenden Regeln und negative Gegenproben.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Passende Pod-Security-Standards zunächst mit Warn-/Audit-Auswertung prüfen und kontrolliert durchsetzen; Ausnahmen begründen und terminieren.
Status: Offen
Erwarteter Nachweis: Namespace-Konfiguration, Admission-Ergebnisse, Ausnahmeliste und Nachweis abgewiesener Test-Pods.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Linux-Workloads soweit kompatibel ohne root, ohne Privilege Escalation und mit geeignetem Seccomp-Profil betreiben; zusätzliche Capabilities minimieren.
Status: Offen
Erwarteter Nachweis: SecurityContext, Laufzeitprüfung und begründete Abweichungen für unvermeidbare Sonderfälle.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
9. Nicht benötigte Hostzugriffe und Cloud-Metadatenzugriffe unterbinden; Administrator-Aktionen und relevante Konfigurationsänderungen nachvollziehbar protokollieren.
Status: Offen
Erwarteter Nachweis: Pod-/Netzprüfungen und auffindbare Audit-Ereignisse mit geschütztem Zugriff.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
NetworkPolicies ersetzen keine Anwendungsautorisierung und verschlüsseln Verkehr nicht automatisch. Wirkung und Sonderfälle hängen vom CNI und Netzpfad ab. Pod-Security-Anforderungen unterscheiden sich teilweise nach Betriebssystem und Version. Nicht ungeprüft Default-Deny in Produktion aktivieren; die Checkliste bescheinigt keine vollständige Cluster-Sicherheit.