Workload soll keine Secrets speichern? Workload Identity Federation konfigurieren

Eine CI/CD-Workload benötigt Zugriff auf Azure. Ein langlebiges Client-Secret im Repository oder in der Pipeline verursacht jedoch ein vermeidbares Risiko.

Microsoft Entra Workload Identity Federation ersetzt das gespeicherte Secret durch eine Vertrauensbeziehung:

GitHub Actions fordert ein kurzlebiges OIDC-Token an
-> Microsoft Entra überprüft die Token-Claims
-> Microsoft Entra tauscht es gegen ein Zugriffstoken
-> der Workflow greift nur auf autorisierte Azure-Ressourcen zu

Dieser Trip verwendet GitHub Actions als externe Workload. Dasselbe Föderationsmodell unterstützt auch andere OpenID-Connect-Identitätsanbieter, Kubernetes-Workloads und unterstützte CI/CD-Plattformen.

Wann Workload Identity Federation verwenden?

Verwende Workload Identity Federation, wenn:

• eine Workload außerhalb von Azure ausgeführt wird und OpenID Connect unterstützt
• ein CI/CD-Job sich bei Azure authentifizieren muss, ohne ein Client-Secret oder einen privaten Zertifikatschlüssel zu speichern
• Anmeldeinformationen nicht in der Pipeline gespeichert oder rotiert werden sollen
• der Zugriff auf ein bestimmtes Repository, einen Branch, ein Tag, einen Pull Request oder eine Umgebung beschränkt werden muss

Verwende für eine Workload auf einem Azure-Dienst nach Möglichkeit direkt eine verwaltete Identität, sofern der Dienst diese unterstützt.

Die Vertrauensbeziehung verstehen

Die Verbundidentitäts-Anmeldeinformation enthält kein Secret. Sie legt fest, welchen externen Tokens Microsoft Entra vertrauen darf.

Microsoft Entra überprüft diese Claims:

Claim	Zweck
iss	Identifiziert den externen Tokenaussteller
sub	Identifiziert die genaue Workload, zum Beispiel einen Repository-Branch
aud	Identifiziert Microsoft Entra als Zielgruppe für den Tokenaustausch

Für einen GitHub-Actions-Workflow auf dem Branch main sieht die Vertrauensbeziehung typischerweise so aus:

Issuer: https://token.actions.githubusercontent.com
Subject: repo:<organization>/<repository>:ref:refs/heads/main
Audience: api://AzureADTokenExchange

Der Subject-Wert unterscheidet zwischen Groß- und Kleinschreibung und muss exakt zum Workflow-Kontext passen. Platzhalter werden in einer normalen Verbundidentitäts-Anmeldeinformation nicht unterstützt.

Voraussetzungen

Bereite Folgendes vor:

• ein GitHub-Repository mit einem Actions-Workflow
• die Namen der GitHub-Organisation und des Repositorys
• den Branch oder die GitHub-Umgebung, der bzw. die als vertrauenswürdig gelten soll
• ein Azure-Abonnement und die Zielressource
• Berechtigung zum Verwalten der App-Registrierung
• Berechtigung zum Zuweisen der erforderlichen Azure-Rolle

Verwende eine dedizierte App-Registrierung für die Workload. Verwende keine Anwendung mit anderen, nicht zugehörigen Berechtigungen wieder.

App-Registrierung erstellen oder öffnen

Öffne im Microsoft Entra Admin Center:

Entra ID
> App-Registrierungen
> Neue Registrierung

Erstelle eine App-Registrierung mit einem aussagekräftigen Workload-Namen oder öffne die vorhandene App, die aktuell das Secret verwendet.

Beispiel:

GitHub deployment workload

Anwendungs- und Mandanten-ID notieren

Notiere auf der Seite Übersicht der App-Registrierung:

Anwendungs-ID (Client)
Verzeichnis-ID (Mandant)

Der Workflow verwendet diese IDs. Sie sind jedoch keine Secrets.

Verbundidentitäts-Anmeldeinformation hinzufügen

Öffne:

Zertifikate & Geheimnisse
> Verbundanmeldeinformationen
> Anmeldeinformation hinzufügen

Wähle:

Szenario für Verbundanmeldeinformationen: GitHub Actions zum Bereitstellen von Azure-Ressourcen

Konfiguriere die Vertrauensbeziehung für die Demo:

Organisation: <GitHub-Organisation>
Repository: <Repository>
Entitätstyp: Branch
GitHub-Branchname: main
Name: github-main

Microsoft Entra erzeugt Issuer, Subject und Audience aus diesen Werten.

Tipp: Vertraue für den ersten Test nur einem dedizierten Demo-Repository und dessen Branch main. Füge später separate Verbundanmeldeinformationen für genehmigte Umgebungen, Branches, Tags oder Pull-Request-Workflows hinzu.

Wähle Hinzufügen und prüfe, ob die Anmeldeinformation auf der Registerkarte Verbundanmeldeinformationen erscheint.

Zugriff auf die Zielressource gewähren

Die Föderation authentifiziert die Workload, gewährt aber allein noch keinen Zugriff.

Öffne die Azure-Ressource oder den kleinstmöglichen geeigneten Bereich und wähle:

Zugriffssteuerung (IAM)
> Rollenzuweisung hinzufügen

Wähle die Rolle mit den geringsten erforderlichen Berechtigungen und weise sie dem Dienstprinzipal der App-Registrierung zu.

Vermeide Besitzer oder Mitwirkender auf Abonnementebene, wenn der Workflow nur Zugriff auf eine Ressourcengruppe oder Ressource benötigt.

GitHub-Actions-Workflow konfigurieren

Erlaube dem Workflow, ein GitHub-OIDC-Token anzufordern:

permissions:
  id-token: write
  contents: read

Melde dich mit der Verbundidentität bei Azure an:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4

      - name: Sign in to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

      - name: Verify the Azure context
        run: az account show --output table

Öffne im GitHub-Repository:

Settings
> Secrets and variables
> Actions
> Variables
> New repository variable

Erstelle diese drei Repository-Variablen:

AZURE_CLIENT_ID: <Anwendungs-ID (Client) aus der App-Registrierung>
AZURE_TENANT_ID: <Verzeichnis-ID (Mandant)>
AZURE_SUBSCRIPTION_ID: <ID des vom Workflow verwendeten Azure-Abonnements>

Workflow ausführen und prüfen

Führe den Workflow vom vertrauenswürdigen Branch main aus.

Die Azure-Anmeldung sollte ohne Client-Secret erfolgreich sein. Der Prüfschritt sollte das erwartete Abonnement anzeigen.

Wenn die Anmeldung fehlschlägt, vergleiche die Verbundanmeldeinformation mit dem Token-Kontext:

richtige GitHub-Organisation und richtiges Repository
richtiger Entitätstyp
exakter Name von Branch, Tag, Pull Request oder Umgebung
Berechtigung id-token: write vorhanden
richtige Client-, Mandanten- und Abonnement-ID

Enterprise-Hinweis

Empfohlene Checkliste:

• eine dedizierte Workload-Identität erstellen
• nur dem erforderlichen Repository und Ausführungskontext vertrauen
• für jeden genehmigten Kontext eine separate Verbundanmeldeinformation verwenden
• Zugriff mit geringsten Rechten im kleinstmöglichen Azure-Bereich gewähren
• GitHub-Produktionsumgebungen mit Genehmigungen schützen
• Drittanbieter-GitHub-Actions an vertrauenswürdige Versionen oder Commit-SHAs binden
• Workload-Identity-Anmeldungen und Azure-Aktivitäten überwachen
• ungenutzte Verbundanmeldeinformationen und Rollenzuweisungen entfernen

Workload Identity Federation entfernt gespeicherte Authentifizierungs-Secrets. Sie ersetzt nicht die Autorisierung, Workflow-Sicherheit, den Branchschutz, Umgebungsgenehmigungen oder die Überwachung.