Im heutigen Software-Entwicklungsalltag ist Security ein entscheidendes Thema. Moderne Java-Anwendungen bestehen zu einem erheblichen Teil aus Fremdbibliotheken. Diese sollten regelmäßig auf den neusten Stand gebracht werden, auch um möglichen Sicherheitslücken entgegenzuwirken.

Wie im Vorgängerartikel Build-Warnungen bei Dependency-Updates beschrieben, machen externe Abhängigkeiten oft über 90% des Codes in Microservices aus. Neben der Aktualität der Bibliotheken ist es besonders wichtig, bekannte Sicherheitslücken (CVEs) zu erkennen und rechtzeitig Gegenmaßnahmen einzuleiten.

Das OWASP Dependency-Check-Maven-Plugin bietet eine praktische Lösung, um aus dem Build-Prozess heraus auf mögliche Sicherheitslücken in Abhängigkeiten aufmerksam zu machen. Im Folgenden stelle ich vor, wie sich das Plugin in eine Spring-Boot-Anwendung sowie eine GitLab CI-Pipeline integrieren lässt.

Micronaut ist ein modernes Java Framework, das speziell mit der Anforderung entwickelt wurde, den Einsatz von Reflection zu minimieren.
Dazu wird unter anderem Code Generierung zur Build Zeit verwendet. Micronaut kann mit Maven als auch Gradle als Buildsystem gut verwendet werden. Mit IntelliJ IDEA gibt es jedoch einiges zu beachten, sonst kann es zu schwer diagnostizierbaren Fehlern kommen.

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.

Gerade für Experimente und zur Entwicklung bietet sich ein lokaler Kubernetes Cluster an. Zur einfachen Umsetzung gibt es diverse Optionen wie Minikube, KinD oder auch k3s. Auch wir setzen in unseren Kubernetes Schulungen gerne auf ein Cluster Setup, dass durch die Teilnehmer mit geringem Aufwand auf dem eigenen System verwendet werden kann, um auch nach der Schulung eigenständig weiter zu lernen und Übungen nachzuvollziehen.

Wie geht man jedoch bei so einem Setup mit dem Thema TLS Zertifikaten um?
Umgehen ist nicht immer ein praktikabler Weg: Manche Browser APIs, wie zum Beispiel der Zugriff auf die Webcam erfordern schlicht den Einsatz von TLS.

Speziell für diesen Anwendungsfall bietet traefik.me eine Domain, Wildcard-DNS Service und ein durch Let’s Encrypt validiertes Zertifikat an. Dieser Beitrag zeigt die Verwendung von traefik.me in Kombination mit Kubernetes.

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 diesem kurzen Blog-Post beschreibe ich zwei Varianten, wie unterschiedliche Timeouts je RestClient konfiguriert werden können.

Kubernetes eignet sich hervorragend auch für kleine Setups, z.B. in einem Homelab, und auch bei begrenzten Hardwareressourcen. Dafür gibt es beispielsweise besonders schlanke Distributionen wie k3s.
Der immense Vorteil von Kubernetes liegt in den bereitgestellten APIs und der sehr einfachen Möglichkeit, alle Konfigurationen deklarativ zu verwalten.

Um Kubernetes als gute Plattform auch für Homelab Anwendungen zu demonstrieren geht es in diesem Beitrag darum, wie der Werbeblocker Pi-Hole auf Kubernetes betrieben werden könnte.

Zur Abbildung eines speziellen Freigabeprozesses von Dokumentvorlagen und Textbausteinen entstand der Wunsch, manuell zu selektieren, welche Dateien von einer Entwicklungsstage in die nächste transportiert werden.
Als System zur Versionskontrolle sollte das bisher genutzte Subversion (SVN) durch git abgelöst werden.

Wir haben uns dazu zwei Varianten im Kontext des git Versionskontrollsystems überlegt und stellen diese im folgenden vor.
Im Fazit wird schließlich betrachtet, wie eine gänzlich alternative Herangehensweise aussehen könnte.