Das Buchungsportal der Nordlicht Reisen GmbH hat inzwischen mehrere Automatisierungen, und jede meldet sich irgendwo an. Eine GitHub-Aktion liefert nach Azure aus, eine Azure-DevOps-Pipeline tut dasselbe für ein zweites Team, ein Skript liest Pull Requests aus Azure Repos, und ein Workflow soll selbst einen Pull Request öffnen. Auf der Wiki-Seite „Zugänge“ steht bei zweien dieser Fälle ein persönliches Zugriffstoken von Frau Berger, die im Herbst das Unternehmen verlässt. Sie sollen entscheiden, welche Identität jede Automatisierung bekommt, und die Zugänge so einrichten, dass kein Mensch dahinter steckt.
Die Prüfung nennt das: Dienstprinzipale und verwaltete Identitäten abwägen, GitHub Apps, GITHUB_TOKEN und PATs einsetzen und Azure-DevOps-Dienstverbindungen und PATs verwalten. Ein Dienstprinzipal ist die Identität einer Anwendung in Microsoft Entra; ein PAT (Personal Access Token, persönliches Zugriffstoken) gehört dagegen immer einem Menschen.
Vorwissen: Was eine verwaltete Identität ist, steht in K3, Lektion 3.3.1. Wie eine Pipeline ohne Geheimnis nach Azure ausliefert (Workload-Identitätsverbund, das Subjekt, azure/login), zeigt K3, Lektion 3.7.5; die Rechte des Tokens in Actions und Azure Pipelines behandelt K3, Lektion 3.7.7. Hier steht die Entscheidung im Mittelpunkt: welche Identität wofür, mit welchen Grenzen.
Dienstprinzipal oder verwaltete Identität
Microsoft stellt beide auf der Seite zu Dienstprinzipalen und verwalteten Identitäten in Azure DevOps so gegenüber:
| Identität | Wofür am besten | Wer verwaltet die Anmeldeinformation |
|---|---|---|
| Verwaltete Identität (managed identity) | Arbeitslasten, die in Azure laufen | Azure; Ihre Anwendung speichert kein Client-Geheimnis |
| Dienstprinzipal (service principal) | Arbeitslasten außerhalb von Azure oder wenn eine übertragbare Anwendungsidentität nötig ist | Sie: Workload-Identitätsverbund, ein Schlüsselpaar (englisch certificate) oder ein Client-Geheimnis |
Microsofts Empfehlung: Für eine Arbeitslast in Azure eine verwaltete Identität; bei einem Dienstprinzipal den Verbund oder ein Schlüsselpaar vor dem Client-Geheimnis, wenn die Umgebung es erlaubt. Eine verwaltete Identität ist ein besonderer Dienstprinzipal, dessen Anmeldeinformationen Azure verwaltet. Eine systemzugewiesene Identität gehört zu genau einer Ressource und wird mit ihr gelöscht, eine benutzerzugewiesene ist eine eigene Ressource, die mehreren Ressourcen zugewiesen werden kann.
Was das für Pipelines bedeutet
Ein von Microsoft gehosteter Agent oder ein GitHub-gehosteter Runner ist keine Ressource, der Sie in Azure eine Identität anheften. Deshalb gibt es den Workload-Identitätsverbund: Die Pipeline weist dem Anbieter nach, wer sie ist, und Microsoft Entra tauscht diesen Nachweis gegen ein kurzlebiges Token. Kein Geheimnis liegt in der Pipeline.
Für die Azure-Resource-Manager-Dienstverbindung nennt Microsoft diese Optionen:
- App-Registrierung (automatisch) mit Verbund. Voraussetzung ist unter anderem die Rolle Owner im Abonnement; Azure DevOps legt App und Verbund selbst an.
- Verwaltete Identität mit Verbund, verbunden mit einer bestehenden benutzerzugewiesenen Identität. Microsoft empfiehlt das, wenn Sie keine App-Registrierung anlegen dürfen.
- App-Registrierung oder verwaltete Identität (manuell): aufwendiger, nur wenn die automatische Option nicht klappt.
Nur aus Gründen der Rückwärtskompatibilität bestehen, und sind nicht empfohlen: App-Registrierung mit Geheimnis, vom Agent zugewiesene verwaltete Identität (selbst gehosteter Agent auf einer Azure-VM) und Veröffentlichungsprofil. Eine bestehende Verbindung stellen Sie mit dem Werkzeug Convert auf Verbund um. Das geht laut Microsoft nur, wenn Azure DevOps die Verbindung selbst angelegt hat und nur ein Projekt sie nutzt; eine automatisch angelegte Verbindung lässt sich sieben Tage lang zurücknehmen. Die Seite kündigt außerdem an, den bisherigen Aussteller (Issuer) des Verbunds von Azure DevOps zugunsten des Entra-Ausstellers einzustellen; neue Verbindungen nutzen den Entra-Aussteller schon, das Datum lesen Sie dort nach.