Uni/praxisbericht
2
0
Fork 0
Code Issues Activity

cert-manager

Browse Source
This commit is contained in:
Tim Wall
2026-06-19 09:19:15 +02:00
parent 09ff2e6f18
commit afcb24fda1
2 changed files with 34 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
Praxisbericht.tex
View File

@@ -222,6 +222,10 @@ Viele der Kunden sind an zunehmend an Ausfallsicherheit interessiert. Sofern ein
Mit der Kombination aus Longhorn und CNPG können somit alle Stateful Workloads von selektron Highly-Available gemacht werden, um Ausfälle der Produktion zu vermeiden.
\subsection{Cert-Manager}
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{Airgap-Installation}