Auf der DevOpsCon Berlin (15. bis 19. Juni 2026) steht erstmals der Workshop "Souveräne IT mit Kubernetes" (Sovereign IT with Kubernetes) auf dem Programm. Er entsteht aus einer Kooperation zwischen der trion GmbH und dem unabhängigen Trainer Erkan Yanar und wird von Thomas Kruse und Erkan Yanar gemeinsam geleitet.

Digitale Souveränität rückt angesichts zunehmender Cyberbedrohungen und der geopolitischen Lage stärker in den Fokus. Wer die Kontrolle über die eigenen Daten und Dienste behalten oder zurückgewinnen will, braucht dafür nicht nur Richtlinien, sondern technische Kontrolle. Der Workshop zeigt, wie sich souveräne IT mit einem hohen Grad an Automatisierung praktisch und sicher auf Basis von Kubernetes umsetzen lässt.

Wenn Systeme miteinander kommunizieren, stellt sich immer die Frage: Wie weist sich ein System gegenüber einem anderen aus? Ein Microservice, der nachts einen Batchjob ausführt, ein CI/CD-System, das Deployments anstößt, oder ein Backend, das im Hintergrund auf eine API zugreift – all diese Szenarien brauchen eine Systemidentität.

Die klassischen Lösungen für dieses Problem – API-Keys, technische Benutzerkonten oder Shared Secrets – haben alle ihre Schwächen. Keycloak bietet mit Service Accounts eine deutlich bessere Alternative, die auf dem bewährten OAuth 2.0 Standard aufbaut.

Container haben den Betrieb von Softwaresystemen seit einigen Jahren modernisiert. Mit Docker, Podman und Kubernetes ist ein effizienter und automatisierter Betrieb möglich, der früher undenkbar war. Doch manchmal stört die Isolation, die Container mit sich bringen:
Was, wenn es gilt, den Inhalt eines Containers zur Laufzeit zu inspizieren und es ist keine Shell installiert?

Die Kubernetes Lernkurve fängt typischerweise mit einem Cluster an.
Das kann ein Minikube, mikrok8s, k3s, der Docker Desktop Kubernetes Cluster oder auch ein Cluster in der Cloud sein.

Ein Kubernetes Cluster kommt jedoch selten allein: Zumindest für Entwicklung und den produktiven Betrieb ist es sinnvoll, mit getrennten Clustern zu arbeiten.

Im Rahmen eines Integrationsprojekts von Kubernetes und Vault (bzw. OpenBao ) sollten Secrets aus Vault in Kubernetes bereitgestellt werden. Dabei sollten die verschiedenen direkten Vault Integrationen durch Infrastruktur in Kubernetes abgelöst werden, und die Vault Secrets als Kubernetes Secrets im Cluster verfügbar gemacht werden, um diese dann als Volume oder Umgebungsvariablen bereitzustellen. Damit soll zum einen das Token-Zero-Problem addressiert werden, also wenn Vault zur Verwaltung von Geheimnissen dient, wie werden die Anwendungen mit einem Geheimnis zur Authentifizierung am Vault versorgt, als auch die individuelle Vault Anbindung der verschiedenen Programmiersprachen und Frameworks.

Vault bietet mit dem Vault Secrets Operator auch direkt eine Integration an, die auf unterschiedliche Weise die Authentifizierung gegenüber Vault umsetzt, als auch für das Mapping der Vault Secrets. Ziel war jedoch nicht nur, ein entsprechendes Setup zu implementieren, sondern eine automatisierte Testbarkeit herzustellen. Dazu wird ein stabiles, reproduzierbares Setup benötigt, um die Kubernetes-Vault-Integration jederzeit in der CI Umgebung frisch herzustellen.

In dem Zuge wurde ein Verfahren benötigt, JWK (JSON Web Keys) im PEM Format bereitzustellen - und das am besten automatisiert durch ein einfaches Shell Script z.B. mit der Bash. Eine Umsetzung auf Basis von Kubernetes OIDC JWKS in PEM formatiertes Material zu erhalten wird im folgenden beschrieben.

Häufig befinden sich die Nutzerdaten (Benutzernamen, Passwörter und Gruppenzugehörigkeiten) von Unternehmen in Active Directory Servern.

Entwickelt man eigene Anwendungen, die diese Benutzerdaten nutzen sollen oder plant man den Einsatz einer Single-Sign-On-Lösung wie Keycloak, so muss man das Active Directory anbinden. Prinzipiell verhält sich ein Active-Directory-Server (AD) wie ein "normaler" LDAP-Server. Man könnte also zur Entwicklung statt eines AD auch einen OpenLDAP-Server oder ein ähnliches leichtgewichtiges Produkt nutzen, das sich einfach als Container in Docker oder Kubernetes betreiben lässt.

Leider hat AD im Gegensatz zu anderen LDAP-Servern ein paar Eigenheiten, die berücksichtigt werden möchten - insbesondere bei der der Durchführung von Entwickler- oder Integrationstests.

Die Absicherung von HTTP Zugriffen mittels TLS (früher SSL) ist spätestens seit den Enthüllungen von Edward Snowden auch für Anwendungen außerhalb von Banken und Medizin zum Standard geworden. Vor allem Dank des kostenlos nutzbaren Let’s Encrypt sind auch die - früher teils horrenden - Kosten kein Grund mehr, auf TLS zu verzichten.
Die meisten Zertifikatanbieter, die das durch Let’s Encrypt eingeführte ACME Protokoll unterstützen, bieten bei Verwendung der DNS Challenge auch Wildcard Zertifikate an. Wird für einen Kubernetes Cluster primär mit Hostnamen in einer Domain oder Subdomain gearbeitet, so bietet sich ein Wildcard Zertifikat entsprechend an. Damit kann unter Umständen sogar der Einsatz des häufig zusätzlich zur Ingress Implementierung betriebenen Cert Manager entfallen: Dazu würde das Wildcard-Zertifikat als Default TLS Zertifikat im Ingress Controller konfiguriert werden/

Wie das funktioniert, wird im folgenden Beitrag beschrieben.

In modernen Authentifizierungs- und Autorisierungsmechanismen spielen Access-Tokens eine zentrale Rolle. Sie ermöglichen es Clients, im Namen eines Benutzers auf geschützte Ressourcen zuzugreifen, ohne eine Session zu benötigen oder ständig Zugangsdaten übertragen zu müssen.

Doch was passiert, wenn ein Access-Token in die falschen Hände gerät? Die Konsequenzen können verheerend sein: Identitätsdiebstahl, Datenexfiltration und unautorisierter Zugriff auf sensible Systeme.

In einem vorherigen Artikel haben wir uns damit befasst, wie man Keycloak Rollen als Spring Security Authorities verfügbar macht, wenn Spring Boot als Resource Server agiert. In diesem Folgebeitrag betrachten wir nun den Fall, in dem unsere Spring Boot Anwendung die Rolle eines OAuth 2.0 Client einnimmt und einen OAuth 2.0 Login mit Keycloak implementiert. Auch hier wollen wir die Rollen aus Keycloak korrekt mappen.