Wir haben über 2.000 Service Accounts und niemand weiß, wem sie gehören: Die Multi-Cloud-IAM-Krise

Es gibt eine bestimmte Art von Panik, die nur in großen Cloud-Umgebungen auftritt. Sie kommt nicht am ersten Tag und nicht einmal im ersten Jahr, sondern etwa im dritten Jahr, nach der dritten Übernahme und dem fünften Kubernetes-Cluster, wenn jemand fragt: „Moment … wie viele Service Accounts haben wir eigentlich?"

In diesem Fall waren es über 2.000 Machine Identities über AWS, Azure und GCP hinweg. Es gab kein zentrales Inventar und keine konsistente Rotationsrichtlinie, dafür einen Mix aus IAM-Rollen, Service Principals, Workload Identities und Kubernetes-Pod-Identities.

Das ist mehr als „etwas unordentlich", das ist eine Governance-Zeitbombe. Und die Rahmenbedingungen sind hart:

• Automatisierte Discovery von Machine Identities
• Rotation ohne App-Ausfallzeit
• Least-Privilege-Empfehlungen basierend auf tatsächlicher Nutzung
• CI/CD-Integration (Jenkins, GitHub Actions)
• API-first-Architektur
• Keine Agents
• Keine Codeänderungen
• Keine Sechs-Monate-Wissenschaftsprojekte

Außerdem geht es nicht um PAM für Menschen, sondern um den Lifecycle von Machine Identities im großen Maßstab. Genau hier bleiben die meisten Unternehmen stecken, ohne dass es jemand laut sagt. Schauen wir uns an, was tatsächlich realistisch ist.

Die erste harte Wahrheit: Es gibt keinen magischen Einheitsknopf

Sie haben es bereits in Ihren Evaluierungen gesehen.

CyberArk ist mächtig und teuer, und es fühlt sich an, als würde man mit einem Panzer zu einem Messerkampf antreten.

HashiCorp Vault ist solide, aber jemand muss es betreiben: HA-Cluster, Storage-Backends, Secret-Engines und Policy-Drift. Dafür braucht es ein Team, ein Tool allein reicht nicht.

Cloud-native Secrets-Manager wie AWS Secrets Manager und Azure Key Vault sind funktional, aber fragmentiert. Am Ende verwalten Sie drei verschiedene Control Planes, und genau diese Fragmentierung hat Sie hierher gebracht.

Die Branche hat noch keinen sauberen, herstellerneutralen „Multi-Cloud-Machine-Identity-Governor" hervorgebracht, der null Betriebsaufwand erfordert. Was tun Unternehmen also tatsächlich? Sie lösen das Problem mit Architektur und nicht mit einem einzelnen Produkt.

Das Muster, das sich durchsetzt: Statische Credentials abschaffen

Das stärkste Signal in der Diskussion war dieses:

Workload Identity + Federation für Cross-Cloud-Aufrufe. Keine Keys oder statischen Credentials speichern.

Gemeint ist eine Strategie, keine Produktempfehlung. Statt langlebige Access Keys zu rotieren, Secret Sprawl nachzuverfolgen und den Passwort-Lebenszyklus zu verwalten, beseitigen diese Teams das Problem vollständig.

In Kubernetes heißt das üblicherweise, OIDC-Federation zu nutzen, Workloads dynamisch Rollen übernehmen zu lassen und kurzlebige Tokens über Clouds hinweg auszutauschen. AWS unterstützt das mit IAM-Rollen für Service Accounts, GCP mit Workload Identity Federation und Azure mit föderierten Credentials für Service Principals.

Wenn Sie das korrekt verdrahten, speichern Pods keine Credentials mehr. Sie fordern sie an, die Credentials laufen ab und erneuern sich automatisch. Es gibt keine Rotations-Ausfallzeit und keinen Agent, und Codeänderungen sind nicht nötig, wenn Sie bereits SDK-Standard-Credential-Provider verwenden. Deshalb skaliert dieser Ansatz.

Aber was ist mit Discovery?

Hier wird es konkret. Sie haben kein zentrales Inventar, und bevor Sie die Rotation optimieren, brauchen Sie Sichtbarkeit. Unternehmen gehen das auf drei Hauptwegen an.

1. Cloud-natives Inventar + Aggregation

Rufen Sie Identitätsdaten aus AWS IAM, Azure Entra ID, GCP IAM und der Kubernetes API ab und speisen Sie sie in eine zentrale Datenplattform ein. Das kann auch etwas so Einfaches sein wie geplante Exporte in ein Warehouse.

Glamourös ist das nicht, aber Sie bekommen eine Liste von Machine Identities mit Role Bindings, Zeitstempeln der letzten Nutzung und angehängten Policies. Darauf lassen sich Least-Privilege-Empfehlungen aufbauen.

Plug-and-Play ist es nicht, aber schneller, als eine massive PAM-Plattform auszurollen.

2. Policy-as-Code + Drift-Monitoring

Unternehmen, die auf API-first-Modelle setzen, behandeln IAM wie Infrastruktur. Aus Terraform State, Cloud-Logs und Nutzungsmetriken entsteht eine Map der effektiven Berechtigungen.

Von dort aus lassen sich ungenutzte Aktionen identifizieren, überprivilegierte Rollen erkennen und automatisch Pull Requests mit reduzierten Policies öffnen. Vollständig autonom ist das nicht, aber es skaliert besser als manuelle Reviews und passt zu Ihrer Anforderung „API-first".

3. Identity-Graph-Tools (aufkommende Kategorie)

Eine neuere Klasse von Tools baut Identity Graphs über Clouds hinweg auf. Sie nehmen Rollenzuweisungen, Trust Policies, Federation-Beziehungen und Nutzungstelemetrie auf und zeigen dann übermäßige Berechtigungen, fehlkonfigurierte Cross-Cloud-Trusts und ruhende Service Accounts.

Diese Tools sind leichtgewichtiger als vollständige PAM-Suiten und oft agentless. Der Kompromiss: Sie dienen in erster Linie der Governance-Sichtbarkeit, und die Lifecycle-Automatisierung kommt manchmal erst an zweiter Stelle.

Warum sich Vault schwer anfühlt (und warum es manchmal trotzdem gewinnt)

Vault wird oft als „Betriebsaufwand" abgetan, und das stimmt auch. Manche Unternehmen wählen es trotzdem, und zwar wegen der dynamischen Credentials, weniger wegen der Secrets-Speicherung.

Vault kann kurzlebige Datenbank-Credentials generieren, temporäre Cloud-Access-Tokens ausstellen und TTL- und Erneuerungsrichtlinien durchsetzen. Wenn Sie bereit sind, es richtig zu betreiben, wird es zu einem Machine-Identity-Broker.

Das ist allerdings ein Commitment, und ohne Personal dafür wird es wehtun. Die eigentliche Trennlinie verläuft also bei der personellen Kapazität und kaum bei den Features.

Die CI/CD-Integration in der Praxis

Sie brauchen Jenkins- und GitHub-Actions-Integration. Die meisten Unternehmen lösen das, indem sie OIDC-Federation von GitHub Actions in Cloud-Rollen nutzen, Jenkins dynamisch Cloud-Rollen übernehmen lassen und statische CI-Credentials vollständig entfernen.

Das senkt das Risiko von Credential-Leaks, spart manuelle Rotationszyklen und verringert den Pipeline-Secret-Sprawl. Es passt auch zu Ihrer Vorgabe „keine Codeänderungen", denn moderne SDKs unterstützen bereits umgebungsbasierte Token-Injection.

Was Unternehmen 2026 tatsächlich einsetzen

Die ehrliche Antwort: Sie kombinieren mehrere Bausteine.

1. Workload Identity Federation überall dort, wo möglich
2. Kurzlebige Credentials statt Rotation
3. Zentralisiertes Identity-Inventar-Reporting
4. Policy-Analytics-Tooling
5. Minimale Secret-Manager nur dort, wo Federation nicht möglich ist

Sie vereinheitlichen nicht alles unter einer Mega-Plattform, sondern standardisieren Muster. Die Frage lautet nicht mehr „welcher Anbieter", sondern: „Wie eliminieren wir statische Machine Credentials?"

Was Sie wahrscheinlich nicht tun sollten

Versuchen Sie nicht, alle Secrets in sechs Monaten in einem Vault zu zentralisieren. Zwingen Sie Anwendungen nicht, ihre Authentifizierungsmuster zu ändern, rollen Sie keine Agents auf 2.000 Workloads aus, und versuchen Sie nicht, jede IAM-Policy manuell richtig zu dimensionieren. So explodieren Zeitpläne.

Ihre Rahmenbedingungen sind klar, und das Design muss sie respektieren.

Wenn das meine Umgebung wäre

Bei über 2.000 Service Accounts über drei Clouds hinweg würde ich so priorisieren.

In Phase 1 (90 Tage) würde ich Machine Identities über Clouds hinweg inventarisieren, Workload Identity Federation für neue Workloads aktivieren und neue statische Credentials aus CI/CD entfernen.

In Phase 2 (nächste 90 Tage) würde ich langlebige Keys wo möglich durch föderierte Tokens ersetzen, nutzungsbasiertes Policy-Trimming einführen und Dashboards für Identity-Ownership bauen.

In Phase 3 würde ich bewerten, ob eine leichtgewichtige Identity-Governance-Plattform Mehrwert bringt.

Was fehlt, ist ein massives Plattform-Rollout, und das mit Absicht. Ihr eigentlicher Feind ist Wildwuchs und nicht fehlendes Tooling.

Das unbequeme Fazit

Multi-Cloud-Machine-Identity-Governance ist im Kern ein Architekturproblem, und ein Produkt allein löst es nicht.

Die Unternehmen, die hier Erfolg haben, hören auf, Secrets zu rotieren, und fangen an, sie zu eliminieren. Sie zentralisieren nicht mehr manuell, sondern föderieren automatisch, und sie denken in „Trust Exchange" statt in „alles in einen Vault".

Die Zukunft liegt in weniger Passwörtern und nicht in besserem Passwort-Rotieren. Die Teams, die das früh verinnerlichen, wachen nicht mehr um 3 Uhr morgens auf und fragen sich, welcher vergessene Service Account noch Admin-Zugriff auf Produktion hat.