Anlage 1 zu V04__Leitfaden_Kuberntes.v7.pdf

[Seite 1]

Leitfaden

Provisionierung von Apps auf Docker Kubernetes

[Seite 2]

Herausgeber:

Staatsbetrieb Sachsenforst

Geschäftsleitung Abteilung Finanzmanagement

Referat Fach-Informationssysteme

Bonnewitzer Straße 34

01796 Pirna, OT Graupa

Redaktion:

Staatsbetrieb Sachsenforst

Referat Fach-Informationssysteme

Bildautoren:

Christian Thomas: Titelbild

Redakteure:

Dokumentenersteller: Thomas, Christian - SBS

Dokumentenredakteur: Thomas, Christian - SBS

Erzeugung des PDF-Dokumentes (Export): Thomas, Christian - SBS

Quelle des Dokumenteninhaltes:

http://betula.forst.smul.sachsen.de/display/DFRAM/Provisionierung+von+Apps+auf+Docker+Kubernetes

Redaktionsschluss:

Letzte Änderung der Hauptseite: 21. Januar 2025

Erzeugung des PDF-Dokumentes (Export): 21. Januar 2025

Auflage:

digital erzeugt

Verteilerhinweis:

Das Dokument sowie die Inhalte sind ausschließlich für die Auftragsverarbeitung (auch Auftragsdatenverarbeitung) zwischen dem Staatsbetrieb Sachsenforst und dem auftragsbezogenen Dienstleister bestimmt.

[Seite 3]

Provisionierung von Apps auf Docker Kubernetes - Dokumentenversion:7

Inhaltsverzeichnis

1 Zweck..........................................................................................................................4

2 Organisatorische Voraussetzungen/ Anwendungsbetrieb ......................................4

3 Docker Kubernetes (Webhosting).............................................................................4

4 Fernzugriff..................................................................................................................5

5 Aufbau des Kubernetes-Clusters...............................................................................5

5.1 Vefügbare Tools...............................................................................................................................5

6 Anforderungen an die Docker-Images/ -Container................................................6

7 Schwachstellenhandling............................................................................................6

8 Integrationen..............................................................................................................7

9 Bereitstellungsumgebungen......................................................................................7

10 Systemvoraussetzungen............................................................................................7

11 Lieferprozess...............................................................................................................8

12 Rollen- und Berechtigungskonzept..........................................................................8

12.1 Zugriff mit Berechtigungsnachweis...............................................................................................8

12.2 Zugriff ohne Berechtigungsnachweis.............................................................................................8 12.3 Benutzerverwaltung.........................................................................................................................8

13 Identity- und Accessmanagement............................................................................8

14 Dokumentation..........................................................................................................9

Seite 3 von 9

[Seite 4]

Provisionierung von Apps auf Docker Kubernetes- Dokumentenversion: 7

1 Zweck

Dieses Playbook dient als Anleitung und Leitfaden für die Implementierung eines Continuous Delivery-Prozess für Anwendungen (abgekürzt Apps) auf Basis Docker und Kubernetes für konkrete Projekte.

 Checkliste Alle folgenden Tipps in den grünen Boxen beinhalten relevanten Themen, die zugearbeitet werden müssen, um die initiale Einrichtung der Anwendungen durchführen zu können.

2 Organisatorische Voraussetzungen/ Anwendungsbetrieb

Für die initale Bereitstellung, den Betrieb sowie die laufende Wartung der Anwendungen sind zwingend Expertenteams notwendig. Diese können interne und externe Dienstleister sein.

 Ein Betrieb der Anwendungen ist ohne verbindliche Vereinbarung zur Anwendungswartung bzw. -pflege nicht möglich.

 Wartungvertrag Abschluß von verbindlichen Vereinbarungen für den Betrieb und die Wartung der Anwendungen zwischen Projektverantwortlichen und dem Dienstleister.

3 Docker Kubernetes (Webhosting)

Auf der E-Government-Plattform des Freistaates Sachsen wird der Dienst "Docker Kubernetes (Webhosting)" als weitgehende self-service-Lösung für den Betrieb von Webanwendungen angeboten, nachfolgend als Kubernetes-Cluster bezeichnet. Der initiale und fortlaufende Software-Auslieferungsprozess (Deployment) kann damit erheblich beschleunigt und vereinfacht

1 mailto:Christian.Thomas@smekul.sachsen.de

Seite 4 von 9

[Seite 5]

Provisionierung von Apps auf Docker Kubernetes- Dokumentenversion: 7

werden. Um diesen Ansprüchen gerecht zu werden, wurden Vorraussetzungen geschaffen, um einen fortlaufenden Software- Auslieferungs-Prozess (Continuous Delivery) zu implementieren.

Der Kubernets-Cluster wird innerhalb des Sächsischen Verwaltungsnetzwerks (SVN) (https://www.egovernment.sachsen.de/ svn.html) betrieben. Das SVN ist ein separates dedizitiertes Netzwerk für die Behörden des Freistaates Sachsen, in dem besondere Sicherheitsanforderungen gelten. Es ist über einen Proxy-Zugang mit dem Internet verbunden, jedoch gelten auf Grund der besonderen Anforderungen starke Einschränkungen.

Verfügbarkeit von Docker Kubernetes (Webhosting):

4 Fernzugriff

Um den Mitarbeitern des Entwicklungs- und Betriebsdienstleisters Zugang zu verschaffen, müssen diese als externe Mitarbeiter ein Benutzerkonten im Verzeichnisdienst Microsoft Active Directory des Staatsbetrieb Sachsenforst erhalten. Dazu müssen sie namentlich bekannt und belehrt werden. Der verantwortliche Fachbereich (Sachsenforst) legitimiert diese Zugänge. Die Anmeldung am Netzwerk erfolgt mit VPN Cisco AnyConnect und Smart- bzw. Hardware-Token.

Die Beantragung der Benutzerkonten erfolgt durch die zuständige Organisationeinheit beim IT-Servicedesk: SBS.ServiceDesk@smekul.sachsen.de2

 Fernzugriff Beantragung von Benutzerkonten für Mitarbeiter, die auf dem Kubernetes-Cluster arbeiten sollen, erfolgt intern durch den verantwortlichen Fachbereich.

5 Aufbau des Kubernetes-Clusters

Der Kubernetes-Cluster ist wie folgt aufgebaut:

• Betrieb mit Kubernets Server-Version v1.30.5 (https://kubernetes.io/releases/) zum 10.01.2025 • internes Monitoringsystem (Prometheus) • Gitlab für die Verwaltung der Konfigurationsdaten der Deployments • Zentrales Logfile Management (Technologiestack Opendistro-Fluentd-Kibana) • Service Mesh (Istio)

5.1 Vefügbare Tools

• Rancher https://www.rancher.com/

2 mailto:SBS.ServiceDesk@smekul.sachsen.de

Seite 5 von 9

[Seite 6]

Provisionierung von Apps auf Docker Kubernetes- Dokumentenversion: 7

• Harbor https://goharbor.io/ • kubectl CLI (Installation notwendig) • kustomize https://kustomize.io/ (Konfigurationsverwaltung von Kubernetes-Anwendungen) • Argo CD https://argoproj.github.io/cd/

6 Anforderungen an die Docker-Images/ -Container

Für den Betrieb der Docker-Container sind vom Entwicklungsdienstleister Container-Images zu erzeugen. Folgende Anforderungen werden an die Container-Images gestellt:

• Die Container-Images besitzen bei der Übergabe alle zum Betrieb benötigten Komponenten (ein Build der Container- Images vor Ort mittels eines Dockerfiles oder das nächträgliche Hinzufügen von Komponenten zum Container(-Image) aus dem Internet sind nicht möglich). • Die Container-Images müssen das OCI-Format (https://opencontainers.org/) besitzen (Docker-Format). • Die Anwendung im Container muss im user mode betrieben werden, also darf nicht als root-User gestartet werden. (https://kyverno.io/policies/pod-security/restricted/require-run-as-nonroot/require-run-as-nonroot/ https:// kyverno.io/policies/pod-security/restricted/require-run-as-non-root-user/require-run-as-non-root-user/) • Den Containern ist die Änderung von Datei-Attributen mit set-user-ID und set-group-ID verboten. (https://kyverno.io/ policies/pod-security/restricted/disallow-privilege-escalation/disallow-privilege-escalation/) • Die Container-Images werden einer Überprüfung von Schwachstellen (CVE) unterzogen • Parameter und Volumes, die zum Betrieb des Containers benötigt werden, müssen dokumentiert sein. Ebenso die notwendigen Abhängigkeiten der Container untereinander. Idealerweise erfolgt die Dokumentation mittels Kustomize (https://kustomize.io/) oder Kubernetes-Konfigurationsfiles. Textdokumentationen sind ebenfalls möglich.

7 Schwachstellenhandling

Der Schwachstellenscanner Aqua Trivy von Aquasec (https://aquasecurity.github.io/trivy/3) überprüft die bereitgestellten Container-Images auf Schwachstellen (CVE). Sie dürfen dabei keine Schwachstellen aufweisen, die mit dem Schweregrad CRITCAL eingestuft werden und für die aktualisierte Versionen verfügbar sind. Der Scanner kann mit der Option "--ignore- unfixed" ausgeführt werden. Damit werden Sicherheitslücken ignoriert, für die es noch keine Patches gibt.

Die Überprüfung von Schwachstellen von Container-Images, deren Container sich im Betrieb befinden, erfolgt zum Beginn jedes Monats. Ein Report dieses Scans werden dem Staatsbetrieb Sachsenforst und nach einer gesonderten Einrichtung auch dem Entwicklungsdienstleister zugesendet.

 Fixen von Schwachstellen Werden Schwachstellen vom Schweregrad CRITICAL entdeckt, müssen diese in einer Frist von 30 Tagen behoben werden, wenn aktualisierte Version der betreffenden Komponente verfügbar sind.

 Automatische Außerbetriebnahme Werden Schwachstellen vom Schweregrad CRITICAL nicht innerhalb der 30 Tage behoben, obwohl eine aktualiserte Version der betreffenden Komponente verfügbar ist, erfolgt die Außerbetriebnahme der Container.

 Schwachstellenscanner Den Dienstleistern wird empfohlen, einen Schwachstellenscanner in ihre projektbezogene Entwicklungs- und Testumgebung zu integrieren.

3 https://aquasecurity.github.io/trivy/v0.17.2/installation/

Seite 6 von 9

[Seite 7]

Provisionierung von Apps auf Docker Kubernetes- Dokumentenversion: 7

8 Integrationen

Die Anwendungen, die im Kubernetes-Cluster betrieben werden, sind standardmäßig ohne Zugiff auf vorhandene SVN- Komponenten oder das Internet.

 Alle Integrationen sind explizit anzufordern: • Die Erreichbarkeit der Anwendungen aus dem Internet und/ oder Zugriffe in das Internet. • Zugriffe auf SVN-Komponenten (z.B. behördeninterne gemanagte Datenbanken, REST-APIs, Keycloak- Instanz, usw.). • Spezifizierung von Wunschdomains.

 Schwachstellenberichte Eintragung einer Single Point of Contact E-Mail-Adresse des Entwicklungs- und Betriebsdienstleisters (und Wartung) für die von ihm betreuten Anwendungen.

9 Bereitstellungsumgebungen

Für die Abbildung von verschiedenen baugleichen Bereitstellungsumgebungen steht lediglich ein Kuberntes-Cluster zur Verfügung. Deshalb werden verschiedene Bereitstellungsumgebungen über die Namespaces differenziert. Namespaces sind ein Mechanismus zur Isolierung von Ressourcengruppen. Darüber hinaus gilt, dass ein Namespace von einem Team verantwortet werden muss. Deswegen bekommt das Team, welches die Anwendung (die Ressourcen) liefert, einen Namespace zugeordnet, ergänzt um einen Suffixes für die Bereitstellungsumgebung an der Namespacebezeichnung. Die Festlegung der verschiedenen Bereitstellungsumgebungen orientiert sich an dem Zweck, wofür diese verwendet werden sollen. Häufige Anwendungsfälle sind Bereitstellungsumgebungen für:

• die Qualitätssicherung (quality assurance), • die Integration und Abnahme (inspection, langläufig auch kurz als "staging" bezeichnet) und • den Produktivbetrieb (production).

 Bereitstellungsumgebungen Anforderung mindestens einer Bereitstellungsumgebung.

10 Systemvoraussetzungen

Die Anwendungen in den Bereitstellungsumgebungen benötigen spezifische Systemressourcen, die durch das Referat 34 verwaltet werden.

 Systemressourcen/ Vertikale Skalierung Welche Systemressourcen-Anforderungen bestehen für CPU, Arbeitsspeicher und Storage je Bereitstellungsumgebung?

 Horizontale Skalierung Wie oft und in welchem Ausmaß werden die Kubernetes-Workloads vergrößert und verkleinert?

Seite 7 von 9

[Seite 8]

Provisionierung von Apps auf Docker Kubernetes- Dokumentenversion: 7

11 Lieferprozess

Die Übergabe der Anwendungsressourcen erfolgt mittels Continuous Delivery. Dazu wird eine externe Image-Registry (die Registry des Dienstleisters) per Proxy Cache an die Image-Registry der Kubernetes-Clusters (Harbor) angebunden. Dies bietet den Vorteil, dass vom Kubenetes-Cluster direkt auf die Images des Dienstleisters zugegriffen werden kann. Das Referat 34 stellt das Pull Secret zur Verfügung.

 Image-Registry Bereitstellung einer Image-Registry durch den Dienstleister, die über das Internet erreichbar ist.

12 Rollen- und Berechtigungskonzept

12.1 Zugriff mit Berechtigungsnachweis

Für jeden unterstützten Anwendungsfall können unterschiedliche Benutzergruppen ausgeschieden und demzufolge Rollen gebildet werden. Diese Ergebnisse sind in einem Rollen- und Berechtigungskonzept aufzulisten und zu beschreiben. Die zugehörigen Berechtigungen sind ebenfalls in der natürlichen Sprache zu formulieren. Die Rolle bildet eine abgegrenzte Einheit, sozusagen eine Sammlung von spezifischen Einzelberechtigungen, die einerseits in der Anwendung implementiert werden muss, anderersseits ihr Äquivalent im Identity und Accessmanagment (IAM) des Staatsbetriebes Sachsenforst findet. Im IAM werden dazu die notwendigen Berechtigungen erstellt und den Ressourcen zugewiesen.

12.2 Zugriff ohne Berechtigungsnachweis

Auch alle Benutzergruppen, die die Anwendung ohne Authentifizierung verwenden, z.B. für externen Szenarien (Benutzer aus dem Internet), sind Rollen- und Berechtigungskonzept aufzulisten und zu beschreiben.

12.3 Benutzerverwaltung

Die Mitgliedschaft von realen Benutzern zu den jeweiliegen Rollen soll durch den Fachbereich erfolgen (Verfahrens- bzw. Anwendungsbetreuer). Schlussendlich wird durch das Referat 34 das Rollen- und Berechtigungskonzept mit der Ressourcenzuordnung ergänzt. Das Mapping zwischen Anwendung und IAM erfolgt durch den Dienst Keycloak (siehe Gliederungspunkt "Identity- und Accessmanagement").

 Der Softwarebetrieb und die Softwarewartung sind spezifische Anwendungsfälle, welche ebenso im Rollen und Berechtigungskonzept erfasst sein müssen.

 Rollen- und Berechtigungskonzept Erstellung und Lieferung des Rollen- und Berechtigungskonzeptes.

13 Identity- und Accessmanagement

Das führende System für das Identity- und Accessmanagement (IAM) im Staatsbetrieb Sachsenforst ist der SVN-integrierte Verzeichnisdienst Microsoft Active Directory (MSAD). In ihm wird das o.g. Rollen- und Berechtigungssystem umgesetzt. Dem Kubernetes-Cluster wiederum steht ein IAM-Proxy mit der Technologie Keycloak zur Verfügung. Dieser verknüpft die Anwendungen mit der MSAD. Gleichfalls sind damit externe Anwendungsszenarien umsetzbar.

Seite 8 von 9

[Seite 9]

Provisionierung von Apps auf Docker Kubernetes- Dokumentenversion: 7

 Verknüpfung mit dem Identity- und Accessmanagement Das Rollen- und Berechtigungskonzept muss in der Anwendung umgesetzt sein. Die Rollen werden werden an der Keycloak-Instanz registriert und verknüpft.

14 Dokumentation

Mit Lieferung der Anwendungen sind folgende Dokumentationen erforderlich:

 Dokumentationen Lieferung: • der Anwendungsarchitektur (Zweck, Komponenten, Integrationen, Schnittstellen, Lizenzen, ...), • der Deploymentdokumentation und • des Rollen- und Berechtigungskonzept.

Seite 9 von 9