Managed Identities

Warum Managed Identities?

Managed Identities (MI) lösen ein sehr konkretes Problem: Workloads benötigen Authentifizierung, aber Secrets in Konfigurationen, Pipelines oder Key Vaults sind operational teuer (Rotation, Leaks, Ownership).

Mit MI bekommt eine Azure-Ressource eine Identität in Entra ID. Die Plattform stellt Tokens zur Verfügung, und du steuerst den Zugriff über RBAC oder dienstspezifische Berechtigungen.

Varianten: System-assigned vs. User-assigned

• System-assigned MI

  • Lebenszyklus ist an die Ressource gebunden.
  • Ideal, wenn die Identität exklusiv zu genau einer Workload gehört.
  • Löschen der Ressource löscht auch die Identität.

• User-assigned MI

  • Eigenständige Ressource, kann mehreren Workloads zugewiesen werden.
  • Sinnvoll für Shared-Identitäten (z. B. mehrere Functions, die gleiches Secret lesen dürfen) oder wenn du Identität unabhängig vom Compute-Lebenszyklus behalten willst.

Pragmatischer Default: System-assigned für die meisten Workloads, User-assigned nur bei klarer Begründung.

Zugriff erteilen: RBAC und Data Plane

MI allein gibt noch keinen Zugriff. Du brauchst eine Zuweisung – und je nach Dienst ist das Data Plane relevant:

• Key Vault: bevorzugt RBAC (statt Access Policies), z. B. “Key Vault Secrets User”.
• Storage: “Storage Blob Data Reader/Contributor” für Datenzugriff.
• Azure Resource Manager: “Contributor” o. ä. für Management Plane-Operationen.

Wichtiger Unterschied: Eine Workload kann Ressourcen deployen dürfen, ohne Daten lesen zu dürfen – und umgekehrt.

Wie Tokens in der Praxis bezogen werden

Bei MI stellt die Plattform Token über einen Managed-Identity-Endpunkt bereit (Compute-abhängig). Applikationen sollten das nicht “von Hand” bauen, sondern eine etablierte Credential-Chain nutzen.

Pragmatisches Prinzip:

• In Cloud-Umgebungen: MI wird automatisch gefunden.
• Lokal/CI: Entwickler-/Federated Credentials übernehmen.

Wichtig für Troubleshooting: viele Fehler wirken wie “Netzwerk”, sind aber ein falsch konfigurierter Token-Audience/Scope (z. B. Storage Data Plane vs ARM).

Grenzen: MI ist nicht für alles geeignet

MI ist Azure-tenantgebunden. Typische Grenzen:

• Cross-Tenant-Zugriffe erfordern explizites Design (B2B/Multitenant App, separate Identitäten).
• Manche Drittanbieter-Systeme erwarten weiterhin klassische Credentials – dann brauchst du einen Übergang (idealerweise kurz und gut überwacht).

Betrieb: Lifecycle und Review

• System-assigned MI verschwinden mit der Ressource: plane das in Decommissioning/Restore-Szenarien.
• User-assigned MI brauchen Ownership: Wer verwaltet Zuweisungen, wer reviewt Role Assignments?
• Behandle MI-Zugriffe wie jede andere Berechtigung: regelmäßige Reviews, Scopes klein halten, privilegierte Zuweisungen vermeiden.

Typische Einsatzszenarien

• App Service/Functions: Zugriff auf Key Vault, Storage, Service Bus ohne Connection-String-Secrets.
• AKS: bevorzugt Workload Identity (federated), aber MI kann in Legacy-Szenarien vorkommen.
• Automation/Runbooks: Zugriff auf ARM und ausgewählte Dienste (z. B. Policy Remediation).

Lokale Entwicklung und CI/CD

Ein häufiger Stolperstein ist, dass MI in Dev-Umgebungen nicht verfügbar ist (lokal, GitHub Actions Runner ohne Azure Identity).

Bewährtes Muster:

• In Produktion: MI.
• In Dev/CI: separate Identität (z. B. Service Principal/Federated Credentials) mit minimalem Scope.
• Im Code: eine Auth-Chain, die erst MI versucht und sonst auf Developer Credentials fällt (ohne Secrets im Repo).

Fallstricke aus der Praxis

• Zu breiter Scope: MI bekommt Contributor auf Subscription “weil es schnell geht” – später ist nicht mehr erklärbar, warum.
• User-assigned MI als Shared-User: wird zur heimlichen “Admin-Identität” vieler Workloads.
• Propagation/Cache: Rollenänderungen wirken nicht sofort; Tokens werden gecached. Bei Problemen Tokens erneuern und Zeit für Propagation einplanen.
• Cross-Tenant: MI ist an den Tenant gebunden. Multi-Tenant-Szenarien brauchen bewusstes Design.

Empfehlung

• MI als Default für Workload-zu-Workload Auth in Azure.
• RBAC konsequent über Gruppen/Scopes modellieren; privilegierte Zuweisungen vermeiden.
• Für Deployments eher dedizierte CI-Identitäten nutzen, statt Workload-MIs “zum Deployen” zu missbrauchen.