Konfigurieren des sicheren Zugriffs auf Azure Repos aus Pipelines

2025-04-30

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Ihre Repositorys sind für Ihren geschäftlichen Erfolg von entscheidender Bedeutung, da sie den Code für Ihre Vorgänge enthalten. Der Zugriff auf Repositorys sollte sorgfältig kontrolliert werden. Dieser Artikel führt Sie zur Verbesserung der Sicherheit der Buildpipeline und der klassischen Releasepipeline beim Zugriff auf Azure Repos, um das Risiko eines nicht autorisierten Zugriffs zu verringern.

Um den sicheren Zugriff auf Azure-Repositorys zu gewährleisten, aktivieren Sie die folgenden Umschaltvorgänge:

Beschränken des Auftragsautorisierungsbereichs auf das aktuelle Projekt für Nicht-Release-Pipelines
Beschränken des Auftragsautorisierungsumfangs auf das aktuelle Projekt für Releasepipelines
Schützen des Zugriffs auf Repositorys in YAML-Pipelines

Dieser Artikel ist Teil einer Reihe, mit der Sie Sicherheitsmaßnahmen für Azure-Pipelines implementieren können. Weitere Informationen finden Sie unter Secure Azure Pipelines.

Voraussetzungen

Kategorie	Anforderungen
Azure DevOps	– Implementieren Sie die Empfehlungen in Make your Azure DevOps secure und Secure Azure Pipelines. - Grundkenntnisse in YAML und Azure Pipelines. Weitere Informationen finden Sie unter Erstellen Ihrer ersten Pipeline.
Erlaubnisse	– So ändern Sie Pipelineberechtigungen: Mitglied der Gruppe "Projektadministratoren". – So ändern Sie Organisationsberechtigungen: Mitglied der Gruppe "Projekt-Sammlungsadministratoren".

Basic-Prozess

Die folgenden Schritte zum Sichern Ihrer Pipelines sind in allen Pipelines ähnlich:

Identifizieren Sie die Azure Repos-Repositorys, auf die Ihre Pipeline Innerhalb derselben Organisation, aber in verschiedenen Projekten Zugriff benötigt.
Überprüfen Sie dazu Ihre Pipeline oder aktivieren Sie die Beschränkung des Zugriffsbereichs für Auftragsautorierung auf das aktuelle Projekt für (Nicht-)Release-Pipelines und achten Sie darauf, welche Repositories Ihre Pipeline nicht auschecken kann. Submodul-Repositorys werden möglicherweise nicht in der ersten fehlgeschlagenen Ausführung angezeigt.
Gewähren Sie der Build-Identität der Pipeline Zugriff auf das Projekt für jedes Projekt, das ein Repository enthält, auf das Ihre Pipeline zugreifen muss.
Gewähren Sie der Kompilierungsidentität der Pipeline Lesezugriff auf dieses Repository für alle Repositories, die Ihre Pipeline auscheckt.
Gewähren Sie der Build-Identität der Pipeline Lesezugriff auf das Repository für jedes Repository, das als Untermodul von einem anderen Repository verwendet wird, das Ihre Pipeline auscheckt und sich im selben Projekt befindet.
Aktivieren Sie den Bereich "Auftragsautorisierung einschränken" auf das aktuelle Projekt für Nicht-Release-Pipelines, beschränken Sie den Auftragsautorisierungsbereich auf das aktuelle Projekt für Releasepipelinen, und schützen Sie den Zugriff auf Repositorys in YAML-Pipelines.

Buildpipelines

Um die Schritte zur Verbesserung der Sicherheit Ihrer Pipelines beim Zugriff auf Azure Repos zu veranschaulichen, verwenden wir das folgende Beispiel.

Angenommen, Sie arbeiten an der SpaceGameWeb-Pipeline, die im fabrikam-tailspin/SpaceGameWeb-Projekt im Azure Repos-Repository SpaceGameWeb gehostet wird.
Ihre SpaceGameWeb Pipeline checkt das SpaceGameWebReact Repository im selben Projekt und die FabrikamFiberFabrikamChat Repositorys im fabrikam-tailspin/FabrikamFiber Projekt aus.
Das FabrikamFiber Repository verwendet das FabrikamFiberLib Repository als Untermodul, das in demselben Projekt gehostet wird.
Die SpaceGameWeb-Repositorystrukturen des Projekts sehen wie im folgenden Screenshot gezeigt aus.
Die FabrikamFiber-Repositorystrukturen des Projekts sehen wie im folgenden Screenshot gezeigt aus.
Stellen Sie sich vor, Ihr Projekt wurde nicht dafür konfiguriert, eine projektbasierte Buildidentität zu verwenden oder den Zugriff auf Repositorys in YAML-Pipelines zu schützen. Gehen Sie außerdem davon aus, dass Sie ihre Pipeline bereits erfolgreich ausgeführt haben.

Verwenden einer projektbasierten Buildidentität für Buildpipelines

Während der Pipelineausführung wird eine Identität für den Zugriff auf Ressourcen wie Repositorys, Dienstverbindungen und Variablengruppen verwendet. Pipelines können zwei Arten von Identitäten verwenden: Projektebene und Sammlungsebene. Die erste priorisiert die Sicherheit, während letzteres die Benutzerfreundlichkeit betont. Weitere Informationen finden Sie unter bereichsbezogenen Buildidentitäten und Auftragsautorisierungsbereich.

Verwenden Sie für erhöhte Sicherheit Identitäten auf Projektebene, wenn Sie Ihre Pipelines ausführen. Diese Identitäten können nur auf Ressourcen innerhalb ihres zugeordneten Projekts zugreifen, wodurch das Risiko eines unbefugten Zugriffs durch böswillige Akteure minimiert wird.

Um Ihre Pipeline zur Verwendung einer projektbezogenen Identität zu konfigurieren, aktivieren Sie die Einstellung Autorisierungsbereich des Auftrags auf das aktuelle Projekt für Pipelines ohne Freigabe.

In unserem aktuell ausgeführten Beispiel kann die SpaceGameWeb-Pipeline auf alle Repositorys in allen Projekten zugreifen, wenn diese Umschaltfläche deaktiviert ist. Wenn die Umschaltfläche aktiviert ist, kann SpaceGameWeb nur auf Ressourcen im fabrikam-tailspin/SpaceGameWeb-Projekt zugreifen, also nur auf die SpaceGameWeb- und SpaceGameWebReact-Repositorys.

Wenn Sie unsere Beispielpipeline ausführen, schlägt die Pipeline fehl, wenn Sie die Umschaltfläche aktivieren, und die Fehlerprotokolle weisen Sie remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting. und remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Um die Auscheckprobleme zu beheben, führen Sie die schritte aus, die im Abschnitt " Einfacher Prozess " dieses Artikels beschrieben sind.

Lesen Sie außerdem explizit die Untermodulrepositorys, bevor die Repositorys, die sie verwenden, verwendet werden. In unserem Beispiel bedeutet dies das FabrikamFiberLib-Repository.

Wenn Sie unsere Beispielpipeline ausführen, ist sie erfolgreich.

Weitere Konfiguration

Um die Sicherheit beim Zugriff auf Azure Repos weiter zu verbessern, sollten Sie den Schutz des Zugriffs auf Repositorys in YAML-Pipelines aktivieren.

YAML-Pipelines
Klassische Buildpipelines

Angenommen, die SpaceGameWeb-Pipeline ist eine YAML-Pipeline, und der YAML-Quellcode sieht ähnlich wie der folgende Code aus.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
  - ...

Schützen des Zugriffs auf Repositorys in YAML-Pipelines

Azure DevOps bietet einen fein abgestuften Berechtigungsmechanismus für Azure Repos-Repositorys als Einstellung Zugriff auf Repositorys in YAML-Pipelines schützen. Mit dieser Einstellung wird eine YAML-Pipeline explizit aufgefordert, auf alle Azure Repos-Repositorys zuzugreifen, unabhängig davon, zu welchem Projekt sie gehören. Weitere Informationen finden Sie unter Access-Repositorys. Diese Einstellung wirkt sich nicht auf das Auschecken anderer Repositorytypen aus, z. B. von GitHub gehostete Repositorys.

Wenn diese Einstellung aktiviert ist, fordert die SpaceGameWeb Pipeline in unserem ausgeführten Beispiel die Berechtigung für den Zugriff auf das SpaceGameWebReact Repository im Projekt sowie die fabrikam-tailspin/SpaceGameWebFabrikamFiber Repositorys im FabrikamChatfabrikam-tailspin/FabrikamFiber Projekt auf.

Wenn Sie die Beispielpipeline ausführen, wird sie ähnlich wie im folgenden Beispiel erstellt.

Screenshot der ersten Ausführung der SpaceGameWeb-Pipeline nach dem Aktivieren der Zugriffsschutz-Umschaltfläche für Repositories in YAML-Pipelines.

Erteilen Sie Berechtigungen für Ihre Pipelinerepositorys oder -ressourcen.

Screenshot der Aufforderung, der SpaceGameWeb-Pipeline die Berechtigung für den Zugriff auf drei Repositorys zu erteilen.

Ihre Pipeline wird ausgeführt, schlägt jedoch fehl, da es das FabrikamFiberLib Repository nicht als Untermodul von FabrikamFiberauschecken kann. Um dieses Problem zu beheben, checken Sie die FabrikamFiberLibSchritte explizit aus, indem Sie einen - checkout: git://FabrikamFiber/FabrikamFiberLib Schritt vor dem -checkout: FabrikamFiber Schritt hinzufügen.

Die Beispielpipeline ist erfolgreich.

Unser endgültiger YAML-Pipelinequellcode sieht wie der folgende Codeschnipsel aus.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: git://FabrikamFiber/FabrikamFiberLib  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md

Problembehandlung

Verwenden Sie die folgenden Lösungen für alle auftretenden Probleme.

Sie verwenden Git in der Befehlszeile, um Repositorys in der gleichen Organisation auszuchecken

Sie verwenden z. B. - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/. Der Befehl schlägt fehl, wenn die Einstellung Zugriffsschutz für Repositorys in YAML-Pipelines aktiviert ist.

Um das Problem zu beheben, schauen Sie sich das OtherRepo Repository mit dem checkout Befehl an, z - checkout: git://FabrikamFiber/OtherRepo. B. .

Ein Repository verwendet ein anderes Repository als Untermodul

Angenommen, eines der Repositorys, das Ihre Pipeline auscheckt, verwendet ein anderes Repository (im selben Projekt) als Untermodul, wie dies in unserem Beispiel für die Repositorys FabrikamFiber und FabrikamFiberLib der Fall ist. Weitere Informationen über das Auschecken von Untermodulen.

Außerdem wird davon ausgegangen, dass Sie der SpaceGame Buildidentität Lesezugriff auf dieses Repository erteilt haben, aber das Auschecken des FabrikamFiber Repositorys schlägt beim Auschecken des FabrikamFiberLib Untermoduls immer noch fehl.

Um dieses Problem zu beheben, checken Sie das FabrikamFiberLibProblem explizit aus, indem Sie einen - checkout: git://FabrikamFiber/FabrikamFiberLib Schritt vor dem -checkout: FabrikamFiber einen Hinzufügen hinzufügen.

In klassischen Buildpipelines können Sie andere Repositorys nicht explizit als Ressourcen deklarieren. Sehen Sie sich weitere Azure Repos-Repositorys an, indem Sie Befehlszeilenaufgaben mit git clone Befehlen hinzufügen, ähnlich dem folgenden Befehl, um das FabrikamFiber Repository auszuchecken: git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --recurse-submodules https://dev.azure.com/silviuandrica/FabrikamFiber/_git/FabrikamFiber

Die Einstellung "Zugriff auf Repositorys schützen" in yaML-Pipelines

Mit der Einstellung "Schützen des Zugriffs auf Repositorys in YAML-Pipelines " wird eine YAML-Pipeline explizit aufgefordert, auf alle Azure Repos-Repositorys zuzugreifen, unabhängig davon, zu welchem Projekt sie gehören. Weitere Informationen finden Sie unter Zugriffstoken, Schützen des Zugriffs auf Repositorys in YAML-Pipelines.

Seien Sie vorsichtig beim Aktivieren der Einstellung Zum Schutz des Zugriffs auf Repositorys in YAML-Pipelines. Wenn Sie dies tun, können Ihre klassischen Buildpipelines nicht auf ein anderes Azure DevOps-Repository zugreifen, mit Ausnahme der in den Einstellungen angegebenen. In unserer Beispielpipeline erhalten Sie einen Fehler und die Protokollmeldung. TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Wenn Ihr Projekt sowohl YAML- als auch klassische Buildpipelinen verwendet und Ihre klassischen Buildpipelinen mehr Azure DevOps-Repositorys als die in ihren Einstellungen angegebenen sehen, erstellen Sie zwei Projekte, eine für die YAML-Pipelines und eine für klassische Buildpipelinen. Aktivieren Sie dann im YAML-Pipelineprojekt die gewünschte Einstellung.

Der Schutz des Zugriffs auf Repositorys in YAML-Pipelines gilt nicht für Repositorys, die auf anderen Diensten wie GitHub gehostet werden.

Die Einstellung für den Autorisierungsbereich des Buildauftrags

Der Autorisierungsbereich des Auftrags auf das aktuelle Projekt für Nicht-Release-Pipelines setzt die Einstellung für den Autorisierungsbereich des Buildauftrags außer Kraft. Wenn Sie die erstgenannte Option einschalten, wird Ihre Pipeline unter Verwendung einer projektbasierten Identität ausgeführt, auch wenn Ihr Buildauftragsautorisierungsbereichdie Projektsammlung angibt.

Screenshot der erfolgreichen Ausführung der Einstellung des Autorisierungsbereichs für den Build-Auftrag.

Klassische Releasepipelines

Der Prozess zum Sichern des Zugriffs auf Repositorys für Releasepipelines ähnelt der Sicherung des Zugriffs auf Repositorys für Buildpipelines.

Um die schritte zu veranschaulichen, die Sie ausführen müssen, verwenden wir ein ausgeführtes Beispiel. In unserem Beispiel gibt es eine Releasepipeline namens FabrikamFiberDocRelease im fabrikam-tailspin/FabrikamFiberDocRelease-Projekt. Angenommen, die Pipeline checkt das FabrikamFiber-Repository im fabrikam-tailspin/FabrikamFiber-Projekt aus, führt einen Befehl aus, um öffentliche Dokumentation zu generieren, und veröffentlicht sie dann auf einer Website. Stellen Sie sich außerdem vor, dass das FabrikamFiber Repository das FabrikamFiberLib Repository (im selben Projekt) als Untermodule verwendet.

Verwenden einer projektbasierten Buildidentität für klassische Releasepipelines

Wenn eine Pipeline ausgeführt wird, wird eine Identität verwendet, um auf verschiedene Ressourcen wie Repositorys, Dienstverbindungen und Variablengruppen zuzugreifen. Es gibt zwei Arten von Identitäten, die von einer Pipeline verwendet werden können: eine Identität auf Projektebene und eine Identität auf Sammlungsebene. Der frühere bietet eine bessere Sicherheit. Letzteres bietet eine einfache Bedienung. Weitere Informationen zu bereichsbezogenen Build-Identitäten und Autorisierungsbereichen von Aufträgen.

Es wird empfohlen, Identitäten auf Projektebene zum Ausführen Ihrer Pipelines zu verwenden. Standardmäßig können Identitäten auf Projektebene nur auf Ressourcen in dem Projekt zugreifen, dessen Mitglied sie sind. Die Verwendung dieser Identität verbessert die Sicherheit, weil sie den Zugriff einer böswilligen Person bei einem Angriff auf Ihre Pipeline einschränkt.

Damit Ihre Pipeline eine Identität auf Projektebene verwendet, aktivieren Sie die Einstellung Autorisierungsbereich für den Auftrag der Releasepipelines auf das aktuelle Projekt begrenzen.

In unserem aktuell ausgeführten Beispiel kann die FabrikamFiberDocRelease-Releasepipeline auf alle Repositorys in allen Projekten zugreifen (auch auf das FabrikamFiber-Repository), wenn diese Umschaltfläche deaktiviert ist. Wenn die Umschaltfläche aktiviert ist, kann FabrikamFiberDocRelease nur auf Ressourcen im fabrikam-tailspin/FabrikamFiberDocRelease-Projekt zugreifen, sodass auf das FabrikamFiber-Repository nicht mehr zugegriffen werden kann.

Wenn Sie unsere Beispielpipeline ausführen, schlägt die Pipeline fehl, wenn Sie die Umschaltfläche aktivieren, und die Protokolle weisen Sie darauf hin. remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Um diese Probleme zu beheben, führen Sie die Schritte im Abschnitt "Einfacher Prozess " dieses Artikels aus.

Unsere Beispielpipeline ist erfolgreich.