Erstellen einer Workloadidentität für einen GitHub Actions-Workflow

  • 5 Minuten

Nachdem Sie das Konzept einer Workloadidentität kennengelernt haben, möchten Sie wahrscheinlich wissen, wie Sie eine solche erstellen und mit einem GitHub Actions-Bereitstellungsworkflow verknüpfen. Diese Lerneinheit zeigt Ihnen die Schritte, um dies zu erreichen.

Erstellen einer Microsoft Entra-Anwendung

In der vorangegangenen Lerneinheit haben Sie gelernt, dass für Workloadidentitäten die Erstellung einer Anwendungsregistrierung in Microsoft Entra ID erforderlich ist.

Hinweis

Zum Erstellen und Ändern von Anwendungsregistrierungen müssen Sie über Berechtigungen in Microsoft Entra ID verfügen. In einigen Organisationen benötigen Sie möglicherweise einen Administrator, der diese Schritte für Sie ausführt.

Bei der Erstellung einer Anwendungsregistrierung müssen Sie einen Anzeigenamen angeben. Der Anzeigename ist ein für Menschen lesbarer Name, der die Anwendungsregistrierung beschreibt.

Tipp

Verwenden Sie für Ihre Anwendungsregistrierung einen eindeutigen, beschreibenden Anzeigenamen. Es ist wichtig, dass Sie Ihrem Team verdeutlichen, welchen Zweck die Anwendungsregistrierung erfüllt, damit sie nicht versehentlich gelöscht wird oder ihre Berechtigungen geändert werden.

Hier sehen Sie einen Azure CLI-Beispielbefehl zum Erstellen einer neuen Microsoft Entra ID-Anwendung:

az ad app create --display-name $applicationRegistrationName

Hier sehen Sie einen Azure PowerShell-Beispielbefehl zum Erstellen einer neuen Microsoft Entra ID-Anwendung:

New-AzADApplication -DisplayName $applicationRegistrationName

Die Ausgabe des oben genannten Befehls enthält einige wichtige Informationen, darunter:

  • Anwendungs-ID: Die Anwendungsregistrierung verfügt über einen eindeutigen Bezeichner, der häufig als Anwendungs-ID oder auch als Client-ID bezeichnet wird. Sie verwenden diesen Bezeichner, wenn sich Ihr Workflow bei Azure anmelden muss.
  • Objekt-ID: Die Anwendungsregistrierung verfügt über eine Objekt-ID, d. h. einen eindeutigen Bezeichner, der von Microsoft Entra ID zugewiesen wird. Ein Beispiel für die Verwendung einer Objekt-ID wird später in diesem Modul gezeigt.

Bei der Erstellung einer Anwendungsregistrierung legen Sie normalerweise nur den Anzeigenamen fest. Die anderen Namen und Bezeichner werden automatisch von Azure zugewiesen.

Achtung

Ein Anzeigename ist nicht eindeutig. Möglicherweise verwenden mehrere Anwendungsregistrierungen denselben Anzeigenamen. Gehen Sie mit Bedacht vor, wenn Sie einer Anwendungsregistrierung, die Sie über ihren Anzeigenamen identifiziert haben, Berechtigungen gewähren. Hierbei kann es passieren, dass Sie versehentlich der falschen Anwendungsregistrierung Berechtigungen erteilen. Es empfiehlt sich, stattdessen einen der eindeutigen Bezeichner zu verwenden.

Verbundanmeldeinformationen

Wenn eine Identität mit Azure kommunizieren muss, meldet sie sich bei Microsoft Entra ID an. An sich erlaubt eine Anwendungsregistrierung keinem Workflow und keiner Anwendung, sich bei Azure anzumelden. Sie müssen zuerst Anmeldeinformationen zuweisen. Verbundanmeldeinformationen sind eine Art von Anwendungsanmeldeinformation. Im Gegensatz zu den meisten Anmeldeinformationen ist für Verbundanmeldeinformationen keine Verwaltung von Geheimnissen wie Kennwörtern oder Schlüsseln erforderlich.

Wenn Sie Verbundanmeldeinformationen für einen Bereitstellungsworkflow erstellen, weisen Sie Microsoft Entra ID und GitHub im Prinzip an, sich gegenseitig zu vertrauen. Diese Vertrauensstellung wird als Verbund bezeichnet.

Wenn Ihr Workflow dann versucht, sich anzumelden, stellt GitHub Informationen zur Ausführung des Workflows bereit, damit Microsoft Entra ID entscheiden kann, ob der Anmeldeversuch zulässig ist. Die Informationen, die GitHub während jedes Anmeldeversuchs für Microsoft Entra ID bereitstellt, können die folgenden Felder enthalten:

  • Den Namen des GitHub-Benutzers oder der GitHub-Organisation.
  • Der Name des GitHub-Repositorys.
  • Den Branch Ihres Repositorys, auf dem der Workflow derzeit ausgeführt wird.
  • Die Umgebung, auf die Ihr Workflowauftrag ausgerichtet ist. Weitere Informationen zu Umgebungen finden Sie in einem späteren Modul.
  • Ob die Erstellung eines Pull Requests den Workflow ausgelöst hat.

Sie können Microsoft Entra ID so konfigurieren, dass ein Anmeldeversuch über GitHub abhängig von den Werten der zuvor aufgeführten Eigenschaften zugelassen oder verweigert wird. Beispielsweise können Sie die folgenden Richtlinien erzwingen:

  • Anmeldeversuche nur zulassen, wenn ein Workflow aus einem bestimmten GitHub-Repository in meiner Organisation ausgeführt wird
  • Anmeldeversuche nur zulassen, wenn ein Workflow aus einem bestimmten GitHub-Repository in meiner Organisation ausgeführt wird und der Branchname „main“ lautet.

In der folgenden Abbildung wird gezeigt, wie sich ein Bereitstellungsworkflow über eine Workloadidentität und eine Verbundanmeldeinformation anmelden kann:

Diagramm mit dem Anmeldeprozess für eine Workloadidentität und Verbundanmeldeinformationen

Folgende Schritte werden beim Anmeldeprozess durchgeführt:

  1. Wenn Ihr Workflow mit Azure kommunizieren muss, stellt GitHub einen sicheren Kontakt mit Microsoft Entra ID her, um ein Zugriffstoken anzufordern. GitHub stellt Informationen zur GitHub-Organisation (my-github-user), zum Repository (my-repo) und zum Branch bereit, auf dem der Workflow ausgeführt wird (main). Außerdem enthalten sind Ihre Mandanten-ID in Microsoft Entra ID, die Anwendungs-ID für die Anwendungsregistrierung der Workflowidentität und die Azure-Abonnement-ID, für die Ihr Workflow bereitgestellt werden soll.

  2. Microsoft Entra ID validiert die Anwendungs-ID und überprüft, ob für die GitHub-Organisation, das Repository und die Verzweigung Verbundanmeldeinformationen innerhalb der Anwendung vorliegen.

  3. Nachdem Microsoft Entra ID bestimmt hat, dass die Anforderung gültig ist, wird ein Zugriffstoken ausgestellt. Ihr Workflow verwendet das Zugriffstoken bei der Kommunikation mit Azure Resource Manager.

Erstellen einer Verbundanmeldeinformation

Wenn Sie die Azure CLI verwenden, definieren Sie Verbundanmeldeinformationen, indem Sie eine JSON-Datei oder eine Variable erstellen. Sehen Sie sich beispielsweise folgende JSON-Datei an:

{
  "name": "MyFederatedCredential",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

In dieser Datei gibt die subject-Eigenschaft an, dass die Verbundanmeldeinformationen nur gültig sein sollen, wenn ein Workflow unter den folgenden Umständen ausgeführt wird:

Feld Wert
Name der GitHub-Organisation my-github-user
Der Name des GitHub-Repositorys. my-repo
Branchname main

Nachdem Sie eine Richtlinie in JSON erstellt und in einer Datei namens policy.json gespeichert haben, können Sie die Azure CLI verwenden, um die Verbundanmeldeinformationen zu erstellen:

az ad app federated-credential create \
  --id $applicationRegistrationObjectId \
  --parameters @policy.json

Wenn Sie Azure PowerShell verwenden, definieren Sie eine Verbundanmeldeinformation, indem Sie eine Zeichenfolge ähnlich der folgenden erstellen:

$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"

Die Zeichenfolge oben gibt an, dass die Verbundanmeldeinformationen nur gültig sein sollen, wenn ein Workflow unter den folgenden Umständen ausgeführt wird:

Feld Wert
Name der GitHub-Organisation my-github-user
Der Name des GitHub-Repositorys. my-repo
Branchname main

Nachdem Sie eine Richtlinienzeichenfolge erstellt haben, können Sie Azure PowerShell zum Erstellen der Verbundinformationen verwenden:

New-AzADAppFederatedCredential `
  -Name 'MyFederatedCredential' `
  -ApplicationObjectId $applicationRegistrationObjectId `
  -Issuer 'https://token.actions.githubusercontent.com' `
  -Audience 'api://AzureADTokenExchange' `
  -Subject $policy

Verwalten des Lebenszyklus Ihrer Workloadidentität

Es ist wichtig, den gesamten Lebenszyklus jeder erstellten Workloadidentität zu berücksichtigen. Was geschieht nach der Erstellung einer Workloadidentität für einen Bereitstellungsworkflow, wenn der Workflow letztlich gelöscht oder nicht mehr verwendet wird?

Workloadidentitäten und Verbundanmeldeinformationen werden nicht automatisch entfernt, daher müssen Sie alte Workloadidentitäten überwachen und entfernen. Auch wenn die Workloadidentitäten Ihres Bereitstellungsworkflows keine geheimen Anmeldeinformationen aufweisen, die wiederverwendet werden könnten, empfiehlt es sich dennoch, sie zu entfernen, wenn sie nicht mehr benötigt werden. Auf diese Weise kann niemand ein anderes GitHub-Repository desselben Namens erstellen und unerwartet Zugriff auf Ihre Azure-Umgebung erhalten.

Eine bewährte Methode besteht darin, Ihre Workloadidentitäten an einem Ort zu dokumentieren, auf den Sie und Ihr Team leicht zugreifen können. Sie sollten für jede Workloadidentität die folgenden Informationen einfügen:

  • Wichtige identifizierende Informationen, z. B. den Namen und die Anwendungs-ID.
  • Ihren Zweck.
  • Die Person, die sie erstellt hat, die Person, die für die Verwaltung verantwortlich ist, und die Person, die bei einem Problem ggf. helfen kann.
  • Die erforderlichen Berechtigungen und eine klare Begründung, warum sie benötigt werden
  • Die erwartete Lebensdauer

Sie sollten Ihre Workloadidentitäten regelmäßig überprüfen, um sicherzustellen, dass sie weiterhin verwendet werden und dass die zugewiesenen Berechtigungen noch stimmen.