Uni/praxisbericht
2
0
Fork 0
Code Issues Activity

Observability

Browse Source
This commit is contained in:
Tim Wall
2026-06-19 11:04:12 +02:00
parent afcb24fda1
commit 57364867cb
1 changed files with 6 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Praxisbericht.tex
View File

@@ -227,6 +227,12 @@ Mit der Kombination aus Longhorn und CNPG können somit alle Stateful Workloads
Um eine sichere Verbindung zu gewährleisten, nutzen wir TLS. TLS garantiert die Verschlüsselung des Nachrichtenaustausch sowie die Identität des Gegenübers mithilfe von Zertifikaten. Um den möglichen Schaden bei Zertifikatdiebstahl oder Sicherheitslücken zu minimieren, sollen Zertifikate ein möglichst kurzes Ablaufdatum besitzen. Das Browser-Forum empfielt einen Zeitraum von 1.5 Monaten für öffentliche Server-Zertifikate\cite{cabforum47}, wobei das Zertifikat innerhalb des ersten Monats automatisch rotiert (ausgewechselt) wird, und Menschen im Falle eines Fehlers trotzdessen noch einen halben Monat haben um zu reagieren. Während unser Anwendungsfall kein öffentliches Zertifikat abbildet, sind 47 Tage ein guter Richtwert. Für TLS-Verschlüsselungen zwischen Microservices wird oft ein Zeitraum von nur 7 Tagen\cite{certTLSPKI} oder weniger empfohlen. Um diesen Richtwert bequem einzuhalten ist die zuvor genannte Automatisierung für Zertifikatsverwaltung notwendig, welche \textit{cert-manager}\cite{certManager} übernimmt. Cert-manager bildet einen Kubernetes Operator, welcher Zertifikate von einer Ansammlung an Zertifikat-Ausstellern anfragen und an Nutzer innerhalb des Kubernetes-Clusters verteilen kann. Aussteller die für unsere Umgebungen infrage kommen sind das \textit{Automated Certificate Management Environment}, kurz ACME, sofern die Kundenfirma einen eigenen Aussteller bereistellt. Mithilfe von ACME lassen sich Zertifikate für Domains oder öffentliche IP-Addressen automatisch anfragen. Im Falle, dass Kunden keine ACME-Infrastruktur bereitstellen, bieten sich von cert-manager verwaltete Selbstsignierte Verschlüsselungen an. Der Operator von cert-manager kann dabei die Zertifikate signieren oder signieren lassen und in \textit{Secrets} speichern. Secrets sind ein Datentyp von Kubernetes, in welchem Daten verschlüsselt gespeichert werden. Diese Secrets können dann von jeglichen Kubernetes-Komponenten benutzt werden. Besonders Bedienerfreundlich ist das Nutzen von cert-manager-\textit{Annotationen} auf Gateways, womit das Zertifikat mithilfe der in der Komponente existierenden Informationen automatisch erstellt und verwaltet wird. Annotationen sind dabei ein Kubernetes-nativer Weg, beliebige Informationen an einer Komponente festzuhalten. Sofern ein cert-manager Aussteller mit den Namen \texttt{aussteller} existiert, muss eine Gateway-Komponente nur mit der Annotation \verb+cert-manager.io/issuer: "austeller"+ markiert werden, wodurch der cert-manager Operator erkennt dass diese Resource ein Zertifikat benötigt. Um eine sichere Verbindung zu gewährleisten, nutzen wir TLS. TLS garantiert die Verschlüsselung des Nachrichtenaustausch sowie die Identität des Gegenübers mithilfe von Zertifikaten. Um den möglichen Schaden bei Zertifikatdiebstahl oder Sicherheitslücken zu minimieren, sollen Zertifikate ein möglichst kurzes Ablaufdatum besitzen. Das Browser-Forum empfielt einen Zeitraum von 1.5 Monaten für öffentliche Server-Zertifikate\cite{cabforum47}, wobei das Zertifikat innerhalb des ersten Monats automatisch rotiert (ausgewechselt) wird, und Menschen im Falle eines Fehlers trotzdessen noch einen halben Monat haben um zu reagieren. Während unser Anwendungsfall kein öffentliches Zertifikat abbildet, sind 47 Tage ein guter Richtwert. Für TLS-Verschlüsselungen zwischen Microservices wird oft ein Zeitraum von nur 7 Tagen\cite{certTLSPKI} oder weniger empfohlen. Um diesen Richtwert bequem einzuhalten ist die zuvor genannte Automatisierung für Zertifikatsverwaltung notwendig, welche \textit{cert-manager}\cite{certManager} übernimmt. Cert-manager bildet einen Kubernetes Operator, welcher Zertifikate von einer Ansammlung an Zertifikat-Ausstellern anfragen und an Nutzer innerhalb des Kubernetes-Clusters verteilen kann. Aussteller die für unsere Umgebungen infrage kommen sind das \textit{Automated Certificate Management Environment}, kurz ACME, sofern die Kundenfirma einen eigenen Aussteller bereistellt. Mithilfe von ACME lassen sich Zertifikate für Domains oder öffentliche IP-Addressen automatisch anfragen. Im Falle, dass Kunden keine ACME-Infrastruktur bereitstellen, bieten sich von cert-manager verwaltete Selbstsignierte Verschlüsselungen an. Der Operator von cert-manager kann dabei die Zertifikate signieren oder signieren lassen und in \textit{Secrets} speichern. Secrets sind ein Datentyp von Kubernetes, in welchem Daten verschlüsselt gespeichert werden. Diese Secrets können dann von jeglichen Kubernetes-Komponenten benutzt werden. Besonders Bedienerfreundlich ist das Nutzen von cert-manager-\textit{Annotationen} auf Gateways, womit das Zertifikat mithilfe der in der Komponente existierenden Informationen automatisch erstellt und verwaltet wird. Annotationen sind dabei ein Kubernetes-nativer Weg, beliebige Informationen an einer Komponente festzuhalten. Sofern ein cert-manager Aussteller mit den Namen \texttt{aussteller} existiert, muss eine Gateway-Komponente nur mit der Annotation \verb+cert-manager.io/issuer: "austeller"+ markiert werden, wodurch der cert-manager Operator erkennt dass diese Resource ein Zertifikat benötigt.
\subsection{Observability}
Neben Graylog nutzt selektron verschiedene Werkzeuge, um Fehler besser nachvollziehen zu können. \textit{Prometheus} sammelt dabei laufend Messwerte aus dem System, zum Beispiel wie stark Server ausgelastet sind oder wie schnell Anfragen verarbeitet werden. Damit diese Daten nicht verloren gehen, werden sie in \textit{Mimir} gespeichert. \textit{Grafana} visualisiert die gespeicherten Informationen in nutzerdefinierten Diagrammen, sodass Entwicklungen und Auffälligkeiten erkennbar sind. \textit{Alertmanager} sendet Warnmeldungen an den Support und Entwickler, sofern Werte außer der Norm auftreten. Dazu kommt \textit{Tempo}, das sogenannte \textit{Traces} sammelt. Traces zeigen, welchen Weg eine Anfrage durch das System nimmt und an welcher Stelle es zu Problemen kommt. Ergänzt wird die Datenerhebund durch \textit{node-exporter} und \textit{Telegraf}, die zusätzliche Daten direkt von Servern und Anwendungen liefern. Neu ist \textit{kube-state-metrics}, welches Informationen bezüglich Kubernetes in das existierende Metrikerhebungs-Ökosystem integriert. Alle der Komponenten werden mithilfe von 3 Helm-Charts ausgeliefert. Zusammen erlauben die Werkzeuge für eine schnelle Fehlerfindung um Systeme langfristig stabil zu betreiben.
\subsection{Airgap-Installation} \subsection{Airgap-Installation}
Viele der Kunden haben strikte IT-Infrastrukturregeln, in welchem Zugang in das Internet stark beschränkt bis komplett deaktiviert ist. Dafür ist es notwendig, dass das komplette System ohne Internet aufgesetzt werden kann. Da Kubernetes eine Cloud-Native Lösung ist, stehen Probleme wie dieses nicht auf der Prioritätsliste der Kernentwickler, jedoch gibt es trotzdem Lösungen dafür. Diese fallen jedoch außerhalb des Zeitrahmens der Praxisphase und werden in der auf der Praxisphase aufbauenden Bachelorarbeit abgehandelt. Viele der Kunden haben strikte IT-Infrastrukturregeln, in welchem Zugang in das Internet stark beschränkt bis komplett deaktiviert ist. Dafür ist es notwendig, dass das komplette System ohne Internet aufgesetzt werden kann. Da Kubernetes eine Cloud-Native Lösung ist, stehen Probleme wie dieses nicht auf der Prioritätsliste der Kernentwickler, jedoch gibt es trotzdem Lösungen dafür. Diese fallen jedoch außerhalb des Zeitrahmens der Praxisphase und werden in der auf der Praxisphase aufbauenden Bachelorarbeit abgehandelt.