Veröffentlichen Sie Azure DevOps-Erweiterungen mit Azure Workload Identity

Wie Sie vielleicht wissen, betreue ich mehrere Azure DevOps Extensions. Um sie zu veröffentlichen, verwende ich die Azure DevOps Extension Tasks. Und um sich zu authentifizieren, müssen Sie ein Personal Access Token bereitstellen.

Wenn Sie Hilfe bei der Konfiguration einer grundlegenden CI/CD-Pipeline für eine Azure DevOps-Erweiterung benötigen , sehen Sie sich die Anleitung auf Microsoft Learn an).

Das Problem mit persönlichen Zugriffstoken ist, dass sie immer aktiv sind, ablaufen (je nach Unternehmensrichtlinien häufiger) und tendenziell mehr Zugriff gewähren, als Sie möchten.

Vor kurzem hat Azure DevOps Unterstützung für Workload-Identitäten erhalten. Eine Workload-Identität verwendet einen Dienstprinzipal und OIDC, um ein temporäres Token für Ihren Azure Pipelines-Job zur Authentifizierung zu erstellen. Jeder Dienst in Azure DevOps, der ein PAT akzeptiert, akzeptiert auch ein auf diese Weise erworbenes Token.

Die Einrichtung war nicht so einfach, wie ich es mir gewünscht hätte, aber jetzt, wo es funktioniert, sollte ich mir keine Sorgen mehr über persönliche Zugangstoken machen müssen, ob sie noch sicher gespeichert sind und nicht ablaufen, wenn ich es am wenigsten erwarte.

Das Gleiche sollte auch für GitHub Actions funktionieren, aber ich bin noch nicht dazu gekommen, das einzurichten.

Die offizielle Dokumentation zur Einrichtung der Workload-Identität und ihrer Registrierung in Azure DevOps finden Sie hier. Die Dokumentation beschreibt jedoch nicht genau dieses Szenario und ich bin dabei auf mehrere Probleme gestoßen.

Die folgenden Schritte sind erforderlich, um auch Ihre Publishing-Pipeline in eine Workload-Identität umzuwandeln:

• Aktivieren Sie die Vorschau der Workload-Identität
• Erstellen Sie eine Service-Verbindung in Azure DevOps unter Verwendung des neuen Workload-Identitätstyps
• Fügen Sie den Service Principal als Benutzer zu Ihrer Azure DevOps Organisation hinzu
• Extrahieren Sie die Azure DevOps Identity Id aus der Profil-API
• Fügen Sie den Service Principal zu Ihrem Azure DevOps Marketplace Publisher hinzu
• Finden Sie die Id Ihrer Visual Studio Marketplace-Dienstverbindung
• Fügen Sie einen AzureCLI Schritt in Ihre Pipeline(s) ein, um ein gültiges Token für den Auftrag anzufordern

Im Folgenden werde ich Ihnen jeden Schritt im Detail erklären.

Aktivieren Sie die Vorschau der Workload-Identität

Um eine Workload-Identität zu verwenden, müssen Sie zunächst die Workload-Identitätsvorschau in Ihrer Azure DevOps-Organisation aktivieren:

Workload Identity-Verbund für ARM-Dienstverbindungen Ermöglicht es Ihnen, ARM-Dienstverbindungen mit dem Authentifizierungsschema des Workload Identity-Verbunds zu erstellen. Damit entfällt die Notwendigkeit, Geheimnisse zu verwalten und zu rotieren. Erfahren Sie mehr.

Erstellen Sie eine Service-Verbindung in Azure DevOps unter Verwendung des neuen Workload-Identitätstyps

Ich gehe davon aus, dass Sie in Ihrem Azure-Abonnement über ausreichende Berechtigungen verfügen, um hier ein Service Principal einzurichten. Ich habe sie und kann daher die Option "automatisch" verwenden. Wenn Sie nicht so viel Glück haben, müssen Sie die manuellen Schritte befolgen.

Gehen Sie zu dem Projekt in Azure DevOps, das Ihre Publishing-Pipeline beherbergt, öffnen Sie ⚙️ Projekteinstellungen und dann Service-Verbindungen:

Klicken Sie dann auf Neue Serviceverbindung.

Wählen Sie in der Liste den Azure Resource Manager aus:

Klicken Sie dann auf Weiter.

Wählen Sie dann Workload Identity Federation (automatisch)

Und klicken Sie erneut auf Weiter.

Wählen Sie Ihr Azure-Abonnement und eine Ressourcengruppe aus und geben Sie Ihrer Serviceverbindung einen Namen:

Klicken Sie dann auf Speichern.

Azure DevOps wird nun einige Dinge in der ausgewählten Azure Subscription einrichten und aushandeln.

Fügen Sie den Service Principal als Benutzer zu Ihrer Azure DevOps Organisation hinzu

Jetzt müssen Sie den Service Principal als Benutzer zu Ihrer Azure DevOps Organisation hinzufügen. Dazu benötigen Sie den vollständigen Anzeigenamen des erstellten Service Principal.

Öffnen Sie die Serviceverbindung, die Sie gerade erstellt haben:

Klicken Sie auf dem Detailbildschirm auf Dienstprinzipal verwalten.

Dies sollte Sie zum Azure-Portal führen und das Übersichtsfenster für den ausgewählten Service Principal öffnen:

Klicken Sie auf das kleine Symbol hinter dem Anzeigenamen, um den vollständigen Anzeigenamen in Ihre Zwischenablage zu kopieren.

Gehen Sie nun zurück zu Azure DevOps und öffnen Sie die ⚙️ Organisationseinstellungen und dann Benutzer:

Klicken Sie auf Benutzer hinzufügen.

Fügen Sie nun den Anzeigenamen des Service-Principals in die Felder Benutzer oder Service-Principals ein und wählen Sie die Zugriffsstufe (Service-Principals benötigen eine Lizenz):

Der Dienstprinzipal sollte nun als Benutzer aufgeführt sein:

Extrahieren Sie die Azure DevOps Identity Id aus der Profile API

Um dem Service Principal Zugriff auf den Publisher im Azure DevOps Marketplace zu gewähren, benötigen wir seine Team Foundation Identity ID. Und um diese zu erhalten, müssen wir die Profil-API abfragen. An dieser Stelle werden die offiziellen Dokumente unscharf, denn sie sagen lediglich:

Fügen Sie einen Service Principal als Mitglied zu einem Publisher-Konto hinzu. Sie können die ID des Service Principal aus seinem Profil abrufen, indem Sie Profile - Abrufen verwenden.

Um die Profil-API aufzurufen, müssen Sie entweder als Eigentümer des Profils angemeldet sein oder Sie müssen bereits dessen Identitäts-GUID kennen. Am Ende habe ich eine kleine Pipeline in Azure Pipelines erstellt und den Dienst Principal verwendet, um seine eigene Profil-ID abzufragen.

steps:
- task: AzureCLI@2
  displayName: 'Fetch profile for Service Principal'
  inputs:
    azureSubscription: 'azure-devops-marketplace'
    scriptType: pscore
    scriptLocation: inlineScript
    inlineScript: |
      az rest -u https://app.vssps.visualstudio.com/_apis/profile/profiles/me --resource 499b84ac-1321-427f-aa17-267ca6975798

Stellen Sie den Build in die Warteschlange und entnehmen Sie die Identität aus den Protokollen:

Fügen Sie den Service Principal zu Ihrem Azure DevOps Marketplace Publisher hinzu

Da wir nun die richtige Identitäts-GUID für den Service Principal haben, können wir ihn als Benutzer zum Azure DevOps Marketplace hinzufügen:

Gehen Sie zum Azure-Marktplatz und melden Sie sich mit dem Eigentümer Ihres Publishers an. Klicken Sie auf Erweiterungen veröffentlichen und dann auf Mitglieder:

Klicken Sie nun auf ➕Hinzufügen.

Fügen Sie die Identitäts-ID aus dem vorherigen Schritt ein und wählen Sie eine Rolle. Ich persönlich habe die Rolle zunächst auf Leser gesetzt, um zu sehen, ob der richtige Anzeigename angezeigt wird, bevor ich die Rolle auf Contributor gesetzt habe :

Finden Sie die Id Ihrer Visual Studio Marketplace-Dienstverbindung

Jetzt benötigen wir die Id der Verbindung zum Visual Studio Marketplace-Dienst.

Gehen Sie zurück zu Ihrer Azure DevOps-Organisation, öffnen Sie das Projekt, das Ihre Publishing-Pipeline enthält, wählen Sie ⚙️ Projekteinstellungen und navigieren Sie dann zu Service Connections.

Öffnen Sie die Dienstverbindung, die Sie zur Veröffentlichung auf dem Visual Studio Marketplace verwenden, und kopieren Sie die resourceId aus der URL:

Fügen Sie einen AzureCLI-Schritt in Ihre Pipeline(s) ein, um ein gültiges Token für den Auftrag anzufordern

Und nun fügen Sie für den letzten Schritt einen Schritt zur Pipeline hinzu, der die Serviceverbindung verwendet, um ein Job-Token zu erhalten und dann das Token auf der Serviceverbindung damit zu überschreiben. Wir verwenden die Aufgabe code>AzureCLI@2< /code, um das Token zu holen und dann einen speziellen Befehlsstring zu protokollieren, um das persönliche Zugriffstoken zu überschreiben, das auf der Visual Studio Marketplace Service Connection gespeichert ist:

# Add a variable that holds the ID of the service connection and use that throughout your pipeline

variables:
- name: 'marketplaceServiceConnection'
  value: '24325a98-0d4b-4180-9936-c930a4156258'  

stages:
- stage: 'Publish'
  displayName: 'Publish'
  jobs:
  - job: 
    displayName: 'Publish'
    steps: 
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'azure-devops-marketplace'
        scriptType: 'pscore'
        scriptLocation: 'inlineScript'
        inlineScript: |
          $accessToken = az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query "accessToken" --output tsv
          write-host "##vso[task.setsecret]$accessToken"
          write-host "##vso[task.setendpoint id=$env:MARKETPLACESERVICECONNECTION;field=authParameter;key=password]$accessToken"

...

    - task: PublishAzureDevOpsExtension@4
      name: 'publishDev'
      inputs:
        connectTo: 'VsTeam'
        connectedServiceName: '$(marketplaceServiceConnection)'

Um sicherzustellen, dass das Job-Token nicht auf dem Bildschirm protokolliert wird, geben wir außerdem einen weiteren task.setSecret Befehl aus. Der Agent erkennt dies und löscht das Token von diesem Zeitpunkt an aus den Protokollen.

Und schon sind Sie fertig!

Das war's! Sie sind fertig! Wenn Sie Ihre nächste Pipeline ausführen, werden Sie nichts anderes sehen als den Schritt, der die Anmeldeinformationen für Ihren Service Principal abruft:

Ich habe meine erste Pipeline mit dieser Methode aktualisiert. Wenn Sie also auf der Suche nach Inspiration sind, können Sie sie sich hier ansehen.

Andere Probleme, die ich lösen musste

Ihre Azure DevOps Organisation muss mit demselben Azure Active Directory Tennant verknüpft sein

Meine Azure DevOps-Organisation war ursprünglich nicht mit Azure Active Directory verknüpft und für das obige Tutorial wird das nicht funktionieren. Ich habe also meine Azure DevOps Organization mit meinem Azure Active Directory-Tenant verknüpft, bevor ich die Konfiguration geändert habe.

Ein Active Directory-Gast kann Azure DevOps keinen Dienstprinzipal nach Namen hinzufügen

Ursprünglich hatte ich eine Menge Probleme, als ich versuchte, den Service Principal als Benutzer zu Azure DevOps hinzuzufügen. Es stellte sich heraus, dass Sie in einem Active Directory-Mitgliedskonto angemeldet sein müssen. Mein Hauptbenutzer ist ein Gast in meinem eigenen Active Directory und das verursachte Probleme.

Ich lud mein anderes Konto zu Azure DevOps ein und fügte es der Gruppe Project Collection Administrators hinzu. Ich meldete mich mit diesem Benutzer an und konnte den Dienstprinzipal hinzufügen.

Sie benötigen die richtigen Berechtigungen in Azure Active Directory, um einen Service Principal einzurichten

In diesem Blog bin ich davon ausgegangen, dass Sie über ausreichende Berechtigungen in Ihrem Active Directory verfügen. Ich habe natürlich den Luxus, über die Zugangsdaten meines eigenen globalen Administratorkontos zu verfügen.

Es ist auch möglich, den Dienstprinzipal von einer anderen Person einrichten zu lassen und dann den manuellen Workflow für die manuelle Einrichtung der Workflow Identity Federation-Dienstverbindung zu verwenden.