7. Phase D: Technologiearchitektur

Als Referenzarchitektur(en) wird eine Auswahl von weit verbreiteten Kubernetes Distributionen festgelegt. Die Implementierung auf anderen von der CNCF zertifizierten Kubernetes Distributionen1 muss auch einfach möglich sein.

Betriebsumgebungen müssen vollständig automatisch erstellt werden können. Im Sinne von DVS Rahmenplan 2.0.1 werden als Applikationen Kubernetes Pods durch Helm Charts ausgerollt. Die Helm Charts sind als Teil der Applikation anzusehen und müssen auch durch die CI/CD Pipeline transportiert werden und auch auditiert werden.

Kubernetes Cluster MÜSSEN automatisch erstellt werden können. Z.B. mit Terraform oder durch andere Skripte. Die VMS oder Hardwarekonfigurationen müssen vollautomatisch aus eine Repository ausgerollt werden. Es DARF in Produktion KEINE Zugänge zu Kubernetes Hosts geben. Kein Login, kein Ssh oder ähnliches.

Alle Dienste, für die ausreichend Compute, Storage und Netzwerk Resource zur Verfügung stehen MÜSSEN initiert werden können.

Es gibt keine Backups von Hosts. Der Umgang mit Logging wird in D+S beschrieben. Hosts MÜSSEN automatisch hinzugefügt werden können.

7.1 Schnittstellen

Schnittstellen zur Erzeugung Kubernetes Hosts MÜSSEN vollautomatisch betreibbar sein, z.B. durch Terraform. Schnittstellen zu Kubernetes verwenden den API Server.

Es muss Container Storage Interface2 (CSI) Schnittstellen zu mindestens einem Storage System geben um eine Standard Storage Klasse festzulegen.

Einer oder mehrere Ingress Controller3 erlauben einen netzwerkseitigen Zugang. Der Ingress Controller implementiert einen Service, der auf Dienste innerhalb des Clusters verweist.

Es werden bis auf weitere Anforderungen ausschließlich Linux AMD64 Container verwendet.

7.2 DevOps Phasen

Die DevOps Phasen beschreiben den Weg einer Applikation von Source Code bis zum Betrieb. Wir orientieren uns an diesen Phasen, auch wenn wir kein DevOps im eigentlichen Sinne4 machen. Die Phasen 3-8 sind weitestgehend automatisch durchzühren. Ausnahmen sind nicht automatisierbare Tests (User Interfaces, Barrierefreiheit) und ein manueller Trigger des Deployments Phase 6.

Tabelle: DevOps Phasen

7.2.1 Digitale Souveränität

Oberstes Ziel bei der Technologiearchitektur ist es, souveräne Entscheidungen für den Aufbau und Betrieb zu treffen. Es muss möglich sein, auch komplexe Technologien stabil und schnell unabhängig vom Betreiber zu implementieren. Dabei werden etablierte Standard Technologien eingesetzt. Eine sicherer Betrieb MUSS einfach möglich sein. Die Grundeinstellungen MÜSSEN bereits eine einfache Basis Sicherheit erlauben, Security by Default5 MUSS einfach erreicht werden können.6

Es sollen Microservice basierte Technologien verwendet werden, für die es Open Source Komponenten mit einer von Open CoDE akzeptierten OSS-Lizenz gibt. Dabei sind permissive Lizenzen zu bevorzugen. Der Einsatz von Lizenzen mit Zusatzanforderung „copyleft“ ist auf den benötigten Sicherheitsbedarf (z.B. durch Notwendigkeit der Geheimhaltung des Codes) abzustimmen.

Bevorzugt werden Projekte der Cloud Native Computing Foundation7. Es sollen die Projekte mit höheren Reifegraden bevorzugt werden, in der Reihenfolge Graduated, Incubating vor Sandbox. Sobald Projekte abgekündigt werden („archived“) MUSS nach einer alternativen Implementierung gesucht werden.

Dabei ist unerlässlich, eine hohe Geschwindigkeit und eine hohe Zuverlässigkeit gleichzeitig zu implementieren. Dieses Vorgehen verlangt eine vollständige Automatisierung, in der nur Entscheidungen über Releases manuell getroffen werden. In keiner Phase werden manuelle Konfigurationen vorgenommen.

In Anbetracht der großen Zahl von Komponenten und der daraus resultierenden möglichen Kombinationen ist ein Automatisierung unerlässlich, sowohl im Hinblick auf die Geschwindigkeit des Rollout Prozesses als auch der Zuverlässigkeit. Nur automatisierte Installationen können nachvollzogen und wiederholt werden.

7.2.1.1 Digitale Performance Metriken

Wir folgen dabei den Definitionen aus der DevOps Welt wie den Schlüssel Metriken zur Messung der DevOps Performance8 und dem „2022 Accelerate State of DevOps Report“ von Google9, weil damit Schlüsselgrößen für die Aktivität verbunden sind. Diese MÜSSEN von kontinuierlich erfasst und aktuell auf einem Dashboard veröffentlicht und bewertet werden.

Alle Kennzahlen in fünf Größen zusammengezogen:

1. Bereitstellungshäufigkeit - Wie oft ein Unternehmen oder ein Projekt erfolgreich für die Produktion freigibt

2. Vorlaufzeit für Änderungen - Die Zeit, die ein Commit benötigt, um in Produktion zu gehen

3. Change Failure Rate - Der Prozentsatz der Implementierungen, die zu einem Ausfall in der Produktion führen

4. Mean Time to Restore Service (MTtR, Zeit bis zur Wiederherstellung des Dienstes) - Wie lange ein Unternehmen braucht, um sich von einem Ausfall in der Produktion zu erholen.

5. Zuverlässigkeit
   Wir folgen der Definition von SRE (Site Reliability Engineering)10 und messen Verfügbarkeit, Latenz und Ressourcen Verbrauch

Der „primäre Dienst“ ist in diesem Fall der souveräne Arbeitsplatz, der aus einer zweistelligen Zahl von Komponenten besteht. Da diese Komponenten häufig aktualisiert werden, ist mit einer mittleren bis hohen Änderungsrate zu rechnen.

Für die Zeit von der Übermittlung des Codes bis zum Einsatz in der Produktion wird mit einer mittleren „Lead Time“ für Änderungsraten von einer Woche bis einem Monat gerechnet. Um Sicherheitsupdates schnell auszurollen, muss auch eine Änderung innerhalb eines Tages möglich sein.

Weil mit dem Ausfall des Dienstes ein hoher Reputationsverlust verbunden ist, muss die darf Zeit für die Wiederherstellung einen Tag nicht überschreiten.

Die Fehlerquote bei Änderungen muss sehr niedrig sein und ist durch geeignete Maßnahmen so nah wie möglich an 0% zu drücken.

Die Metriken werden wie folgt bewertet:11

Tabelle: Metriken für Software Auslieferung

7.2.2 Implementierung von Applikationen

Unter einer Applikation verstehen wir einen oder mehrere Microservices, implementiert als Container, die zusammenarbeiten.

Die Konfiguration erfolgt durch Helm Charts.

7.2.2.1 Versionierung

Alle Helm Charts, Container und Konfigurationen MÜSSEN eindeutig versioniert und signiert werden.

7.2.2.2 Container

Container SOLLEN nach 12Factor12 Kriterien entwickelt werden. Es DÜRFEN nur die Anwendungen im Container enthalten sein, die für den Betrieb des Containers gebraucht werden. Es SOLL nur EIN PROZESS pro Container gestartet werden. Es DÜRFEN keine für einen Angriff verwendbare Werkzeuge13 vorhanden sein.

Idealerweise wird dafür ein statische Binärdatei, verwendet. Auch eine minimale Umgebung14 ist noch erlaubt.

12Factor IX „Disposability“15 verpflichtet zu schnellen Starts und Stops. Das schließt Prozesse mit Just in Time (JIT) Compilern eigentlich aus. Deswegen ist der Einsatz nur in Ausnahmefällen möglich. Vorzuziehen sind für Programmiersprachen die auf der Java Virtual Machine beruhen die Übersetzung in Native Executables16. Entsprechende Frameworks sind einzusetzen. Als Obergrenze bis zum Start eines Containers werden 60s festgelegt.

7.2.2.3 Helm Charts

Der Paketmanager Helm17 verbindet die Container mit Templates und Variablen zu einer vollständigen Applikation. Dabei werden vollständige Kubernetes Objekte erzeugt. Der gesamte Souveräne Arbeitsplatz wird als ein konfigurierbarer Helm Chart ausgeliefert.

Alle verwendeten Applikationen werden durch Abhängigkeiten18 auf andere Helm Charts implementiert. Schalter legen fest, welche Anwendungen und Features tatsächlich ausgeliefert werden.

Alle Charts MÜSSEN auch die Anbindung an die Peripherie wie Netzwerke, Ingress, Loadbalancer, Networkpolicies, Storage, Zertifikate und ähnliches konfigurieren.

Alle Helm Charts MÜSSEN elementare Tests vorsehen, die zeigen, ob alle Container im Zustand READY sind.

7.2.2.4 Rollout Prozess

Der Prozess des Rollouts MUSS vollautomatisch nur aus Images, Charts und Git Commits durch einen Gitops19 Prozess geschehen. Ein Rollback MUSS möglich sein.

Alle Helm Charts MÜSSEN automatisiert ausrollbar sein. Hooks20 MÜSSEN so eingesetzt werden, dass das Deployment durch automatisierte Tools möglich ist21.

7.2.2.4.1 Lizenz Compliance

Bis zum Erscheinen eines deutschen oder europäischen Rahmens wird der Standard des US „Department of Commerce - The Minimum Elements for an SBOM“ verwendet22. Für jeden Container MUSS eine SBOM23 im SPDX oder CycloneDX Format erstellt werden. SBOMs MÜSSEN signiert werden.

7.2.3 Segmentierung im Schichtenmodell

Jede Anwendung ist in geeignete Schichten aufzuteilen24. Die Schichten bilden eine Hierarchie, vom Frontend bis zur Persistenzschicht und dürfen nur eine Kommunikation von oben innerhalb einer Schicht und in die unteren Schichten aufbauen.

7.2.4 Netzwerk

Die Netzwerkschicht MUSS auf die Anforderungen der umgebenden virtuellen oder on Premises Implementierung der Nodes und der aufnehmenden Rechenzentren angepasst sein. Die Architektur MUSS zusammen zusammen mit der Einbettung konzipiert und bewertet werden. Dies gilt für virtuelle Umgebungen als auch im Zusammenhang mit Software Defined Networks.

Nicht betrachtet werden die Implementierung außerhalb des Kubernetes Stacks, also Hypervisor, Hardware und Netzwerkimplementierung. Für alle diese Komponenten SOLLEN Open Source Implementierungen verwendet werden, soweit sie vorliegen.25

7.2.5 Implementierung

Zur Netzwerkschicht zählen alle Komponenten, die das Kubernetes Network Modell26 implementieren.

Die Netzwerkschicht muss durch den Plattformbetreiber implementiert werden. Dabei ist darauf zu achten, dass die Vorgaben der DVS Zielarchitektur 2.0 Verschlüsselung vorsehen. Es gibt zahlreiche Implementierungen27, es SOLLEN nur solche ausgewählt werden, die CNCF graduiert sind. Von einem Hersteller in der ganzen Deployment Chain zur Verfügung stehen.

7.2.6 Datenschicht

Die Daten werden in einem oder mehreren Kubernetes Storage durch das Container Storage Interface (CSI)28 mit einem der Treiber implementiert.29 Die Storageschicht muss ausreichend dimensoniert sein. Die Dimensionierung ist durch geeignete Last Tests zu überprüfen

7.2.6.1 Logging

Aus dem Logging werden Analysen über den aktuellen und historischen Zustand des Clusters und der Applikationen abgeleitet. Damit wird das Monitoring des Betriebszustandes, Alarmierungen im Falle einer Störung und Trendanalysen für Planungen abgeleitet. Es werden auch hier Projekte aus dem Bereich der Cloud Native Observability and Analysis Frameworks30 eingesetzt, z.B. Fluentd31, der sicherstellt, dass die Logdaten verschiedener Quellen in verschiedenen Endpunkten gespeichert werden können.

7.2.6.1.1 Kubernetes Logs

Die Logdaten der Kubernetes Infrastruktur sind für den Betrieb notwendig, müssen aber über die betrieblichen Erfordernisse nicht aufbewahrt werden. Für Trendanalyse reicht eine Aggregation.

7.2.6.1.2 Application Logs

Applikationen haben u.U. individuelle Anforderungen an das Logging. Es MUSS möglich die Logfiles verschiedener Applikationen individuell zu trennen und in verschiedene Endpunkte zu schreiben.

7.2.6.1.3 Monitoring

Für das Monitoring sind Dashboards anzulegen, die den Betriebszustand angemessen visualisieren.32 Dazu gehört neben dem Ist-Zustand auch eine Visualierung der Historie und über eine Trendanalyse eine Projektion in die Zukunft.

7.2.7 Continuous Integration

Eine CI Pipeline33 für den SouvAp wird eingerichtet. Alle Quellen einschließlich der Build Anweisungen für alle Artefakte sowie der Tests werden im OpenCoDE Repository abgelegt.

Binäre Artefakte wie Pakete und Container Images werden in Repositories abgelegt34. Die Repositories müssen nicht öffentlich zugänglich sein.

Abbildung : Continuous Integration

Die Abbildung zeigt eine minimale Deployment Pipeline. Der weiße Pfad definiert die Build-, Test- und Deploymentschritte zum Ausrollen einer Applikation. Die roten Schritte definieren zusätzliche Sicherheitsprüfungen, die nicht in jedem Commit durchlaufen werden müssen, aber nächtlich oder minimal wöchentlich ausgeführt werden müssen.

7.2.7.1 Verteilung der Pipeline

Die Pipeline ist nicht als eine einheitliche Applikation zu verstehen, die an einem zentralen Ort abläuft. Die Übergabepunkte werden durch Trigger angesprochen35, wie sie z.B. OpenCode.de und jede Git Implementierung über Web Hooks36 auslösen kann. Sind Web Hooks aus Sicherheitsgründen nicht möglich, treten periodische Pull Prozesse an ihre Stelle.

Es gibt mindestens Prod/Staging/Dev. Darüber hinaus können weitere Umgebungen aufgebaut werden, z.B. für Last Tests. Die Verantwortlichkeiten und Übergabepunkte sind noch zu definieren.

Bei Übergabe sind Signierte Container und Helm Charts mit eindeutiger Versionierung zu übergeben.

7.2.7.2 Freigaben

Technisch werden Freigaben über einen Git Commit realisiert. Durch Web Hooks können beliebige Prozesse angestoßen werden.

7.2.7.3 GitOps Rollout

Für das Rollout der Applikation wird ein GitOps Prozess37 verwendet. Die Zielkonfiguration wird in einem Git Repository beim Betreiber erfasst. Wenn durch einen neuen Commit im Repository eine Abweichung entsteht, wird automatisch eine Synchronisation den Ziel- auf den Ist-Zustand durchgeführt.

Das Rollout der Konfiguration erfolgt durch eine Web-Anwendung, die diesen Prozess visualisiert38. Ein Rollback muss möglich sein.

7.2.8 Modularität

Die Phasen 1-7 MÜSSEN durch die Entwicklung abgedeckt werden.

Alle Beteiligten im Projekt müssen in die Lage versetzt werden, alle Phasen des Projektes in eigener Souveränität durchzuführen. Für die automatischen Schritte ist es notwendig, dass neben dem Programmcode auch Bauprozesse und die Elemente der Build Pipeline offengelegt wird. Dazu gehören

1. Build Scripte

2. Bauanleitungen für die Container

   1. Dockerfiles

   2. oder ähnliches

3. Härtungsskripte

4. Test Suiten39

5. Deployment

   1. Basis Funktionalität

   2. Spezielle Anforderungen wie Tests mit Netzwerk oder Storage Schichten.

Es ist nicht notwendig, dass Test Suites in beliebiger Tiefe ausgeführt werden. Für die Entwicklung durch Zendis wird eine minimale Pipeline realisiert. Das Deployment wird nur in einer Basisvariante durchgeführt, nicht mit z.B speziellen Netzwerkschichten. Diese können auf Anforderung durch Erweiterung der Beauftragung hinzu genommen werden. Gleiches gilt für Lasttests.

7.2.8.1 Registry

Es MUSS eine Registry für die Container Images verwendet werden.

7.2.9 Föderierung

Eine Föderierung von Diensten über Cluster Grenzen muss möglich sein, das bedeutet nicht eine Föderierung von Clustern (siehe D+S).

7.3 Phase D+S: Sicherheitsarchitektur

Eine wesentliche Voraussetzung für Souveränität ist Sicherheit. Unter Sicherheit werden viele Aspekte zusammengefasst, die im einzelnen detailliert ausgeführt werden.

7.3.1 DevSecOps Phasen und Sicherheitsaspekte

Um aus einem DevOps Ansatz einen DevSecOps Prozess zu machen, orientiert sich an den Prozessen von Clound Native Computing Foundation (CNCF) und dem US Department of Defence (US DoD)40, insbesondere an den DoD Enterprise DevSecOps Fundamentals41.

Hinzu kommen 14 Sicherheitsaspekte in den verschiedenen Phasen. Ziel aller Phasen ist zu jeder Zeit und in jedem Cluster nur bekannte Artefakte und Konfigurationen zu haben.

Tabelle 1: DevSecOps Phasen und Sicherheitsaspekte

7.3.1.1 Signaturen

Dadurch dass sie signiert sind, und die Signaturen geprüft werden, kann garantiert werden, dass es keine ungewünschten Programme und Konfigurationen im System gibt. Die Erfassung der Signaturen in einem Kontobuch garantiert zudem, dass keine Artefakte im Umlauf sind, die eine Signatur tragen und nicht legitimiert sind. Dazu ist der Betrieb eines oder mehrere souveränen Kontobücher notwendig49. Ein öffentliches Kontobuch erfasst alle für den souveränen Arbeitsplatz aus Open Source Komponenten erzeugten Signaturen. Für Erweiterungen in einem nichtöffentlichen Prozess ist der Betrieb eines privaten Kontobuches innerhalb der jeweiligen Organisation notwendig.

7.3.1.2 Metriken für die Umsetzung des DevSecOps Prozesses

Das „DevSecOps Fundamental Playbook des US-DoD“50 empfiehlt die Übernahme der Google Metriken statt eines Reife Modells51 wie es bereits in Kapitel D eingeführt wird.

7.3.2 Tiefe Sicherheit

Es werden gestaffelte Schutzmassnahmen, „Security in Depth“ verwendet. Selbst wenn die Applikation im Container verwundbar ist, wird ein Ausbruch in das System durch andere Massnahmen wie die Container Runtime oder Networkpolicies verhindert.

Das Konzept zieht sich durch alle Aspekte. Eine Sicherheitslücke in einem Aspekt muss durch andere Aspekte aufgehalten werden. Wenn z.B. eine Library in einer Applikation verwundbar ist, muss es unmöglich gemacht werden, diese Lücke auszunutzen. Es dürfen weder Tools für Laterale Angriffe im Container vorhanden sein noch dürfen Dienste erreichbar sein, die der Container nicht braucht.

Es MÜSSEN alle Sicherheitsvorkehrungen getroffen werden, die Kubernetes mitbringt52 und die die eingesetzten Produkte erlauben. Es auf der Applikationen, diese Einstellungen zu definieren. Im Sinne des DevSecOps Prozesses werden diese Einstellungen auditiert und bewertet.

7.3.3 Applikationen

7.3.3.1 Sicherer Auslieferung und Betrieb von Applikationen

Eine Applikation ist nur dann sicher betreibbar wenn sie einer eindeutig nachvollziehbare Lieferkette stammt. Neben der sicheren Grundkonfiguration beinhaltet das eine Versionierung einer Applikation. Für alle Applikationen ist eine SBOM zu liefern, für alle Container mit eine nachvollziehbaren Liste aller verwendeten Libraries. Es DÜRFEN KEINE Libraries enthalten sein, die nicht von der SBOM erfasst sind.

7.3.3.1.1 Container

Es werden gestaffelte Schutzmassnahmen, „Security in Depth“ verwendet. Selbst wenn die Applikation im Container verwundbar ist, wird ein Ausbruch in das System durch andere Massnahmen wie die Container Runtime oder Networkpolicies verhindert. Wenn Container mit mehreren Prozessen, also ähnlich wie virtuelle Maschinen betrieben werden müssen53, ist eine gesonderte Betrachtung durchzuführen.

Es dürfen keine persistenten Daten in Containern gehalten werden. Sollen Datenbanken betrieben werden, muss die Speicherung auf externem Storage erfolgen.

Es sind grundsätzlich Datenbanken in Clustern auf verschiedenen Nodes verteilt zu verwenden. Jeder Container ist als vergänglich (ephemeral) zu betrachten und kann durch den Betrieb jederzeit ohne Ankündigung beendet werden. Alle davon abhängigen Dienste MÜSSEN dessen ungeachtet unterbrechungsfrei weiterlaufen, es gibt grundsätzlich keine Wartungszeiten.

Eine Zusammenfassung findet sich im verpflichtenden BSI Standard SYS 1.6.

7.3.3.1.2 Stateless Containers

Es dürfen nur zustandslose Container verwendet werden. Das schliesst Datenbanken im Cluster mit ein, sofern sie sich auf Storage abstützen und vollautomatisch Backup-Restore fähig sind. Der Zyklus ist automatisiert zu testen.

7.3.3.1.3 Container Images

Es SOLLEN, ab Q1 2024 MÜSSEN nur gehärtete Container ausgerollt werden mit idealerweise statisch gelinkten Binaries54. Container SOLLEN, ab Q1 2024 DÜRFEN im Gegensatz zur Praxis auf Dockerhub oder auch bei Red Hat 55KEINE Betriebssystem Komponenten enthalten (curl, wget, aber auch echo, cat)
Ausnahmen sind zu vermeiden und MÜSSEN unter Vorlage einer Risikoanalyse genehmigt werden. Dabei sind die Security Scans der Container mit einzubeziehen.

7.3.3.1.4 Nutzungstypen

Der Nutzungstype eines Cluster hängt von der Bedrohungsanalyse der Anwendungen ab. Wenn nur eigener Code verwendet und ausgeschlossen werden kann, das Sidechannel Attacks durchgeführt werden können, DARF Hardware geteilt werden (Shared).
Sobald laut Risiko Analyse Code verwendet wird, der nicht vertrauenswürdig ist, MUSS die Isolation auf eigenen Hardware Nodes erfolgen., nicht nur VMs als NodePool sondern auf einem eigenem Cluster.

7.3.3.1.5 Helm Charts

Helm Charts implementieren „Configuration as Code“ und sind als Teil des Lieferprozesses auf Sicherheitslücken zu überprüfen, zu auditieren und zu scannen.

Die Charts DÜRFEN KEINE Secrets enthalten. Secrets werden immer gesondert ausgerollt. In den Helm Charts werden die Namen der Secrets referenziert.

7.3.3.1.6 Secret Management

Ein geeignetes Secret Management ist zu etablieren.

7.3.3.1.7 Git Repository

Es wird von Kerckhoffs’ Prinzip56 ausgegangen. Alle Konfigurationen, Charts, Build Umgebungen müssen im OpenCode Repository des Bundes öffentlich zur Verfügung stehen.

Alle Secrets, Passwörter, Credentials DÜRFEN NICHT öffentlich sein und MÜSSEN auf den Betreiber beschränkt werden.

Alle Git Commits MÜSSEN signiert57 werden, die Signaturen MÜSSEN vor der Weiterverarbeitung geprüft werden.

7.3.3.1.8 Rollout Prozess

Alle Artefakte für den Rollout müssen signiert werden. Das betrifft Images, Charts und Git Commits.

7.3.3.1.9 SBOM

Die SBOM muss automatisch auf Verwundbarkeiten überprüft werden.

7.3.3.2 Segmentierung im Schichtenmodell

Die Isolation im Schichtenmodell ist durch Microsegmentation58 auf der Netzwerkschicht zu implementieren.

7.3.3.3 Frontend

Frontend Anwendungen sind von außen erreichbar. Aus diesem Grund MÜSSEN sie besonders gehärtet werden.

7.3.3.4 Netzwerk

Die Sicherheit der Netzwerkschicht MUSS zusammen zusammen mit der Umgebung implementiert werden. Es ist von aussen durchgehend HTTPS zu verwenden. Sie muss an die Anforderungen der umgebenden virtuellen oder on Premises Implementierung der Nodes und der aufnehmenden Rechenzentren angepasst sein. Die Architektur MUSS zusammen zusammen mit der Einbettung konzipiert und bewertet werden. Dies gilt für virtuelle Umgebungen als auch im Zusammenhang mit Software Defined Networks.

Abbildung :Netzwerk

Nicht betrachtet werden die Implementierung außerhalb des Kubernetes Stacks, also Hypervisor, Hardware und Netzwerkimplementierung. Für alle diese Komponenten SOLLEN Open Source Implementierungen verwendet werden, soweit sie vorliegen.59

Die Loadbalancer sind außerhalb des Clusters. Die Netzwerkschicht MUSS Microsegmenation durch Networkpolicies oder im Falle des Einsatzes von ServiceMeshs eine vergleichbare Isolation erlauben.

Eingehende Anfragen werden in der Ingress Schicht60 autorisiert und authentifiziert. Dazu ist eine Anbindung an das ein Identity and Access Management System notwendig. Auch ein zukünftiges API Gateway wird in diese Schicht integriert61.

7.3.3.4.1 Verschlüsselung auf der Netzwerkschicht

Verschlüsselung auf der Netzwerkschicht ist eine Vorgabe aus der DVS Zielarchiektur. Aus diesem Grunde MUSS ein Produkt ausgewählt werden62, dass diese Eigenschaft auf eine Weise implementiert, die nicht umgangen werden kann63. Das kann durch VPN Tunnel oder mTLS Proxies in Service Meshs implementiert werden.

Der Standard für VPN Tunnel unter Kubernetes ist Wireguard64. Sobald eine Implementierung von Post Quantum Key Exchange mit Wireguard unter Kubernetes vorliegt, MUSS sie eingesetzt werden65.

7.3.3.4.2 Servicemesh

Ein Servicemesh66 KANN eingesetzt werden, um die Vorgaben zu zentralisieren67. Der Einsatz stellt einen tiefen Eingriff in die Netzwerkarchitektur und -sicherheit dar.

Bei Einsatz eines Servicemeshs MUSS die Mikrosegmentierung mit den Mitteln des Servicemeshs umgesetzt werden. Die Implementierung muss einer eigenen Sicherheitsbetrachtung unterzogen werden. Es ist darauf dazu zu achten, dass das Sidecar Pattern68 alleine nicht geeignet ist, eine ausreichende Trennung zwischen Netzwerksegmentierung und Applikation zu gewährleisten69. Es MUSS eine Implementierung über das Container Network Interface (CNI)70, oder bei entsprechender Reife, über das Service Mesh Interface (SMI)71 gewählt werden.

7.3.3.4.3 Verschlüsselung

Es ist Aufgabe der Plattformbetreiber, nachzuweisen, dass die Vorgabe zur Hoheit über Krypto-Module und –Schlüssel eingehalten wird.72

7.3.3.4.4 Isolation P-A-P

Es eine Kombination von Paketfiltern und Web-Applikationsfiltern (WAF) einzusetzen. Die erste Schicht der Paketfilterung wird bereits vom Loadbalancer implementiert, die WAF SOLLTE in die Ingressschicht integriert werden.73 Real-Time Audio Video Kommunikation muss gesondert betrachtet werden.

7.3.3.4.5 Microsegmentation

Die zweite Paketfilterschicht MUSS durch die Basis Netzwerkimplementierung in die Beziehungen der Applikationen eingreifen und darf nur notwendige Verbindungen zulassen. Im Sinne einer minimalen Rechtevergabe74 MUSS durch Massnahmen der Netzwerkschicht sichergestellt werden, dass sich nur Anwendungen miteinander verbinden können, die diesen Kontakt benötigen. Die Sicherstellung durch Networkpolicies oder entsprechende Service Mesh Regeln sind Teil der Applikation und durch einen Helm Chart auszuliefern. Um zu erschweren, dass die Regeln durch Applikationen ausser Kraft gesetzt werden können, MUSS eine Implementierung über das CNI oder CMI erfolgen. Sidecars, die durch Admission Controller75 erzeugt werden, können umgangen werden und sind als nicht ausreichend anzusehen.

7.3.3.4.6 Verschlüsselung der Datenschicht (Encryption on Rest)

Es SOLLTE eine Implementierung mit Encryption76 on Rest eingesetzt werden, sobald für diese Implementierung allgemein verfügbar ist.77 Dies gilt besonders für Umgebungen mit hohem Schutzbedarf.

7.3.3.4.7 Datenbanken

Datenbanken in Kubernetes MÜSSEN grundsätzlich als verteilter Datenbank Cluster aufgesetzt werden.78 Einzelne Datenbank-Nodes sind ephemeral, dafür MUSS die Synchronisation überwacht werden. Datenbank Cluster MÜSSEN so dimensioniert werden, dass die Last durch das Aufsynchronisieren eines neuen Nodes nach Ausfall eines Nodes zu keinen Performance Einschränkungen führen kann.79

7.3.3.4.8 Backup-Restore

Für die Persistenzschicht MUSS ein vollständiger Backup-Restore Zyklus aufgesetzt werden.80 Die Restore Fähigkeit der Daten ist automatisiert regelmäßig, mindestens wöchentlich, zu testen.81 Der Backup Prozess DARF die Daten NICHT im gleichen Storage System ablegen auf dem die Daten lagern. Es ist zu prüfen, ob weitere Anforderungen an Wiederherstellung nach Katastrophen eingehalten werden müssen.

Die Daten müssen verschlüsselt gespeichert werden. Der Schlüssel muss separat von den Daten abgelegt werden.

7.3.3.4.9 Logging

Für alle Arten von Logging müssen angemessene Aufbewahrungsfristen definiert werden.

7.3.3.4.9.1 Audit Logs

Kubernetes Audit Logs82 dienen der Aufzeichnung sicherheitsrelevanter Änderungen am Cluster. Sie MÜSSEN außerhalb des Clusters in einer eigenen Datenbank gespeichert werden. Sie erfassen die Daten des Betriebs, sowohl der Änderungen die automatisch durchgeführt werden als auch die durch Betriebspersonal veranlassten Änderungen des Clusterzustandes. Sie werden für Sicherheits Audits herangezogen.

Die Erfassung der Daten des Betriebspersonals kann die Zustimmung der Personalvertretung erfordern. Es eine geeignete Audit Log Policy83 definiert werden.

7.3.3.4.9.2 Application Logs

Es DÜRFEN KEINE sicherheitsrelevanten Informationen in den Logs erfasst werden, auch nicht während einer Fehleranalyse.

7.3.3.4.9.3 Monitoring

Für das Monitoring sind Dashboards anzulegen, die den Betriebszustand angemessen visualisieren84.

7.3.3.4.10 Alerting

Aus dem Monitoring System MÜSSEN Alarme abgeleitet werden, die im Fall einer Störung das Betriebspersonal benachrichtigen.

7.3.3.4.11 Management Cluster

Für die Steuerung der GitOps Prozess MUSS ein separater Management Cluster verwendet werden. Der Cluster steuert die Arbeitscluster und hat deshalb eine hohe Vertrauensstellung. Auf dem Management Cluster darf keine andere Arbeitslast installiert sein, um Supply Chain Attacks zu verhindern85.

Es wird eine Verbindung zu einer Registry und einem Git Repository benötigt. Eine Installation z.B. mit Harbor, Gitea und ArgoCD86 kann auch so eingerichtet werden, dass Produktionssysteme ohne Verbindung zum Internet betrieben werden können, z.B. als Container Proxy Cache87 und Git Mirror88. Die Komponenten können durch andere Produkte ersetzt werden.

Der Management Cluster DARF NICHT von den Produktionsclustern gesteuert werden. Er MUSS so eingerichtet werden, dass nur signierte und überprüfte Artefakte ausgerollt werden können.

Er braucht nicht permanent zu Verfügung stehen, wenn eine andere Registry verwendet wird.

Alle Logging Anforderungen für Kubernetes Cluster gelten auch für den Management Cluster. Insbesondere die Ergebnisse der Vulnerability Scans MÜSSEN zeitnah ausgewertet werden und in angemessene Reaktionen von Updates bis zum Abschalten der Applikationen umgesetzt werden.

7.3.3.5 Continuous Integration

Binäre Artefakte wie Pakete und Container Images werden in Repositories abgelegt89. Die Repositories müssen nicht öffentlich zugänglich sein. Die Pakete und Images sind mit GPG90 und Sigstore91 zu signieren.

1. Die Artefakte MÜSSEN auf einem Build Server aus dem Source Code erzeugt und paketetiert werden.

1. Der Source Code MUSS auf Verwundbarkeiten gescannt werden.

1. Die Berichte dazu MÜSSEN vorgelegt werden.

1. Eine Software Bill of Material MUSS erzeugt werden.

1. Die Container müssen aus den Paketen erzeugt, signiert und in die Container Registry geladen werden.

1. Ein Security Scanner MUSS die Container auf Verwundbarkeiten untersuchen.

1. Die Container werden auf einem Testcluster mit einer Testkonfiguration ausgerollt und automatisch und manuell getestet.

1. Auf dem Testcluster MUSS ein vollständiger Integrationstest durchgeführt werden.

1. Die Freigabe erfolgt über eine weitere Signatur, die in einer geeigneten abgeschotteten Umgebung durchgeführt werden MUSS.

1. Zusätzlich werden weitere Sicherheitstests an der Applikation durchgeführt92.

Die Cluster werden permanent durch geeignete Scanner auf Sicherheitslücken und Fehlkonfigurationen geprüft93.

7.3.3.5.1 Registry

In der Registry MÜSSEN alle Container auf Sicherheitslücken überprüft werden.94 Ein Schwachstellenmanagement und ein automatisierter Export von CVEs MUSS möglich sein.

7.3.3.5.2 Scannen

Die Überprüfung muss mindestens täglich gegen die Common Vulnerabilities and Exposure (CVE)95 Datenbank erfolgen, die Ergebnisse der Scans sind zu loggen und bei Auffinden einer Sicherheitslücke ist ein Alarm auszulösen. Als Scanner kommen verschiedene Scanner in Frage.96

7.3.3.6 Policies

Es ist zu erwarten, dass im Falle einer Sicherheitslücke das Abschalten eines unsicheren Containers nicht ohne weiteres möglich ist. Für diesen Fall muss ein Prozess aufgesetzt werden, der eine Entscheidung vorbereitet, wann

1. Entscheidung Weiterbetrieb eines verwundbaren Containers oder Abschalten

1. Anstoßen eines Bug Fix Prozesses

1. Ausrollen der gefixten Version

Die Aktionen sind angemessen zu dokumentieren.

7.3.3.7 Signieren

Container MÜSSEN signiert werden. Der Signaturprozesse MUSS in einer sicheren Umgebung erfolgen. Schlüssellängen MÜSSEN den BSI Vorgaben97 für kryptographische Verfahren entsprechen.

Alle Container, Helm Charts und Git Konfigurationen, von denen ein Deployment abhängt, MÜSSEN signiert sein. Der Prozess MUSS so aufgesetzt, dass in der CI/CD Pipeline keine Container, Helm Charts und Konfigurationen zum Deployment eingesetzt werden, die nicht signiert werden.

1. Die Registry muss die Signaturen der Container überprüfen.

1. Deployment Tools müssen die Signaturen der Helm Charts und des Git Commits prüfen.

1. Es dürfen nur Kubernetes Versionen verwendet werden, die sich so konfigurieren lassen, dass nur signierte Container zu Ausführung kommen. Das geschieht idealerweise durch die Kubernetes Runtime98. Wird ein Admission-Controller99 eingesetzt, ist er so zu konfigurieren, dass keine unsignierten Container im ganzen Cluster eingesetzt werden.

7.3.3.7.1 Keyless Signature

Es MUSS eine Infrastruktur für Keyless Signing100 mit einer Certificate Authority (CA) aufgesetzt werden, die Keyless Signing unterstützt101. Über die Signaturen ist ein Kontobuch zu führen, dass die Signaturen aller Images erfasst102. Insbesondere ist die zeitliche Gültigkeit der Schlüssel zu überprüfen.

Produktions Images MÜSSEN mit dieser Infrastruktur signiert werden.

7.3.3.8 Sicherheit

Es wird „Defense in Depth“ durchgeführt103. Das bedeutet, dass verschiedene Sicherheitsmaßnahmen eingeführt werden, die sich ergänzen. Die Sicherheit des Gesamtsystems muss gewährleistet sein, auch wenn einzelne Teile kompromittiert sind.

Im Einzelnen müssen die folgenden Maßnahmen ergriffen werden.

7.3.3.8.1 Container

Es MÜSSEN minimale, signierte Container wie oben definiert verwendet werden.

7.3.3.8.2 Microsegmentierung durch Networkpolicies

Die Container MÜSSEN durch Networkpolicies wie oben definiert isoliert werden.

7.3.3.9 Secret Management

Ein eigenes Secret Management ist einzuführen, um Credentials unabhängig von Git Repositories aufbewahren zu können.

7.3.3.10 Kubernetes-spezifische Sicherheitsmaßnahmen

In den Clustern muss der Zugriff von Anwendungen auf Host, Netz und Cluster Ressourcen auf das notwendige Maß beschränkt werden. Die aktuellen CIS und Nist Standards sind einzuhalten, eine aktuelle Übersicht104 verweist auf die weitergehenden Sicherheitsmassnahmen.

Darüber ist die Architektur so auszulegen, dass privilegierte Container keinen Zugang vom und zum Internet haben dürfen.105

7.3.3.11 Netzwerk Zonen

Innerhalb des Clusters MÜSSEN Schichten und Namespaces durch Microsegmentation isoliert sein. Egress Traffic MUSS auch über einen Loadbalancer/Firewall geleitet werden.

Die Frontend Netze können bei Vorliegen einer entsprechenden Risikoanalyse auf gemeinsamer Hardware betrieben werden. Für höhere Sicherheitsanforderungen MUSS die Loadbalancer Hardware getrennt werden.

Die Netze der Hosts werden aufgeteilt. Es können dafür mehrere Ingress Controller106 eingerichtet werden, die nur aus jeweils einer Zone erreichbar sind.

1. Externe Frontends
   Anbindung an Loadbalancer Richtung Internet

2. Föderierte Frontend
   Anbindung an Loadbalancer Richtung Föderierte Netze

3. Internes Frontend
   Anbindung an Interne Netze der Betreiber

4. Ggf. weiter Frontend Netze

5. Kubernetes Nodes
   Eigene Schicht, verschlüsselter Traffic (Wireguard) zwischen Nodes

   1. Internets Netz in Kubernetes
      nicht nach außen sichtbar ist. Zugriff nur über Proxies Richtung Frontend. Es MUSS eine Implementierung gewählt werden, die Microsegmentation erlaubt, ggf als Service Mesh

   2. Storage Schicht
      Anbindung an Storage Systeme

7.3.3.12 Föderierung

Unter Föderierung wird die Integration zweier oder mehr Cluster zu einer Einheit, verstanden. Nach außen wirkt die Föderierung wie eine Anwendung. Sie wird eingerichtet, um Latenz, Performance und/oder die Verfügbarkeit zu verbessern. Kritischer Punkt ist Verteilung der Datenschicht. Um die Konsistenz der Daten zu erreichen, muss bei schreibenden Zugriff eine Synchronisation der Daten erreicht werden. Vorteile für die Latenz werden dabei wieder zunichte gemacht. Neben der Verbindung der Netzwerke üblicherweise durch Service Meshs107 muss eine verteilte Datenhaltung über die Datenbank108 und das Storage System eingerichtet werden109.

Die Ingress Schicht wird durch einen Reverse Proxy implementiert. In dieser Schicht MUSS Authorisierung und Authentifizierung durch Anfrage an einen Authentifizierungsserver hergestellt werden. Grundsätzlich können auf dieser Ebene durch Redirects auch Dienste an andere Cluster durchgeführt werden. Der Cluster, der einen Request empfängt, MUSS die Autorisierung und Authentifizierung sicherstellen.

Eine Föderierung von Diensten ist möglich. Es muss die Authentifizierung und Autorisierung so eingerichtet werden, das ein Zugriff auf den Service einer anderen Behörde, mit dem Daten ausgetauscht werden sollen, wie ein externer Zugriff behandelt wird.

Zwischen Behörden wird Ingress Traffic über über ein Frontend mit jeweiligen Regeln geleitet. Egress Traffic wird mit Firewall Regeln limiiert.

Bei hohen Performance Anforderungen KANN nach Risikoanalyse und Prüfung ein gemeinsames VLAN über eine verschlüsseltes VPN zur Verbindung verwendet werden110.

Multi-Cluster Federation111 ist möglich, verkompliziert aber das Netzwerk, das Sicherheitsmodell und engt die Update Möglichkeiten so stark ein, dass davon abgeraten wird. Deswegen SOLL Multi Cluster Federation NICHT eingesetzt werden.

Es gibt keine direkte Kopplung zwischen Behördennetzen über VPN oder VLAN. Behördennetze werden als nicht sicher eingestuft.112

Alle föderierten Dienste MÜSSEN als WebServices angesprochen werden. TCP oder UDP, die in Ausnahmefällen notwendig werden, MÜSSEN um die Authentifizierung in Kubernetes verwenden zu können, über einen kube-proxy durchgeführt werden. Damit sind sie auch über TLS abgesichert.
Das schliesst auch alle Dienste über REST API ein, wie z.B. Nextcloud Federation113.

Alle REST API Schnittstellen MÜSSEN abgesichert werden. Die Regeln sind als RBAC Regeln zu dokumentieren. 114

7.3.3.13 Transport Layer Zertifikate

Aufgrund der großen Menge der anfallenden Domains und der damit verbundenen Zertifikate SOLLTE ein Automatisches Zertifikatsmanagement nach RFC 8555115 eingeführt werden. In diesem Fall SOLLTE ein Zertifikatsmanagement Dienst116 die Zertifikate automatisch aktualisieren.

7.3.3.14 Weitere notwendige sicherheitrelevante Dienste

7.3.3.14.1 ACME Server RFC 8555

Es SOLLTE ein ACME Server117 verwendet werden. Alle Dienste MÜSSEN über kurzlebige Zertifkate abgesichert werden. Zertifikate MÜSSEN über einen den Cert-Manager118 automatisch ausgerollt werden können.

7.3.3.14.2 Logging, Monitoring, Alerting

Es MÜSSEN von den Betreibern geeignete Logging, Monitoring und Alerting Systeme aufgebaut und Betrieben werden (Audit Logging, Cluster Monitoring und Applikations Logging). Diese MÜSSEN über ein Fluentd Output Plugin119 ansprechbar sein.

7.3.3.14.3 Scanning im Betrieb

Betreiber MÜSSEN die Sicherheit Ihrer Cluster täglich scannen und das Ergebnis dokumentieren.

7.3.3.14.4 Sigstore Transparency Log

Es SOLLTE ein eigenes Rekor Transparency Log geführt werden.120

Es DÜRFEN KEINE Container ausgführt werden, die nicht signiert werden. Es DÜRFEN KEINE Signaturen von Containern im Rekor Log existieren, zu denen keine Container auffindbar sind.

7.3.3.14.5 Signaturprüfung

Die Signaturen aller Container und Helm Charts MÜSSEN überprüft werden. Bei der Ausführung durch einen Admission Controller121 oder durch die Container Runtime (bevorzugt, sobald verfügbar)

7.3.3.14.6 Zero Trust

Aufgrund der Findings des Rechnungshofes122 kann nicht mehr davon ausgegangen werden, dass Verwaltungsnetze sicher sind. Deshalb sind alle Verbindung von und zum SouvAP und allen Anwendungen durch Authorisierung abzusichern. Dafür bietet sich eine Zero Trust Implementierung an.

7.3.3.15 Standards

Die folgenden Standards sind für das Projekt als verbindlich anzusehen. Dies sind weitestgehend Standards der Deutschen Verwaltungscloud, des BSI aber auch internationale Standards, die in der Cloud Native Community anerkannt sind.

Soweit keine deutschen oder EU Standards vorhanden sind, wird auf internationale Standards zurückgegriffen.

7.4 Phase D +M: Betrieb des Souveränen Arbeitsplatzes in einer Multicluster Umgebung

Der Betrieb des SouvAp in einer verteilten Umgebung, die mehrere Backend Standorte umfasst, muss grundsätzlich möglich sein. Alle Module des Souveränen Arbeitsplatzes sollten an jedem Standort installiert sein.

Die Replikation der Backend Infrastruktur an einen oder mehrere weitere Standorte erhöht grundsätzlich die Verfügbarkeit und liefert damit einen wesentlichen Beitrag zur Resilienz. Damit ist grundsätzlich eine Active-Active Replikation gemeint. Die dazu notwendige Synchronisation der Datenhaltung muss über Datenbank oder Storage Replikation erfolgen.

Durch die Möglichkeit, sich mit dem jeweils nächsten Cluster im Sinne der geringsten Latenz zu verbinden, erhöht dich die Benutzbarkeit und damit die Akzeptanz der User. Die Entwicklung in Kubernetes ist sehr dynamisch, vor einer konkreten Implementierung sind die existierenden Lösungen zu vergleichen. Eine Übersicht findet sich in „Simplifying multi-clusters in Kubernetes“ 124

7.4.1 Controlplane

Beide Cluster müssen durch die gleiche Git Konfiguration betrieben werden. Das Einrichten einer virtuellen Controlplane wird empfohlen125, es gibt aber noch viele weiter Optionen, um Cluster nur für ausgewählte Namespaces126 oder nur auf Netzwerkschicht 7127 zu synchronisieren. In diesem Fall müssen alle Namespaces aller Module des Souveränen Arbeitsplatzes synchronisiert werden.

7.4.2 Anforderung

Der Betrieb einer Multiclusterumgebung stellt einen erheblichen Aufwand da. Aus diesem Grund MUSS in der Bedrohungsanalyse eine Höchstverfügbarkeit oder eine entsprechende Lastabschätzung explizit verlangt werden. In ersten Fall sind die Kriterien für die Standortwahl von Rechenzentren128 einzuhalten.

Es wird davon ausgegangen, dass zwei oder mehr Rechenzentren sich gegenseitig unterbrechungsfrei vertreten und im Regelfall gemeinsam ihre Leistung zur Verfügung stellen. Ein reiner Standby Betrieb ist auch möglich, lässt aber große Teile der Kapazität brach liegen.

Aufgrund der Entfernungsanforderungen von im Regelfall mindestens 200km, bei Betrieb in zwei unterschiedlichen Flusssystemen mindestens 100km DÜRFEN nur asynchrone Methoden zur Datensynchronisation verwendet werden.

7.4.3 Netzwerk

Alle Beschreibungen für Kubernetes gehen davon aus, dass die Cluster sich ein Netzwerk als IP Subnetz teilen. Aufgrund der Anforderungen an die Verschlüsselung aus der DVS kommen dafür nur verschlüsselte Verbindungen in Frage. Durch die Kopplung des Netzwerkes an mehreren Standorten sind damit alle Netzwerke in der selben Sicherheitszone.

7.4.4 Kopplung durch Service Mesh

Es ist ein Deployment Modell129 zu definieren. In den Hyperscaler Clouds wird üblicherweise ein Servicemesh130 zugrunde gelegt. Dabei ist darauf zu achten, dass bei Updates die installierten Versionen einem genauen Upgradepfad folgen.

7.4.5 Loadbalancer

Üblicherweise sollen die Anwendung nach außen einheitlich erscheinen und für die Anwender nicht sichtbar sein, in welchem Standort die Anwendung läuft.

Dazu wird ein Globaler Loadbalancer so eingerichtet, dass er die Anfragen und den Traffic auf die Standort lokalen Loadbalancer umlenkt. Diese können die Daten mit verschiedenen Methoden, über ein Service Mesh, einen Ingress Controller oder bei hohen Lastanforderungen auch unter Umgehung des Linux Kernels direkt in die Container des Pod leiten.

7.4.6 Storage

Der Pod verarbeitet die Daten und speichert sie in eine lokale Datenbank oder über einen Persistent Volume Claim in ein Persistent Volume. Das Storage System, das das PV bereitstellt wird üblicherweise als Block Storage implementiert.

7.4.7 Synchronisation

Eine Datensynchronisation kann entweder über die Replikationsmechanismen der Datenbank oder des Blockstorage erfolgen.

7.4.7.1 Datenbanken

Datenbankreplikationen sind sehr speziell, deswegen muss für jedes Datenbank Management System (DBMS) die dazu passende Replikationsart gewählt und automatisiert eingerichtet werden. Im Zweifel ist die Datenbanksynchronisation performanter und deswegen vorzuziehen, weil der Automatisierungsaufwand nur einmal geleistet werden muss.

7.4.7.2 Blockspeicher

Einfacher einzurichten sind Replikationen durch Blockspeicher (Blockstorage). Die Methode eignet sich im wesentlichen für Dateien, bei Datenbanken ist eine Active-Active Replikation der verwendeten Blöcke, in diesen Fall ist eine Active-Passive Synchronisation sinnvoller. Es ist darauf zu achten, dass die Replikation zur Clustertopologie passt und lokal synchrone und für entfernte Replikationen asynchrone Replikation ausgewählt wird.

7.4.7.3 Verschlüsselung des Filesystems

Die Daten auf den verwendeten Filesystemen sind grundsätzlich zu verschlüsseln. Die dafür im BSI Grundschutz vorgesehenen Schlüssellängen sind einzuhalten131.

7.4.8 Monitoring

Zusätzlich zu den anderen Parametern sind noch die die Replikationslücke (replication lag) bei den Datenbanken und dem Speicher zu erfassen und zu bewerten. Der Betrieb ist so auszulegen, dass sich die Lücke nicht auswirkt132. Es gibt dafür verschiedene Strategien133.

7.4.9 Vertrauenszone

Durch die Netzwerkkopplung der Cluster sind die Netze beider Standorte direkt gekoppelt. Dadurch ist in der Sicherheitsbetrachtung immer darauf zu achten, dass beide Cluster eine gemeinsame Sicherheitszone bilden, die sich über zwei oder mehr Standorte erstreckt. Sind die einzelnen Cluster unterschiedlich eingestuft, wird der gekoppelte Verbund mit der niedrigeren Stufe bewertet.

1. Vgl. https://www.cncf.io/certification/software-conformance/↩︎

2. https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/↩︎

3. https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/↩︎

4. Vgl.: https://en.wikipedia.org/wiki/DevOps↩︎

5. https://www.ncsc.gov.uk/information/secure-default↩︎

6. Beispiel Web Server: http ist unsicher, https mit Installation von Zertifikaten ist sicher, aber komplex, anzustreben ist automatisches Ausrollen von Zertifikaten, z.B. mit ACME RFC 8555↩︎

7. https://www.cncf.io/projects/↩︎

8. https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance?hl=en↩︎

9. https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf?hl=de↩︎

10. https://de.wikipedia.org/wiki/Site_Reliability_Engineering↩︎

11. Zahlen sind eventuell anzupassen↩︎

12. Vgl. https://12factor.net↩︎

13. Vgl. Curl: https://github.com/thomasfricke/training-kubernetes-security/blob/main/OpenShift/ImageTragickExploit.ipynb oder auch ein simples cat und echo: https://andreafortuna.org/2021/03/06/some-useful-tips-about-dev-tcp/↩︎

14. Vgl. Google best practices for building containers: https://cloud.google.com/solutions/best-practices-for-building-containers; Minimal go container from scratch: https://github.com/endocode/minimal-go-container-from-scratch; Google Distroless: https://github.com/GoogleContainerTools/distroless; Alpine: https://www.alpinelinux.org/↩︎

15. Vgl. https://12factor.net/disposability↩︎

16. Vgl. https://en.wikipedia.org/wiki/Quarkus; https://quarkus.io/; https://micronaut.io/↩︎

17. Vgl. https://helm.sh/↩︎

18. Vgl. https://helm.sh/docs/helm/helm_dependency/↩︎

19. Vgl. https://de.wikipedia.org/wiki/DevOps#GitOps,https://www.redhat.com/en/topics/devops/what-is-gitops↩︎

20. Vgl. https://helm.sh/docs/topics/charts_hooks/↩︎

21. Vgl. z. B. https://argo-cd.readthedocs.io/en/stable/user-guide/helm/↩︎

22. Vgl. https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf↩︎

23. Vgl. https://www.cisa.gov/sbom; https://spdx.dev/; https://github.com/anchore/syft; https://cyclonedx.org/↩︎

24. Vgl. https://de.wikipedia.org/wiki/Schichtenarchitektur; https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html↩︎

25. Vgl. z.B. Hypervisor KVM: https://www.linux-kvm.org/page/Main_Page; Virtualisierungsmanagement https://scs.community/de/; offene Hardware: https://www.opencompute.org/; Sonic: https://azure.microsoft.com/de-de/blog/sonic-the-networking-switch-software-that-powers-the-microsoft-global-cloud/↩︎

26. https://kubernetes.io/docs/concepts/services-networking/#the-kubernetes-network-model↩︎

27. Vgl. https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy↩︎

28. Vgl. https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/↩︎

29. Vgl. https://kubernetes-csi.github.io/docs/drivers.html↩︎

30. https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category↩︎

31. Vgl. https://www.fluentd.org/↩︎

32. Vgl. z. B. https://grafana.com/grafana/dashboards/↩︎

33. Vgl. https://opensource.com/article/19/7/cicd-pipeline-rule-them-all↩︎

34. Vgl. https://www.networkworld.com/article/3305810/how-to-list-repositories-on-linux.html#:~:text=A%20Linux%20repository%20is%20a,software%20packages%20on%20Linux%20systems↩︎

35. https://docs.gitlab.com/ee/ci/triggers/↩︎

36. https://en.wikipedia.org/wiki/Webhook↩︎

37. Vgl. https://www.redhat.com/en/topics/devops/what-is-gitops↩︎

38. Vgl. z.B.: https://github.com/argoproj/argo-cd; https://fluxcd.io/↩︎

39. https://landscape.cncf.io/card-mode?category=cloud-native-network und https://landscape.cncf.io/card-mode?category=service-mesh↩︎

40. https://public.cyber.mil/devsecops/↩︎

41. https://software.af.mil/wp-content/uploads/2021/05/DoD-Enterprise-DevSecOps-2.0-Fundamentals.pdf↩︎

42. https://en.wikipedia.org/wiki/Secure_coding↩︎

43. https://owasp.org↩︎

44. https://github.com/thomasfricke/notebooks-management-cluster↩︎

45. https://goharbor.io/docs/2.0.0/administration/vulnerability-scanning/↩︎

46. https://github.com/kubescape/kubescape↩︎

47. https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/↩︎

48. https://goharbor.io/docs/2.1.0/administration/vulnerability-scanning/configure-system-allowlist/↩︎

49. https://blog.sigstore.dev/a-guide-to-running-sigstore-locally-f312dfac0682/↩︎

50. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsFundamentalsPlaybook.pdf↩︎

51. https://dsomm.timo-pagel.de/ und https://www.datadoghq.com/resources/devsecops-maturity-model/↩︎

52. https://kubernetes.io/docs/concepts/security/↩︎

53. Vgl. https://www.commitstrip.com/en/2016/06/24/how-to-host-a-coder-dinner-party/↩︎

54. distroless↩︎

55. https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image↩︎

56. Vgl. Kerckhoffs’ Prinzip: https://de.wikipedia.org/wiki/Kerckhoffs%E2%80%99_Prinzip↩︎

57. Vgl. https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/↩︎

58. Vgl. https://cloud.redhat.com/blog/networkpolicies-and-microsegmentation↩︎

59. Vgl. z.B. Hypervisor KVM: https://www.linux-kvm.org/page/Main_Page; Virtualisierungsmanagement https://scs.community/de/; offene Hardware: https://www.opencompute.org/; Sonic: https://azure.microsoft.com/de-de/blog/sonic-the-networking-switch-software-that-powers-the-microsoft-global-cloud/↩︎

60. Vgl. https://kubernetes.io/docs/concepts/services-networking/ingress/↩︎

61. Vgl. https://apisix.apache.org/docs/apisix/customize-nginx-configuration/↩︎

62. Vgl. z.B., aber ohne Anspruch auf Vollständigkeit,
    Tigera Calica: https://www.tigera.io/project-calico/; WeaveNet: https://www.weave.works/oss/net/; Cilium: https://cilium.io/↩︎

63. Das schließt Sidecars aus. Es muss nach das CNI verwendet werden: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/↩︎

64. https://www.wireguard.com/, security fixed durch STF https://sovereigntechfund.de/wireguard.html↩︎

65. Kandidat ist Projekt Rosenpass https://nlnet.nl/project/Rosenpass/↩︎

66. Vgl. Einführung: https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh; Auswahl einiger Produkte: https://thechief.io/c/editorial/top-14-kubernetes-service-meshes/; ohne Anspruch der Vollständigkeit↩︎

67. Der Reifegrad von Service Meshs unterliegt einer sehr dynamischen Entwicklung. Es ist zu erwarten, das im Laufe des Jahres 2023 eine oder mehrere Implentierungen einen Reifegrad erreichen, der eine Implementierung als Standard Netzwerkschicht erreicht. Dann wird die Verschlüsselung ausschließlich durch Service Meshs implementiert.↩︎

68. Vgl. https://istio.io/latest/docs/reference/config/networking/sidecar/↩︎

69. Vgl. Angriff auf Istio Sidecars: https://github.com/thomasfricke/training-kubernetes-security/blob/main/IstioHack.ipynb↩︎

70. Vgl. Container Network Interface: https://github.com/containernetworking/cni↩︎

71. Vgl. https://www.cncf.io/projects/service-mesh-interface-smi/↩︎

72. Vgl. DVS-007-R01↩︎

73. Vgl. https://en.wikipedia.org/wiki/ModSecurity↩︎

74. Vgl. https://en.wikipedia.org/wiki/Principle_of_least_privilege↩︎

75. Vgl. https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/↩︎

76. Es gibt dazu zahlreiche Standards vom BSI, die einzuhalten sind.↩︎

77. Vgl. https://github.com/kubernetes-sigs/secrets-store-csi-driver/issues/906↩︎

78. Vgl. z.B. https://github.com/zalando/postgres-operator↩︎

79. Also mindestens N+2↩︎

80. Vgl. z.B. mit https://velero.io/↩︎

81. Level of Done: Das Backup ist fertig, wenn der Restore getestet ist.↩︎

82. Vgl. https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/↩︎

83. Vgl. https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/#audit-policy↩︎

84. Vgl. z. B. https://grafana.com/grafana/dashboards/↩︎

85. Vgl. https://www.trendmicro.com/vinfo/be/security/news/vulnerabilities-and-exploits/abusing-argo-cd-helm-and-artifact-hub-an-analysis-of-supply-chain-attacks-in-cloud-native-applications↩︎

86. Vgl. https://github.com/thomasfricke/notebooks-management-cluster↩︎

87. Vgl. https://goharbor.io/docs/2.1.0/administration/configure-proxy-cache/↩︎

88. Vgl. https://docs.gitea.io/en-us/repo-mirror/↩︎

89. Vgl. https://www.networkworld.com/article/3305810/how-to-list-repositories-on-linux.html#:~:text=A%20Linux%20repository%20is%20a,software%20packages%20on%20Linux%20systems↩︎

90. Vgl. https://gnupg.org/↩︎

91. Vgl. https://www.sigstore.dev/↩︎

92. Vgl. z.B. OWASP Zap: https://owasp.org/www-project-zap/↩︎

93. Vgl. z.B., aber nicht nur mit: https://github.com/aquasecurity/kube-bench↩︎

94. Vgl. z.B. Harbor: https://goharbor.io/↩︎

95. Vgl. https://cve.mitre.org/cve/↩︎

96. Vgl. https://geekflare.com/container-security-scanners/; z.B. Trivy: https://trivy.dev/↩︎

97. Vgl. BSI TR-02102-1↩︎

98. Vgl. https://kubernetes.io/docs/setup/production-environment/container-runtimes/; z.B. https://cri-o.io/↩︎

99. Vgl. https://docs.sigstore.dev/policy-controller/overview/↩︎

100. Vgl. https://github.com/sigstore/cosign/blob/main/KEYLESS.md↩︎

101. Vgl. https://github.com/sigstore/fulcio↩︎

102. Vgl. https://github.com/sigstore/rekor↩︎

103. Vgl. https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/defense-in-depth↩︎

104. Vgl. https://kubernetes.io/docs/concepts/security/↩︎

105. Das ist ein Grund, warum ein Management Cluster isoliert von den anderen Clustern installiert werden muss, obwohl die Funktionalität natürlich mitlaufen kann.↩︎

106. https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource↩︎

107. https://www.cncf.io/blog/2021/04/12/simplifying-multi-clusters-in-kubernetes/↩︎

108. z.B. Vitess https://vitess.io/ auf der Basis von MySQL oder https://github.com/zalando/postgres-operator mit https://b-peng.blogspot.com/2021/07/postgres-disaster-recovery-on-k8s-zalando.html auf der Basis von Postgres↩︎

109. https://docs.ceph.com/en/quincy/radosgw/multisite/↩︎

110. z.B. mit Multus https://github.com/k8snetworkplumbingwg/multus-cni↩︎

111. https://www.cncf.io/blog/2021/04/12/simplifying-multi-clusters-in-kubernetes/↩︎

112. Nach https://background.tagesspiegel.de/cybersecurity/bundesrechnungshof-sieht-gravierende-defizite-bei-it-sicherheit↩︎

113. https://nextcloud.cmedia/wp135098u/Architecture-Whitepaper-WebVersion-072018.pdf↩︎

114. Nach Meinung der Entwickler gibt es nicht genug Interesse an der Cluster Federation https://groups.google.com/g/kubernetes-sig-multicluster/c/lciAVj-_ShE

     Das Kubefed Projekt wurde eingestellt https://github.com/kubernetes-sigs/kubefed, https://www.heise.de/select/ix/2019/3/1551686036454559

     Dies deckt sich mit der Erfahrung des Autors, der über das rein technische Interesse keinen realen Usecase gefunden hat.↩︎

115. Automatic Certificate Management Environment (ACME) https://datatracker.ietf.org/doc/html/rfc8555↩︎

116. https://www.cncf.io/blog/2022/10/19/cert-manager-becomes-a-cncf-incubating-project/↩︎

117. https://www.rfc-editor.org/rfc/rfc8555, z.B. https://github.com/letsencrypt/boulder↩︎

118. https://cert-manager.io/docs/↩︎

119. https://docs.fluentd.org/v/0.12/output↩︎

120. https://blog.sigstore.dev/a-guide-to-running-sigstore-locally-f312dfac0682/↩︎

121. https://github.com/sigstore/policy-controller↩︎

122. Nach https://background.tagesspiegel.de/cybersecurity/bundesrechnungshof-sieht-gravierende-defizite-bei-it-sicherheit↩︎

123. BSI Kriterien für die Standortwahl von Rechenzentren, Standort-Kriterien RZ Version 2.0↩︎

124. https://www.cncf.io/blog/2021/04/12/simplifying-multi-clusters-in-kubernetes/↩︎

125. https://github.com/virtual-kubelet/virtual-kubelet↩︎

126. https://submariner.io/,↩︎

127. https://skupper.io/↩︎

128. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/RZ-Sicherheit/Standort-Kriterien_Rechenzentren.pdf?__blob=publicationFile&v=1↩︎

129. https://istio.io/latest/docs/ops/deployment/deployment-models/↩︎

130. https://cloud.google.com/service-mesh/docs/unified-install/gke-install-multi-cluster↩︎

131. Relevante Grundschutz Bausteine: CON.1 Kryptokonzept,
     SYS.1.1 Allgemeiner Server – Container kann ein Server sein, sowie APP.4.4.A20 verschlüsselte Datenhaltung bei Pods↩︎

132. Innerhalb Deutschlands unter 10ms↩︎

133. https://github.blog/2017-10-13-mitigating-replication-lag-and-reducing-read-load-with-freno/↩︎