TL;DR: Zertifikate, Schlüssel und Secrets benötigen Lifecycle-Management – und die Plattform dafür sollte nicht zu einem eigenen Betriebsprojekt werden. Der aktualisierte ILM-Operator reduziert den Betrieb von ILM auf zwei deklarierte Kubernetes-Ressourcen: Platform und Connector. Ihr Aufwand fließt in die Governance kryptografischer Assets, nicht in die Wartung der Infrastruktur.
Die schwierige Aufgabe beim Trust Lifecycle Management war nie die Entscheidung, es einzuführen. Die Herausforderung bestand darin, die dafür nötige Plattform bereitzustellen und zu betreiben. Diese Hürde ist jetzt deutlich niedriger.
Betrachten Sie, wo Ihre kryptografischen Assets heute liegen. Zertifikate terminieren TLS in jedem Namespace. Schlüssel liegen in HSMs und Cloud-Key-Stores. Secrets verteilen sich über HashiCorp Vault und Kubernetes. Jedes davon hat ein Ablaufdatum, einen Verantwortlichen und eine Richtlinie, der es folgen sollte. Da abgelaufene Zertifikate auch 2026 noch Ausfälle verursachen, wissen die meisten Teams bereits, dass Tabellen und Kalendererinnerungen nicht skalieren.
Trust Lifecycle Management ist die Antwort auf diesen Wildwuchs. ILM, die Open-Source-Plattform für Identity Lifecycle Management, dient dazu, diese Artefakte richtliniengesteuert zu erstellen, zu synchronisieren, zu rotieren und zu widerrufen. Darüber hinaus bietet sie ein auditierbares Inventar und überprüfbare Automatisierung. Es gab jedoch immer eine stille Voraussetzung: Jemand muss ILM selbst bereitstellen und betreiben. Für viele Teams entschied dieser Betriebsaufwand darüber, ob sich die Governance kryptografischer Assets überhaupt lohnte. Das aktuelle Update des ILM-Operators zielt genau auf diese Kosten ab.
Das eigentliche Produkt sind gesteuerte kryptografische Assets
Es lohnt sich, genau zu benennen, was Sie von einer Plattform wie ILM wirklich erwarten. Zunächst möchten Sie jedes Zertifikat, jeden Schlüssel und jedes Secret kennen und wissen, in welchem Zustand es sich befindet. Rotation soll planmäßig erfolgen und nicht erst, wenn ein Ausfall dazu zwingt. Ebenso muss Widerruf schnell möglich sein, wenn Vertrauen verloren geht. Und schließlich brauchen Sie Nachweise für all das, die einer Prüfung standhalten. Das ist das Produkt. Die darunterliegende Bereitstellung ist Overhead.
Dieser Overhead war traditionell erheblich. ILM auf Kubernetes zu betreiben bedeutete, eine Values-Datei für den gesamten Stack zu pflegen, Upgrades zu planen, die Kompatibilität von Komponenten zu prüfen und Rollouts zu beobachten. Das Helm-Chart installiert ILM gut – zieht sich aber zurück, sobald die Installation abgeschlossen ist. Jede Stunde, die dafür aufgewendet wird, fehlt bei der Governance der Assets, für deren Verwaltung die Plattform angeschafft wurde. Der richtige Zeitaufwand für Deployment-Mechanik ist: so wenig wie möglich.
Was Ihnen der ILM-Operator abnimmt
Das Kubernetes-Operator-Pattern verlagert Betriebswissen aus Runbooks in Software. Sie deklarieren den gewünschten Zustand, und ein Controller arbeitet kontinuierlich daran, den Cluster daran anzupassen. Beim ILM-Operator ist diese Deklaration eine einzige Platform-Ressource. Sie legt Version, Datenbank, Message Broker, Identity Provider und die Exposition der Plattform fest. Der Operator baut ILM daraus auf und hört nie mit der Reconciliation auf. Wenn etwas abweicht, führt er es zurück. Ändern Sie die Deklaration, rollt der Operator die Änderung in der richtigen Reihenfolge aus.
Die zustandsbehafteten Abhängigkeiten bleiben bewusst flexibel. PostgreSQL, RabbitMQ und Keycloak können jeweils extern betrieben werden, sodass ILM auf bereits vorhandene Infrastruktur verweist. Alternativ können sie managed sein: Der Operator delegiert die Bereitstellung an den etablierten Operator der jeweiligen Technologie, statt diese Systeme selbst neu zu templatisieren. In der Praxis lautet der Quickstart-Weg „alles managed“ – ein funktionierendes ILM auf einem frischen Cluster, ohne dass zuvor Secrets erstellt werden müssen.
| Ihre Zeit fließt in … | Helm-Chart-Bereitstellung | Operator-verwaltete Bereitstellung |
|---|---|---|
| ILM bereitstellen | Eine Values-Datei für den gesamten Stack zusammenstellen | Eine Platform-Ressource deklarieren |
| Upgrades | Upgrade selbst durchführen und Kompatibilität prüfen | Version auf ein getestetes Bundle ändern |
| Konfigurationsdrift | Manuell finden und beheben | Nichts – Reconciliation führt den Zustand zurück |
| Rotation von Zugangsdaten | Betroffene Komponenten selbst neu bereitstellen | Nichts – referenzierte Secrets werden überwacht |
| Abdeckung erweitern | Ein Subchart konfigurieren und das Release aktualisieren | Eine Connector-Ressource deklarieren |
Natürlich stellen beide Modelle dieselbe Plattform bereit, und das Helm-Chart bleibt ein vertrauter Einstieg. Der Unterschied liegt darin, wofür danach Ihre Zeit aufgewendet wird. Genau diese Verschiebung macht kryptografisches Asset-Management in der Praxis einfacher: Die Plattform, die verwaltet, benötigt selbst deutlich weniger Verwaltung.
Alle Orte erreichen, an denen Ihre Trust-Artefakte liegen
Eine Lifecycle-Plattform ist nur so nützlich wie ihre Reichweite. ILM erreicht Ihre Umgebung über Connectors. Sie binden Zertifizierungsstellen wie Microsoft AD CS und EJBCA, HashiCorp Vault für Secrets sowie Discovery- und Compliance-Anbieter an. Diese Connectors bestimmen, wie viel Ihres kryptografischen Bestands tatsächlich gesteuert wird. Dieselbe Frage nach Abdeckung treibt den Aufbau eines umfassenden Inventars kryptografischer Assets. Ebenso ist das der Grund, warum Lifecycle Governance Secrets einschließen muss und nicht nur Zertifikate.
Mit dem Operator wird jeder Connector zu einer eigenen Connector-Ressource, die unabhängig von der Plattform bereitgestellt und konfiguriert wird. Die Governance auf einen neuen Bereich Ihrer Umgebung auszuweiten – eine weitere CA, einen weiteren Vault oder eine weitere Discovery-Quelle – ist damit eine Deklaration und kein Deployment-Projekt. Ein Connector kann sich sogar selbst bei ILM registrieren. Der vertraute Genehmigungsablauf bleibt bestehen: Der Connector wartet auf Freigabe, bis ein Administrator ihn akzeptiert.
Die Disziplin, die ILM auf Ihre Assets anwendet – auf ILM selbst angewendet
Die Kernthese von ILM lautet, dass Trust-Artefakte durch Automatisierung gesteuert werden sollten und nicht durch Heldentaten. Der Operator überträgt dieses Prinzip auf die Plattform selbst – besonders sichtbar in den Day-2-Details.
- Upgrades werden zu einer einzeiligen Änderung. Das Versionsfeld wählt ein getestetes Bundle, das jedes Komponenten-Image festlegt – Kombinationen, die gemeinsam validiert wurden, statt von Hand zusammengesetzt zu werden.
- Nichts ändert sich hinter Ihrem Rücken. Eine Plattform fixiert ihre Version bei der Erstellung. Ein Upgrade des Operators aktualisiert eine laufende Plattform niemals stillschweigend, und ein Major-Version-Wechsel der verwalteten Infrastruktur wartet auf Ihre ausdrückliche Bestätigung.
- Rotation propagiert. Wenn sich ein referenziertes Secret ändert – etwa weil Datenbank-Zugangsdaten rotiert werden – erkennt der Operator dies und stellt die betroffenen Komponenten neu bereit. Zugangsdaten liegen niemals in der Ressource selbst; dort stehen nur Verweise auf Kubernetes Secrets.
- Status sagt die Wahrheit. Die Plattform meldet Phase und Conditions auf Grundlage gemessener Bereitschaft – also dessen, was tatsächlich verfügbar ist – und nicht auf Annahmen darüber, was verfügbar sein sollte.
- Löschen ist standardmäßig sicher. Wird eine Platform-Ressource gelöscht, bleiben die Daten der verwalteten Infrastruktur erhalten, sofern Sie nicht ausdrücklich etwas anderes wählen.
Eine Plattform, die den Lifecycle von Vertrauen automatisiert, sollte selbst lifecycle-automatisiert sein.
In der Praxis sieht so der Weg von ad-hoc betriebenem PKI zu gesteuerten Abläufen auf Deployment-Ebene aus. Die Plattform kommt dadurch dokumentiert, wiederholbar und kontinuierlich durchgesetzt – mit standardmäßig aktivierten Network Policies und gehärteten Workloads ab Werk.
Offen entwickelt – und früh genug, um mitzugestalten
Alles oben Beschriebene ist öffentlich. Der Operator liegt unter github.com/OmniTrustILM/operator unter der MIT-Lizenz. Die Dokumentation wird direkt mitgeliefert: Quickstart, Konfigurationsreferenz, Designdokumente und mehr als zwei Dutzend Beispielressourcen. Für Teams, die bereits das Helm-Chart betreiben, gibt es einen dokumentierten Migrationspfad. Zusätzlich übersetzt ein Converter-Tool eine bestehende Values-Datei zu etwa 90 % in eine Platform-Ressource und markiert den Rest zur Prüfung.
Offenheit ist hier wichtig: Das ist frühe Software. Die Platform- und Connector-Ressourcen wurden erst kürzlich ins Repository aufgenommen, und der Operator befindet sich auf Alpha-Reifegrad. Für die Community ist genau dieses Timing die Chance. Die Entscheidungen, die den Operator prägen werden, fallen jetzt. Welche Deployment-Szenarien sollten die Beispiele abdecken? Was muss eine Migration berücksichtigen? Welche Edge-Konfigurationen sind wichtig? Feedback von heute hat mehr Einfluss als Feedback, nachdem sich die Schnittstellen verfestigt haben.
Wichtigste Erkenntnisse
- Kryptografische Assets – Zertifikate, Schlüssel und Secrets – benötigen Lifecycle Governance, und ILM stellt sie bereit. Der ILM-Operator beseitigt nun den Großteil des Aufwands für den Betrieb von ILM selbst.
- Eine deklarierte
Platform-Ressource ersetzt die manuell gepflegte Bereitstellung: Der Operator baut die Plattform auf und hält sie kontinuierlich im gewünschten Zustand. - Jeder Connector ist eine unabhängige
Connector-Ressource. Damit lässt sich Governance für eine weitere CA, einen Vault oder eine Discovery-Quelle deklarativ erweitern. - Day 2 bleibt einfach: getestete Upgrade-Bundles, keine stillen Änderungen, automatische Neubereitstellung bei Credential-Rotation und ehrliche Statusmeldungen.
- Der Operator steht unter MIT-Lizenz, wird offen entwickelt und befindet sich noch in einer frühen Phase – Community-Feedback hat deshalb gerade jetzt das größte Gewicht.
Probieren Sie ihn in einem Test-Cluster aus: Gehen Sie zu github.com/OmniTrustILM/operator, folgen Sie dem Quickstart und deklarieren Sie Ihre erste Platform. Teilen Sie uns anschließend mit, was in Ihrer Umgebung gesteuert werden muss – eröffnen Sie ein Issue mit Ihrem Szenario, Ihren Migrationsfragen oder dem Connector, den Sie als Nächstes betreiben möchten. In dieser Phase prägt Ihr Input den Operator am stärksten.
