Bitnami Secure Images: Risiken für Keycloak-Nutzer und sichere Alternativen

Bitnami hat die Bereitstellung seiner Container-Images – darunter das beliebte Keycloak Image – auf ein weitgehend kostenpflichtiges Modell umgestellt. Für bisherige Nutzer der kostenlosen, gepflegten Bitnami-Images bedeutet dies gravierende Veränderungen. Insbesondere Keycloak-Anwender sehen sich nun mit erheblichen Sicherheits- und Betriebsrisiken konfrontiert, wenn sie weiterhin alte Legacy-Images nutzen. Im Folgenden beleuchten wir die zentralen Risiken und zeigen strategische Alternativen auf, wie z. B. Keycloak as a Service oder ein Secured Keycloak Image, um Sicherheit und Betrieb weiterhin zu gewährleisten.

Risiken und Nachteile der Bitnami-Umstellung

1. Sicherheitslücken durch Legacy-Images

Bitnami teilt seine Images nun in zwei Repositorien auf: aktuelle, gepatchte Images gibt es nur noch im kostenpflichtigen Katalog, während das kostenlose Legacy-Repository eingefroren wurde. Alle älteren Keycloak-Versionen sind in dieses Legacy-Repository gewandert – und erhalten keine Sicherheitsupdates mehr.

Für eine sicherheitskritische Anwendung wie Keycloak (Identity & Access Management) ist das fatal. Bekannte Schwachstellen (CVEs) im Keycloak-Server oder dessen Basis (z. B. Java, OS) bleiben ungepatcht. Die Folge: Ein Keycloak-Server auf einem Legacy-Image läuft eventuell mit offenen Sicherheitslücken, was ein hohes Risiko von Angriffen, Ausfällen oder Datenkompromittierung bedeutet.

Ebenso problematisch sind die Compliance-Auswirkungen: Der Betrieb von Software mit bekannten, ungepatchten Schwachstellen verstößt gegen gängige Sicherheitsstandards (z. B. ISO 27001) und Audit-Anforderungen. Compliance-Verletzungen und Prüfungsprobleme drohen, wenn Unternehmen weiterhin unsichere Container-Images verwenden. Kurz gesagt: Das Sicherheitsniveau eines ungepatchten Keycloak-Servers sinkt drastisch, gepaart mit erheblichen Audit-Risiken. Der Betrieb eines Keycloak-Servers mit einem Legacy-Image in Produktion ist daher praktisch ein No-Go.

2. Betriebs- und Stabilitätsrisiken (CI/CD-Probleme)

Neben Sicherheitsaspekten treten unmittelbar operative Probleme auf. Viele Deployments referenzieren in ihren Kubernetes-Helm Charts oder CI/CD-Pipelines fest definierte Image-Versionen – z. B. bitnami/keycloak:25.0.0. Durch die Repository-Änderung schlagen solche Deployments nun fehl oder ziehen ungewollt alte Images. Mit anderen Worten: Automatisierte Builds und Updates brechen plötzlich ab, weil das referenzierte Image nicht mehr unter dem erwarteten Pfad verfügbar ist. Im schlimmsten Fall führt dies zu Dienstunterbrechungen – etwa ein fehlgeschlagenes Keycloak-Update kann den Identity Provider lahmlegen, sodass sich Benutzer nicht mehr bei angeschlossenen Anwendungen anmelden können.

Bitnami bietet in der kostenlosen Variante oft nur einen :latest Tag anstelle versionierter Images. Doch die Nutzung von :latest in Produktion ist ein bekanntes Anti-Pattern: Die Version kann sich unvorhergesehen ändern, was Reproduzierbarkeit und Stabilität erschwert. Man verliert die Kontrolle über genaue Versionsstände, was Rollbacks oder konsistente Tests beinahe unmöglich macht.

Zwar gibt es eine kurzfristige Notlösung: In Helm Charts kann man den Image-Pfad manuell von docker.io/bitnami/keycloak auf docker.io/bitnamilegacy/keycloak ändern, um zumindest wieder ein Image zu azitziehen. Dies behebt aber nur den unmittelbaren Fehler beim Image Pull – das Kernproblem bleibt: Man betreibt weiterhin ein veraltetes, unsicheres Image.

Unterm Strich entstehen also Betriebsrisiken auf zwei Ebenen:

Aktuelle Updates werden erschwert oder verhindert, was zu möglichen Downtimes führen kann.
Zukünftige Deployments erfordern Workarounds (Legacy-Pfad verwenden, etc.), die aber keine nachhaltige Lösung darstellen und Best Practices zuwiderlaufen.

3. Hoher Eigenaufwand und Kosten für Alternativen

Organisationen, die das Bitnami-Abo meiden möchten, stehen vor dem Zwang zur Migration. In der Praxis gibt es zwei Hauptpfade: (a) Wechsel zu alternativen Images – etwa das offizielle Keycloak-Image/Operator oder Community-gepflegte Helm-Charts – oder (b) Eigenes Bauen und Pflegen eines Keycloak-Container-Images. Beide Ansätze sind jedoch mit erheblichem Aufwand verbunden.

Migration zu Alternativen: Der Umstieg z. B. auf den offiziellen Keycloak Operator erfordert ein stark geändertes Setup. Der Operator funktioniert anders als das bisherige Helm-Chart, sodass Konzeptanpassungen und Kubernetes-Know-how nötig sind. Auch alternative Community-Helmcharts müssen zunächst evaluiert und an die eigene Umgebung angepasst werden. All dies bedeutet hohe initiale Migrationsarbeit – von der Anpassung der CI/CD-Pipeline bis zum Regressions-Testing der neuen Deployment-Methode.

Eigenwartung des Images: Der andere Weg ist, Keycloak auf eigener Faust aktuell zu halten. Dabei übernimmt das Unternehmen selbst die Rolle, die zuvor Bitnami gespielt hat – mit allem, was dazu gehört:

Kontinuierliches CVE-Scanning: Regelmäßig (z. B. wöchentlich) alle eingesetzten Container-Images auf neue Schwachstellen prüfen (Tools wie Trivy oder Grype einsetzen).

Patches backporten: Tritt eine kritische Lücke z. B. in der Basis (etwa der Linux-Bibliothek glibc) auf, muss man ein eigenes Update ins veraltete Image einpflegen. Das heißt, ein angepasstes Dockerfile schreiben und ein neues Image bauen, das den Fix enthält.

Grundsystem aktuell halten: Auch die Java-Laufzeitumgebung und weitere Abhängigkeiten von Keycloak brauchen permanente Pflege, um Sicherheitsupdates zu erhalten.

Intensives Testing: Jedes selbst gebaute Image muss ausführlich getestet werden, um sicherzustellen, dass eigene Änderungen keine Seiteneffekte oder Fehler in Keycloak verursachen.

Dieser Engineering-Aufwand ist enorm und er bleibt dauerhaft bestehen. Unternehmen ohne dediziertes Security-Engineering-Team stoßen hier schnell an Grenzen. Das Betriebsrisiko steigt ebenfalls, da Fehler beim manuellen Patchen oder Testen zu Instabilitäten führen können.

Zudem war der Wechsel auf eine “selbst gepflegte” Keycloak-Installation genau das Szenario, das Bitnami-Nutzer ursprünglich vermeiden wollten. Man wird vom passiven Konsumenten eines gepflegten Images zum aktiven Verwalter der Containersicherheit – eine Rolle, die viele weder geplant noch eingepreist hatten. Die Kosten für die nötige Entwicklerzeit und erhöhte Fehleranfälligkeit können dabei schnell jede Ersparnis übersteigen. Nicht umsonst liegen kommerzielle Angebote wie Bitnami Secure Images preislich im fünfstelligen Dollarbereich pro Jahr, was für kleinere Unternehmen eine große, ungeplante Budgetbelastung darstellt (entweder direkt als Abo-Kosten oder indirekt als interne Personalressourcen).

Ohne professionelle Updates bleibt nur die Professionalisierung der eigenen Software-Supply-Chain – ein teures Unterfangen – oder der Umstieg auf eine Lösung mit Sicherheitsunterstützung. Angesichts der kritischen Bedeutung von Identity-Systemen ist klar: In den meisten Fällen lohnt es sich nicht, die Bitnami-Änderung allein stemmen zu wollen.

Strategische Alternativen: Keycloak sicher betreiben ohne Mehraufwand

Wie lassen sich die genannten Risiken umgehen? Zum Glück gibt es Auswege: Anstatt in Eigenregie Patches hinterherzujagen oder ein teures Abo einzugehen, kann man auf professionell gemanagte Lösungen setzen. Zwei Ansätze bieten sich an, je nach Bedarf des Unternehmens:

Keycloak as a Service – eine voll gemanagte Keycloak-Instanz, betrieben von einem spezialisierten Dienstleister (wie intension).

Keycloak Secured Image – ein von Experten gehärtetes und laufend aktualisiertes Keycloak-Containerimage, das im eigenen Umfeld betrieben wird.

Diese Alternativen nehmen den Update- und Wartungsaufwand dem Kunden ab und dieser muss sicht nicht selbst um das CVE-Management kümmern. Im Folgenden schauen wir uns die Vorteile dieser Ansätze an.

Keycloak as a Service – Managed Service statt Eigenbetrieb

Keycloak as a Service (KCaaS) bedeutet, dass eine komplette Keycloak-Umgebung als Managed Service bereitgestellt wird. Dein Unternehmen nutzt Keycloak, ohne sich um Installation, Updates oder den operativen Betrieb kümmern zu müssen. Ein Anbieter wie intension übernimmt die Verantwortung für Sicherheit und Verfügbarkeit der Keycloak-Instanz.

Wichtigste Vorteile auf einen Blick:

Laufende Sicherheits-Patches: Die Keycloak-Server werden vom Anbieter kontinuierlich mit Patches versorgt – sowohl für Keycloak selbst als auch für das zugrundeliegende System. Sicherheitslücken werden geschlossen, sobald Updates verfügbar sind, ohne dass du eingreifen musst. Dadurch gibt es keine ungepatchten CVEs mehr in deiner Umgebung.

Stabile, aktuelle Umgebung: Der Service stellt sicher, dass Keycloak immer auf einem unterstützten, aktuellen Versionsstand läuft. Trotzdem werden Updates kontrolliert und planbar eingespielt, um die Stabilität zu gewährleisten – kein Chaos durch plötzlich wechselnde :latest-Images.

Weniger Betriebsaufwand: Dein Team wird entlastet. Weder müssen eigene CI/CD-Pipelines für Keycloak gepflegt, noch Images gebaut oder Logs auf Sicherheitsvorfälle analysiert werden. Der Wartungsaufwand sinkt gegen Null, sodass sich Entwickler auf Kernaufgaben konzentrieren können.

Compliance & Support: Ein professioneller KaaS-Anbieter sorgt dafür, dass die Keycloak-Instanz Compliance-konform betrieben wird (Stichwort ISO-Zertifizierungen, Datenschutz, etc.). Zudem stehen Support und Expertenwissen bereit, etwa 24/7-Monitoring oder SLAs, die interne Teams so oft nicht abbilden können.

Hohe Verfügbarkeit: Durch den Betrieb auf einer robusten, skalierbaren Infrastruktur (z. B. Multi-Node-Kubernetes, verteilte Zonen) wird eine ausfallsichere Keycloak-Umgebung gewährleistet. Selbst Lastspitzen oder Hardwareausfälle werden vom Service abgefangen, meist ohne Downtime – etwas, das im Eigenbetrieb viel Aufwand erfordert.

Mit Keycloak as a Service wählt man also einen strategischen Ansatz: anstatt sich um jedes Security-Detail zu sorgen, überlässt man die Plattform erfahrenen IAM-Experten. Für Unternehmen, die Keycloak intensiv nutzen, aber ihre Ressourcen nicht auf Container-Security verwenden möchten, ist das eine attraktive Option.

Keycloak Secured Image – Sicherheit für den Eigenbetrieb

Manche Organisationen möchten oder müssen Keycloak weiterhin im eigenen Rechenzentrum/Cluster betreiben – sei es aus regulatorischen Gründen oder wegen spezieller Integrationen. Auch für diesen Fall gibt es eine Lösung: das Keycloak Secured Image (z. B. angeboten von intension).

Dieses Modell liefert ein härtetes, sicheres Container-Image von Keycloak, das regelmäßig aktualisiert wird. Das Image wird vom Anbieter kontinuierlich gepflegt, analog zum Bitnami-Subscription-Modell – jedoch ohne dass man das vollständige Bitnami-Paket erwerben muss.

Merkmale und Vorteile des Secured Image:

Regelmäßige Security-Updates: Für alle unterstützten Keycloak-Versionen werden sogenannte Micro-Release-Updates bereitgestellt, sobald kritische Sicherheitsfixes verfügbar sind. Das bedeutet, selbst wenn du eine bestimmte Version (z. B. Keycloak 26.0.x) einsetzen möchtest, bekommst du vom Anbieter zeitnah ein aktualisiertes Image mit den neuesten Patches. Sicherheitslücken werden so geschlossen, bevor sie Schaden anrichten. Die Sicherheitswartung umfasst dabei auch den Host-Stack des Containers (Betriebssystem, Java etc.) – nicht nur Keycloak selbst.

Längere Support-Zyklen: Im Gegensatz zum reinen Open-Source-Upstream, der Patches oft nur in neuere Versionen ausliefert, garantiert ein Secured Image eine gewisse Unterstützungsdauer für jede Major/Minor-Version. Beispielsweise werden ausgewählte Keycloak-Versionen noch Monate oder bis zur übernächsten Version mit Updates versorgt. Damit kannst du relativ stabile Versionen betreiben, ohne sofort auf jedes neue Release springen zu müssen – und bleibst trotzdem sicher.

Einfache Integration: Das Secured Image wird per Container-Registry zur Verfügung gestellt und kann nahtlos in deine bestehende CI/CD-Pipeline eingebunden werden. Anstatt in Eigenregie Dockerfiles zu pflegen, ziehst du einfach das vom Anbieter bereitgestellte Image – inklusive aller Patches. So minimierst du Änderungen an deiner Infrastruktur.

Support und Expertise: Nutzt du ein kommerziell bezogenes Keycloak-Image, steht dir in der Regel auch Support bei Problemen zur Seite. Bei intension zum Beispiel erhältst du Hilfe, falls es Fragen oder Incidents mit dem Image gibt, und profitierst von der Erfahrung der Entwickler, die die Images bauen.

Keine Kompromisse bei Kontrolle: Du behältst deine Keycloak-Installation in der eigenen Umgebung unter voller Kontrolle – nur die Image-Pflege läuft extern. Das ist ideal, wenn interne Richtlinien eine Inhouse-Betriebsweise verlangen, du aber dennoch den Komfort von gewährleisteter Sicherheit nutzen möchtest.

Mit einem solchen Secured Image umgehst du das Risiko, auf unsicheren Legacy-Ständen zu laufen, ohne gleich den ganzen Betrieb aus der Hand geben zu müssen. Es stellt einen Mittelweg dar, der Sicherheit und Unabhängigkeit verbindet.

Vergleich: Selbst hosten (Legacy) vs. Managed/gesichertes Keycloak

Zum Abschluss fassen wir die Risiken der Legacy-Nutzung und die Vorteile einer professionellen Lösung noch einmal gegenüberstellend zusammen:

Risiko bei Legacy-Images (Eigenbetrieb)	Vorteil mit Managed Service oder Secured Image
Offene Sicherheitslücken: Keine neuen Updates, bekannte CVEs bleiben bestehen Analyse zu Bitnami	Kontinuierliche Patches: Anbieter liefert zeitnahe Sicherheitsupdates, keine offenen CVEs im System.
Compliance-Verstöße: Betrieb mit ungepatchter Software gefährdet Audit- und Sicherheitsstandards	Compliance sichergestellt: Durch aktuelle Software und Nachweise (z. B. ISO-Zertifizierung/SBOM) ist der Betrieb regelkonform und auditierbar.
Instabile Deployments: Pipeline-Fehler oder Downtime durch fehlende/alte Images	Zuverlässiger Betrieb: Immer verfügbare, getestete Images/Services sorgen für reibungslose Updates und hohe Verfügbarkeit.
Hoher Wartungsaufwand: Ständiges eigenes Scanning, Patchen (Backports) und Testen erforderlich	Minimaler Aufwand: Wartungsarbeiten übernimmt ein spezialisiertes Team – kein eigenes Patch-Management nötig.
Ungeplante Kosten: Entweder teures Abo oder erheblicher interner Ressourcenaufwand erforderlich	Planbare Kosten: Kalkulierbares Preismodell für Service/Support; interne Ressourcen werden geschont und können produktiver eingesetzt werden.

Tabelle: Unsichere Legacy-Nutzung vs. professionell gemanagte Keycloak-Lösungen

Fazit: Sicherheit und Entlastung durch moderne Keycloak-Services

Die Umstellung auf Bitnami Secure Images hat deutlich gemacht, wie kritisch das Thema Security Maintenance für Keycloak-Installationen ist. Wer auf kostenlose Legacy-Images setzt, geht ein hohes Risiko in Kauf – technisch wie organisatorisch. Doch Unternehmen haben eine Wahl: Anstatt selbst zum „Patch-Day-Helden“ werden zu müssen, kann man auf professionelle Keycloak-Angebote zurückgreifen.

Keycloak as a Service bietet einen umfassenden Rundum-Service, der Sicherheit, Updates und Betrieb garantiert, ohne dass dein Team Zeit in Infrastruktur investieren muss. Alternativ stellt ein Keycloak Secured Image sicher, dass du deine Keycloak-Server weiterhin inhouse betreiben kannst, aber dabei stets ein aktuelles, sicheres Fundament unter dir hast. Beide Wege helfen, die Balance zwischen Security und Aufwand zu meistern.

Letztlich gilt: Eine zentrale IAM-Lösung wie Keycloak sollte kein unkalkulierbares Risiko darstellen. Mit den richtigen Maßnahmen – sei es ein Wechsel des Betriebsmodells oder der Bezug gehärteter Images – bleibst du auf der sicheren Seite und kannst dich auf das Wesentliche konzentrieren: deine Anwendungen und Nutzer. Sprich uns gerne an, wenn du mehr über einen sicheren Keycloak-Betrieb erfahren möchtest – wir unterstützen dich dabei, die optimale Lösung für dein Unternehmen zu finden.