... | ... | @@ -13,7 +13,6 @@ Der Softwarelieferant SOLL... |
|
|
|
|
|
**Umsetzungshinweise**
|
|
|
|
|
|
- plattformspezifische Isolationsmechanismen wie z.B. Namespaces, Pod Security Admission und Network Policies
|
|
|
|
|
|
Der Plattformbetreiber MUSS ...
|
|
|
|
... | ... | @@ -21,6 +20,6 @@ Der Plattformbetreiber MUSS ... |
|
|
|
|
|
[^1]: der Plattformbetreiber MUSS technische Maßnahmen anbieten, die eine Isolation und Kapselung containerisierter IT-Systeme sowie die Trennung dieser IT-Systeme in unterschiedliche virtuelle Netze ermöglichen. Dabei muss die Netzwerkarchitektur (physische, virtuelle und Overlay-Netze) so gestaltet werden, dass die Anforderungen an einen sicheren Netzwerkbetrieb lt. BSI-Grundschutz NET.1 und NET.3 erfüllt sind.
|
|
|
|
|
|
[^2]: durch Plattform vorgegebene Isolationsmechanismen wie z.B. SE Linux und CGroups.
|
|
|
[^2]: durch Plattform vorgegebene Isolationsmechanismen wie z.B. SE Linux und CGroups; plattformspezifische Isolationsmechanismen wie z.B. Namespaces, Pod Security Admission und Network Policies
|
|
|
|
|
|
[^3]: Bei einem Recovery ist der exakt gleiche Zustand des Clusters (gleiche Anzahl an Pods) nicht erreichbar. Folgende Mechanismen sollten beachtet werden: Festspeicher (Persistent Volumes); Konfigurationsdateien von Kubernetes und den weiteren Programmen der Control Plane; plattformspezifische Erweiterungen wie z.B. Monitoring, Logging, Ingress etc.; Datenbanken der Konfiguration, namentlich hier etcd; alle Infrastrukturanwendungen die zum Betrieb des Clusters und der darin befindlichen Dienste notwendig sind; die Datenhaltung der Code und Image Registries |