diff --git a/Praxisbericht.tex b/Praxisbericht.tex
index 1d745ae..53944cd 100644
--- a/Praxisbericht.tex
+++ b/Praxisbericht.tex
@@ -231,7 +231,13 @@ Um eine sichere Verbindung zu gewährleisten, nutzen wir TLS. TLS garantiert die
 
 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{External Secrets Operator}
 
+Während Helm und FluxCD für ein einfaches Deployment sorgen, und cert-manager die Zertifikate für Kommunikationsverschlüsselung verwaltet, ist immernoch ein manueller Teil auf dem Cluster zu konfigurieren: Secrets. Secrets sollen aus Sicherheitsgründen nicht im Klartext gespeichert werden, wofür verschiedene Lösungen existieren. Eine beliebte Lösung sind Secret-Manager wie \textit{Vault}, welche Secrets verschlüsselt an einer zentralen Zugriffsstelle speichern. Die Aufgabe des Transports aus dem Secret-Manager in das Cluster übernimmt der \textit{External Secrets Operator}\cite{passESO} (kurz ESO), welcher beliebige Secret-Stores, unter anderem Vault, anbindet. ESO ist dabei weitestgehend anbieteragnostisch, und erlaubt es auch nicht offiziell unterstützte Secret-Manager mit einer selbstdefinierten Integration anzubinden, wodurch der psb-interne Passwortmanager ebenfalls integriert werden kann. In den Helm-Charts bleiben somit Referenzen auf nicht-definierte Kubernetes-Secrets, in Git-Repositories bleiben External-Secret-Definitionen welche Referenzen von Secrets im Secret-Manager auf zu erstellende Kubernetes-Secrets beinhalten, und im Secret-Manager liegen die wirklichen Daten. Vorteilhaft ist der Fakt, dass weder in Helm noch in Git Secrets abgelegen werden, und alle genutzten Secrets an einer zentralen Anlaufstelle auffindbar sind. Im Fall, dass Passwörter ausgewechselt werden müssen, ist die Änderung an einer zentralen Stelle zu bewältigen. Falls Kunden Passwörter selbst verwalten möchten, ist eine Anbindung an den Kundeneigenen Secret-Manager möglich.
+
+%\subsection{Spegel}
+%\subsection{Registry}
+%\subsection{Talos}
 
 \subsection{Airgap-Installation}