In vielen Azure-Projekten begegnen mir noch immer klassische Serviceverbindungen mit Client Secrets, manchmal sogar Benutzerkonten in Automatisierungsskripten. Vor ein paar Jahren war das gängige Praxis. Heute liegen die Risiken offen auf dem Tisch, denn Secrets werden zu oft im Klartext gespeichert, versehentlich in Repos gepusht oder landen in Umgebungsvariablen. Spätestens seit Microsoft die verpflichtende MFA für Admin- und Entwicklerportale in Azure und Entra ID mit Stichtag Oktober 2025 ausgeweitet hat, haben solche Konstrukte keine Zukunft mehr. Wer seine Pipelines dauerhaft betreiben will, sollte sich deshalb mit Workload Identity Federation beschäftigen.

Workload Identity Federation ersetzt statische Secrets durch kurzlebige Tokens

Bei Workload Identity Federation melden sich Automatisierungsdienste wie Azure DevOps oder GitHub Actions nicht mehr mit fest hinterlegten Secrets bei Azure an, sondern mit kurzlebigen Tokens. Die Identität prüft dabei der Pipeline-Anbieter selbst, etwa GitHub Actions. Azure akzeptiert ein vertrauenswürdiges Token, das über eine Föderation mit der Anwendung verknüpft ist, also mit einer App-Registrierung oder einer Managed Identity. Statische Secrets braucht man dann nicht mehr, und jede Anmeldung lässt sich sauber nachvollziehen. Das erhöht die Sicherheit deutlich. Ab MFA-Phase 2 führt aber ohnehin kaum ein Weg daran vorbei, weil viele Serviceverbindungen mit Benutzerkonten oder Secrets dann schlicht nicht mehr funktionieren.

Praxis-Tipp: Oft erlebe ich, dass Projektteams vor der Migration zurückschrecken. Gerade jetzt, kurz vor den großen Änderungen durch die verpflichtende MFA, lohnt sich der Wechsel aber. Azure DevOps und GitHub machen die Umstellung mittlerweile erstaunlich einfach.

Bestehende Serviceverbindungen in Azure DevOps lassen sich per Klick umstellen

Wer noch klassische Azure-DevOps-Serviceverbindungen nutzt (Projekt → Projekteinstellungen → Serviceverbindungen), sieht dort in der Regel bereits einen Hinweis auf die neue Föderationsoption. Bei den meisten AzureRM- bzw. ARM-Verbindungen folgt die Migration diesem Muster:

flowchart TD
  devops["Azure DevOps Pipeline"] --> oidc["OIDC-Token anfordern"]
  oidc --> azuread["Entra ID: Föderierte Anmeldung"]
  azuread --> serviceconn["Service-Principal mit federierter Identität"]
  serviceconn --> azure["Azure-Ressourcen"]

Abbildung: Azure DevOps meldet sich per OIDC und Workload Identity Federation bei Azure an

Im Azure-DevOps-Portal öffnet man die bestehende Serviceverbindung und klickt auf „In Workload Identity Federation konvertieren“. Azure DevOps legt dann im Hintergrund am verknüpften Service Principal ein Federated Credential an, meist mit einem passenden Subject-Claim wie sub=system:serviceaccount:.... Berechtigungsprobleme entstehen nach meiner Erfahrung vor allem dann, wenn die Rolle des Service Principals zu weit gefasst ist. Hier gilt tatsächlich, dass weniger mehr ist. Statt Contributor auf Subscription-Ebene vergibt man besser granulare Rollen auf Ebene der Ressourcengruppe oder des jeweiligen Dienstes.

Weitere Details und fertige Beispiele stehen in der offiziellen Dokumentation (Workload Identity für Azure-DevOps-Release-Pipelines).

Für GitHub Actions legt man die föderierten Anmeldeinformationen selbst an

Bei GitHub Actions funktioniert das Prinzip ähnlich, eingerichtet wird es aber meist im Entra Admin Center (App-Registrierungen → Zertifikate & Geheimnisse → Föderierte Anmeldeinformationen). Über „Föderierte Anmeldeinformationen hinzufügen“ definiert man dort Regeln, die zum OIDC-Token eines bestimmten GitHub-Repos, Branches oder Environments passen. Als Claims kommen etwa repo:org/repo:ref:refs/heads/main oder, gezielt für Umgebungen, environment:production infrage. Wer lieber mit Maschinenidentitäten arbeitet, kann das Ganze übrigens auch mit einer User-assigned Managed Identity umsetzen.

Gerade bei komplexeren Szenarien mit mehreren Branches oder Umgebungen hilft die offizielle Anleitung weiter (GitHub Actions mit OIDC in Entra ID).

Minimale Rechte verhindern, dass die föderierte Identität zum Einfallstor wird

Damit die neue föderierte Identität keine neue Angriffsfläche öffnet, sollte man die Fehler aus der Zeit der Client Secrets nicht wiederholen. Allumfassende Rollen haben hier nichts verloren, vergeben werden gezielt nur die Rechte, die tatsächlich gebraucht werden (Principle of Least Privilege). Sehr praktisch ist, dass jede Verbindung ihren eigenen Subject-Claim hat. Damit lassen sich Zugriffe sauber auditieren, sofern man für jede Anwendung oder Pipeline eine eigene App-Registrierung oder Managed Identity verwendet. Die Unterschiede und Einsatzszenarien beider Varianten habe ich im Beitrag Workload-Identitäten in Entra ID: Managed Identities vs. App-Registrierungen ausführlicher beschrieben.

Die Zwangs-MFA macht Benutzerkonten in der Automatisierung zum Problem

Vielen ist noch nicht bewusst, dass Benutzerkonten in Automatisierungsskripten mit Phase 2 der verpflichtenden Azure-MFA endgültig zum Problem werden. In einigen Tenants habe ich gesehen, dass selbst zentrale Deployments noch über alte Benutzerkonten liefen. Spätestens ab Herbst 2025 ist damit Schluss. Wer böse Überraschungen vermeiden und den Betrieb sichern will, muss deshalb auf Workload Identity Federation umstellen, freiwillig ist das nicht mehr. Wie man Client Secrets sicher ablöst und welche Alternativen es gibt, erkläre ich im Beitrag Client Secrets ablösen: Sichere Alternativen in Entra ID.

Workload Identity Federation ist für mich der neue Standard

Für mich ist Workload Identity Federation längst mehr als ein weiteres Feature. Sie ist der neue Standard für sichere und wartungsarme Automatisierung in Azure und Microsoft 365. Die Umstellung kostet anfangs etwas Zeit, rechnet sich aber schnell, denn es laufen keine Secrets mehr ab, Rollouts verlieren ihren Schrecken und man behält die Zugriffe besser im Blick. Spätestens mit der Azure-MFA-Pflicht ist der Drops ohnehin gelutscht. Wer jetzt umstellt, spart sich später eine Menge Nerven und Troubleshooting.