Konfigurieren des sicheren Zugriffs auf Azure Repos aus Pipelines
Ihre Repositorys sind eine wichtige Ressource für Ihren Geschäftserfolg, weil sie den Code enthalten, der Ihr Unternehmen unterstützt. Der Zugriff auf Repositorys sollte nicht einfach erteilt werden.
In diesem Artikel erfahren Sie, wie Sie die Sicherheit Ihrer Pipelines verbessern, die auf Azure Repos zugreifen, um das Risiko zu begrenzen, dass Ihr Quellcode in die falschen Hände gelangt.
Bei der Einrichtung von Pipelines für den sicheren Zugriff auf Azure-Repositorys werden die Umschaltflächen Auftragsautorisierungsbereich für Nicht-Releasepipelines auf aktuelles Projekt beschränken, Auftragsautorisierungsbereich für Releasepipelines auf aktuelles Projekt beschränken und Zugriff auf Repositorys in YAML-Pipelines schützen aktiviert.
Wir behandeln sowohl Buildpipelines als auch klassische Releasepipelines:
Basic-Prozess
Die Schritte sind für alle Pipelines ähnlich:
Ermitteln Sie die Liste der Azure Repos-Repositorys, auf die Ihre Pipeline Zugriff benötigt, die Teil derselben Organisation sind, sich aber in unterschiedlichen Projekten befinden.
Sie können die Liste der Repositorys kompilieren, indem Sie Ihre Pipeline überprüfen. Oder Sie können die Umschaltfläche Auftragsautorisierungsbereich auf aktuelles Projekt für (Nicht-)Releasepipelines beschränken aktivieren und feststellen, welche Repositorys Ihre Pipeline nicht auscheckt. Submodulrepositorys werden möglicherweise in der ersten fehlerhaften Ausführung nicht angezeigt.
Führen Sie für jedes Azure DevOps-Projekt, das ein Repository enthält, auf das Ihre Pipeline zugreifen muss, die Schritte zum Erteilen des Zugriffs auf das Projekt für die Buildidentität der Pipeline aus.
Führen Sie für jedes Azure Repos-Repository, das Ihre Pipeline auscheckt, die Schritte zum Erteilen von Lesezugriff auf dieses Repository für die Buildidentität der Pipeline aus.
Führen Sie für jedes Repository, das von einem Repository, das Ihre Pipeline auscheckt, als Submodul verwendet wird und sich im selben Projekt befindet, die Schritte zum Erteilen von Lesezugriff auf dieses Repository für die Buildidentität der Pipeline aus.
Aktivieren Sie die Umschaltflächen Auftragsautorisierungsbereich für Nicht-Releasepipelines auf aktuelles Projekt beschränken, Auftragsautorisierungsbereich für Releasepipelines auf aktuelles Projekt beschränken und Zugriff auf Repositorys in YAML-Pipelines schützen.
Buildpipelines
Um die Schritte zur Verbesserung der Sicherheit Ihrer Pipelines beim Zugriff auf Azure Repos zu veranschaulichen, verwenden wir ein aktuell ausgeführtes Beispiel.
Angenommen, Sie arbeiten an der SpaceGameWeb-Pipeline, die im fabrikam-tailspin/SpaceGameWeb-Projekt im Azure Repos-Repository SpaceGameWeb gehostet wird. Nehmen Sie außerdem an, dass Ihre SpaceGameWeb-Pipeline checkt das SpaceGameWebReact-Repository im selben Projekt und die FabrikamFiber- und FabrikamChat-Repositorys im fabrikam-tailspin/FabrikamFiber-Projekt auscheckt.
Nehmen Sie schließlich an, dass das FabrikamFiber-Repository das FabrikamFiberLib-Repository als Untermodul verwendet, das im selben Projekt gehostet wird. Erfahren Sie mehr über das Auschecken von Untermodulen.
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. Nehmen Sie außerdem an, dass Sie Ihre Pipeline bereits erfolgreich ausgeführt haben.
Verwenden einer projektbasierten Buildidentität für Buildpipelines
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. Ersteres bietet mehr Sicherheit, letzteres mehr Benutzerfreundlichkeit. 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 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 enthalten die folgenden Meldungen: 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.
Führen Sie zum Beheben der Check-Out-Probleme die unter Grundlegende Vorgehensweise beschriebenen Schritte aus.
Darüber hinaus müssen Sie die Untermodulrepositorys vor den Repositorys, die sie verwenden, explizit auschecken. In unserem Beispiel bedeutet dies das FabrikamFiberLib-Repository.
Wenn Sie jetzt unsere Beispielpipeline ausführen, ist sie erfolgreich.
Weitere Konfiguration
Um die Sicherheit beim Zugriff auf Azure Repos weiter zu verbessern, sollten Sie die Einstellung Zugriff auf Repositorys in YAML-Pipelines schützen 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. Erfahren Sie mehr über diese Einstellung. Das Auschecken anderer Repositorytypen, z. B. von in GitHub gehosteten Repositorys, ist von dieser Einstellung nicht betroffen.
In unserem aktuell ausgeführten Beispiel fordert die Pipeline die SpaceGameWeb-Berechtigung für den Zugriff auf das SpaceGameWebReact-Repository im fabrikam-tailspin/SpaceGameWeb-Projekt sowie die FabrikamFiber- und FabrikamChat-Repositorys im fabrikam-tailspin/FabrikamFiber-Projekt an, wenn dieser Umschalter aktiviert ist.
Wenn Sie die Beispielpipeline ausführen, erhalten einen Build ähnlich dem im folgenden Screenshot gezeigten.
Sie werden aufgefordert, den Repositorys, die Ihre Pipeline auscheckt oder als Ressourcen definiert hat, Berechtigungen zu erteilen.
Sobald Sie so vorgehen, wird ihre Pipeline ausgeführt, aber sie schlägt fehl, weil sie das FabrikamFiberLib-Repository nicht als Untermodul von FabrikamFiber auschecken kann. Um dieses Problem zu beheben, checken Sie FabrikamFiberLib explizit aus, fügen Sie z. B. einen - checkout: git://FabrikamFiber/FabrikamFiberLib-Schritt vor dem -checkout: FabrikamFiber-Schritt ein.
Wenn Sie die Beispielpipeline jetzt ausführen, ist sie 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
Hier werden einige problematische Situationen genannt und wie damit umgegangen werden kann.
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 Umschaltfläche Zugriff auf Repositorys in YAML-Pipelines schützen aktiviert ist.
Um das Problem zu beheben, überprüfen Sie das OtherRepo-Repository mithilfe des checkout-Befehls, z. B. - checkout: git://FabrikamFiber/OtherRepo.
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 FabrikamFiberLib explizit aus, fügen Sie z. B. einen - checkout: git://FabrikamFiber/FabrikamFiberLib-Schritt vor dem -checkout: FabrikamFiber-Schritt ein.
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 aktuell 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, das FabrikamFiber-Repository verwendet das FabrikamFiberLib-Repository (im selben Projekt) als Untermodul.
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. Ersteres bietet mehr Sicherheit, letzteres mehr Benutzerfreundlichkeit. 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 enthalten die Meldung 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.
Führen Sie zum Beheben dieser Probleme die Schritte unter Grundlegendes Verfahren aus.
Wenn Sie jetzt unsere Beispielpipeline ausführen, ist sie erfolgreich.