Freigeben über

Konfigurieren des sicheren Zugriffs auf Azure Repos aus Pipelines

  • Artikel

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 Auftragsautorisierungsbereichs auf das aktuelle Projekt für Releasepipelinen
  • Zugriff auf Repositorys in YAML-Pipelines schützen

Basic-Prozess

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

  1. 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 den Grenzwert für die Auftragsautorisierung auf das aktuelle Projekt für (nicht)release pipelines und beachten Sie, welche Repositorys Ihre Pipeline nicht auschecken kann. Submodule-Repositorys werden möglicherweise nicht in der ersten fehlgeschlagenen Ausführung angezeigt.
  2. Gewähren Sie den Buildidentitätszugriff der Pipeline für jedes Projekt , das ein Repository enthält, auf das Ihre Pipeline zugreifen muss.
  3. Gewähren Sie der Buildidentität der Pipeline Lesezugriff auf dieses Repository für jedes Repository, das Ihre Pipeline auscheckt.
  4. Gewähren Sie der Buildidentität der Pipeline Lesezugriff auf dieses Repository für jedes Repository , das von einem Repository als Untermodul verwendet wird, aus und befindet sich im selben Projekt.
  5. 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 FabrikamFiber FabrikamChat 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. Screenshot: SpaceGameWeb-Repositorystruktur.
  • Die FabrikamFiber-Repositorystrukturen des Projekts sehen wie im folgenden Screenshot gezeigt aus. Screenshot: FabrikamFiber-Repositorystruktur.
  • 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 für die Verwendung einer Identität auf Projektebene zu konfigurieren, aktivieren Sie den Autorisierungsbereich für den Auftrag auf das aktuelle Projekt für die Einstellung nicht freigegebener Pipelines .

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.

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 differenzierten Berechtigungsmechanismus für Azure Repos-Repositorys in Form der Einstellung Zugriff auf Repositorys in YAML-Pipelines schützen. Mit dieser Einstellung fordert eine YAML-Pipeline explizit die Berechtigung für den Zugriff auf alle Azure Repos-Repositorys an, und zwar 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 FabrikamFiber FabrikamChat Repositorys im fabrikam-tailspin/SpaceGameWeb fabrikam-tailspin/FabrikamFiber Projekt auf.

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

Screenshot: Erste Ausführung der SpaceGameWeb-Pipeline nach dem Aktivieren der Umschaltfläche „Zugriff auf Repositorys in YAML-Pipelines schützen“.

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

Screenshot: Sie werden aufgefordert, 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 der Zugriff auf 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. Erfahren Sie mehr über das Auschecken von Untermodulen.

Nehmen Sie außerdem an, 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.

Klassische Releasepipelines

Das Verfahren zum Sichern des Zugriffs auf Repositorys für Releasepipelines ähnelt dem Verfahren 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. Erfahren Sie mehr über bereichsbezogene Buildidentitäten und den Auftragsautorisierungsbereich.

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 Auftragsautorisierungsbereich auf aktuelles Projekt für Nicht-Releasepipelines beschränken.

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.