Übersicht
OpenID Connect (OIDC) ermöglicht deinen GitHub Actions-Workflows den Zugriff auf Ressourcen in Azure, ohne dass die Azure-Anmeldeinformationen als langlebige GitHub-Geheimnisse gespeichert werden müssen.
Dieser Leitfaden gibt einen Überblick über die Konfiguration von Azure, um OIDC von GitHub als Verbundidentität zu vertrauen, und enthält ein Workflowbeispiel für die azure/login
-Aktion, die Token zur Authentifizierung bei Azure und zum Zugriff auf Ressourcen verwendet.
Voraussetzungen
-
Informationen zu den grundlegenden Konzepten, nach denen GitHub OpenID Connect (OIDC) sowie die Architektur und Vorteile des Protokolls verwendet, findest du unter Informationen zur Sicherheitshärtung mit OpenID Connect.
-
Bevor du fortfährst, musst du deine Sicherheitsstrategie planen, um sicherzustellen, dass Zugriffs-Token nur auf vorhersehbare Weise zugewiesen werden. Zur Steuerung, wie dein Cloud-Anbieter Zugriffs-Token ausgibt, musst du mindestens eine Bedingung definieren, damit nicht vertrauenswürdige Repositorys keine Zugriffs-Token für deine Cloud-Ressourcen anfordern können. Weitere Informationen findest du unter Informationen zur Sicherheitshärtung mit OpenID Connect.
Hinzufügen der Verbundanmeldeinformationen zu Azure
Der OIDC-Anbieter von GitHub arbeitet mit dem Workloadidentitätsverbund von Azure zusammen. Eine Übersicht findest du in der Dokumentation von Microsoft unter Workloadidentitätsverbund (Vorschau).
Um den OIDC-Identitätsanbieter in Azure zu konfigurieren, musst du die folgende Konfiguration ausführen. Anweisungen zum Vornehmen dieser Änderungen findest du in der Azure-Dokumentation.
- Erstelle eine Azure Active Directory-Anwendung und einen Dienstprinzipal.
- Füge Verbundanmeldeinformationen für die Azure Active Directory-Anwendung hinzu.
- Erstelle GitHub-Geheimnisse zum Speichern der Azure-Konfiguration.
Weitere Anleitungen zum Konfigurieren des Identitätsanbieters:
- Stelle für die Sicherheitshärtung sicher, dass du Informationen zur Sicherheitshärtung mit OpenID Connect gelesen hast. Ein Beispiel findest du unter Informationen zur Sicherheitshärtung mit OpenID Connect.
- Für die
audience
-Einstellung wird der Wertapi://AzureADTokenExchange
empfohlen, aber du kannst hier auch andere Werte angeben.
Aktualisieren deines GitHub Actions-Workflows
Um deine Workflows für OIDC zu aktualisieren, musst du zwei Änderungen an deinen YAML-Daten vornehmen:
- Füge Berechtigungseinstellungen für das Token hinzu.
- Tausche mit der
azure/login
-Aktion das OIDC-Token (JWT) gegen ein Cloudzugriffstoken aus.
Hinzufügen von Berechtigungseinstellungen
Der Auftrag oder die Workflowausführung erfordert eine Einstellung permissions
mit id-token: write
. Du kannst das OIDC JWT-ID-Token nicht anfordern, wenn die Einstellung permissions
für id-token
auf read
oder none
festgelegt ist.
Mit der Einstellung id-token: write
kann der JWT von GitHub-OIDC-Anbieter mit einer der folgenden Ansätze angefordert werden:
- Verwenden von Umgebungsvariablen auf dem Runner (
ACTIONS_ID_TOKEN_REQUEST_URL
undACTIONS_ID_TOKEN_REQUEST_TOKEN
). - Verwenden von
getIDToken()
aus dem Actions-Toolkit.
Wenn du ein OIDC-Token für einen Workflow abrufen musst, können die Berechtigungen auf Workflowebene festgelegt werden. Beispiel:
permissions:
id-token: write # This is required for requesting the JWT
contents: read # This is required for actions/checkout
Wenn Du nur ein OIDC-Token für einen einzelnen Auftrag abrufen musst, kann diese Berechtigung innerhalb dieses Auftrags festgelegt werden. Beispiel:
permissions:
id-token: write # This is required for requesting the JWT
Möglicherweise musst Du hier zusätzliche Berechtigungen angeben, abhängig von den Anforderungen Deines Workflows.
Für wiederverwendbare Workflows sollte die permissions
-Einstellung für id-token
auf Aufruferworkflowebene oder in dem bestimmten Auftrag auf write
festgelegt werden, der den wiederverwendbaren Workflow aufruft. Weitere Informationen findest du unter Wiederverwenden von Workflows.
Anfordern des Zugriffstokens
Die azure/login
-Aktion empfängt ein JWT vom GitHub-OIDC-Anbieter und fordert dann ein Zugriffstoken von Azure an. Weitere Informationen findest du in der azure/login
-Dokumentation.
Im folgenden Beispiel wird ein OIDC-ID-Token mit Azure ausgetauscht, um ein Zugriffstoken zu empfangen, das dann für den Zugriff auf Cloudressourcen verwendet werden kann.
name: Run Azure Login with OIDC
on: [push]
permissions:
id-token: write
contents: read
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: 'Az CLI login'
uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: 'Run az commands'
run: |
az account show
az group list