Toegang tot Azure-opslagplaatsen beveiligen vanuit pijplijnen

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

Uw opslagplaatsen zijn essentieel voor het succes van uw bedrijf wanneer ze de code gebruiken die uw activiteiten mogelijk maken. Toegang tot opslagplaatsen moet zorgvuldig worden beheerd. In dit artikel wordt u begeleid bij het verbeteren van de beveiliging van build-pijplijnen en klassieke releasepijplijnen bij het openen van Azure-opslagplaatsen om het risico op onbevoegde toegang te beperken.

Schakel de volgende schakelknoppen in om beveiligde toegang tot Azure-opslagplaatsen te garanderen:

• Bereik van taakautorisatie beperken tot huidig project voor niet-release-pijplijnen
• Bereik voor taakautorisatie beperken tot huidig project voor release-pijplijnen
• Toegang tot opslagplaatsen in YAML-pijplijnen beveiligen

Basic-proces

De volgende stappen om uw pijplijnen te beveiligen, zijn vergelijkbaar met alle pijplijnen:

1. Identificeer de Opslagplaatsen van Azure-opslagplaatsen waartoe uw pijplijn toegang nodig heeft binnen dezelfde organisatie, maar in verschillende projecten.
   U kunt dit doen door uw pijplijn te inspecteren of het bereik voor taakautorisatie beperken tot het huidige project in te schakelen voor (niet)release-pijplijnen en te weten welke opslagplaatsen uw pijplijn niet kan uitchecken. Submoduleopslagplaatsen worden mogelijk niet weergegeven in de eerste mislukte uitvoering.
2. Verdeel de build-identiteit van de pijplijn toegang tot dat project voor elk project dat een opslagplaats bevat waartoe uw pijplijn toegang nodig heeft.
3. Verwijs de build-identiteit van de pijplijn leestoegang tot die opslagplaats voor elke opslagplaats die uw pijplijn uitcheckt.
4. Verwijs de build-identiteit van de pijplijn leestoegang tot die opslagplaats voor elke opslagplaats die wordt gebruikt als een submodule door een opslagplaats die uw pijplijn uitcheckt en zich in hetzelfde project bevindt.
5. Schakel het bereik voor taakautorisatie beperken tot het huidige project voor niet-releasepijplijnen, het bereik voor taakautorisatie beperken tot het huidige project voor release-pijplijnen en de toegang tot opslagplaatsen in YAML-pijplijnen beveiligen.

Pijplijnen bouwen

Om de stappen te illustreren die moeten worden uitgevoerd om de beveiliging van uw pijplijnen te verbeteren wanneer ze toegang hebben tot Azure-opslagplaatsen, gebruiken we het volgende voorbeeld.

• Stel dat u werkt aan de SpaceGameWeb pijplijn die in het fabrikam-tailspin/SpaceGameWeb project wordt gehost, in de SpaceGameWeb opslagplaats voor Azure-opslagplaatsen.
• Uw SpaceGameWeb pijplijn controleert de SpaceGameWebReact opslagplaats in hetzelfde project en de FabrikamFiber opslagplaatsen FabrikamChat in het fabrikam-tailspin/FabrikamFiber project.
• De FabrikamFiber opslagplaats gebruikt de FabrikamFiberLib opslagplaats als een submodule die wordt gehost in hetzelfde project.
• De SpaceGameWeb opslagplaatsstructuren van het project zien eruit in de volgende schermopname.
• De FabrikamFiber opslagplaatsstructuren van het project zien eruit in de volgende schermopname.
• Stel dat uw project niet is ingesteld voor het gebruik van een build-identiteit op basis van een project of om de toegang tot opslagplaatsen in YAML-pijplijnen te beveiligen. Stel ook dat u de pijplijn al hebt uitgevoerd.

Een build-identiteit op basis van een project gebruiken voor build-pijplijnen

Tijdens het uitvoeren van pijplijnen wordt een identiteit gebruikt voor toegang tot resources, zoals opslagplaatsen, serviceverbindingen en variabele groepen. Pijplijnen kunnen gebruikmaken van twee typen identiteiten: projectniveau en verzamelingsniveau. De voormalige prioriteit geeft prioriteit aan beveiliging, terwijl de laatste het gebruiksgemak benadrukt. Zie de scoped build-identiteiten en het bereik voor taakautorisatie voor meer informatie.

Gebruik identiteiten op projectniveau wanneer u uw pijplijnen uitvoert voor verbeterde beveiliging. Deze identiteiten hebben alleen toegang tot resources binnen hun bijbehorende project, waardoor het risico op onbevoegde toegang door kwaadwillende actoren wordt geminimaliseerd.

Als u uw pijplijn wilt configureren voor het gebruik van een identiteit op projectniveau, schakelt u het bereik voor taakautorisatie beperken tot het huidige project in voor de instelling voor niet-releasepijplijnen .

Wanneer deze wisselknop is uitgeschakeld, heeft de SpaceGameWeb pijplijn in ons actieve voorbeeld toegang tot alle opslagplaatsen in alle projecten. Wanneer de wisselknop is ingeschakeld, SpaceGameWeb hebben alleen toegang tot resources in het fabrikam-tailspin/SpaceGameWeb project, dus alleen de SpaceGameWeb en SpaceGameWebReact opslagplaatsen.

Als u onze voorbeeldpijplijn uitvoert wanneer u de wisselknop inschakelt, mislukt de pijplijn en geven de foutenlogboeken u 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. en 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.

Volg de stappen die worden beschreven in de sectie Basisproces van dit artikel om de problemen met het afrekenen op te lossen.

Bekijk bovendien expliciet de submoduleopslagplaatsen voordat de opslagplaatsen die deze gebruiken. In ons voorbeeld betekent dit de FabrikamFiberLib opslagplaats.

Als u onze voorbeeldpijplijn uitvoert, slaagt dit.

Verdere configuratie

Als u de beveiliging verder wilt verbeteren wanneer u toegang krijgt tot Azure-opslagplaatsen, kunt u de toegang tot opslagplaatsen in YAML-pijplijnen beveiligen.

YAML-pijplijnen

Stel dat de SpaceGameWeb pijplijn een YAML-pijplijn is en dat de YAML-broncode er ongeveer als volgt uitziet.

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
  - ...

Toegang tot opslagplaatsen in YAML-pijplijnen beveiligen

Azure DevOps biedt een gedetailleerd machtigingsmechanisme voor Opslagplaatsen van Azure-opslagplaatsen, in de vorm van de instelling Toegang tot opslagplaatsen beveiligen tot opslagplaatsen in YAML-pijplijnen . Met deze instelling wordt een YAML-pijplijn expliciet om toestemming gevraagd om toegang te krijgen tot alle Opslagplaatsen van Azure-opslagplaatsen, ongeacht het project waartoe ze behoren. Zie toegangs opslagplaatsen voor meer informatie. Deze instelling heeft geen invloed op het uitchecken van andere typen opslagplaatsen, zoals door GitHub gehoste opslagplaatsen.

Wanneer deze instelling is ingeschakeld in ons actieve voorbeeld, vraagt de SpaceGameWeb pijplijn toestemming om toegang te krijgen tot de SpaceGameWebReact opslagplaats in het fabrikam-tailspin/SpaceGameWeb project en de FabrikamFiber opslagplaatsen FabrikamChat in het fabrikam-tailspin/FabrikamFiber project.

Wanneer u de voorbeeldpijplijn uitvoert, wordt deze gebouwd zoals in het volgende voorbeeld.

Verken uw pijplijnopslagplaatsen of -resources.

Uw pijplijn wordt uitgevoerd, maar mislukt omdat de FabrikamFiberLib opslagplaats niet kan worden uitgecheckt als submodule van FabrikamFiber. Als u dit probleem wilt oplossen, bekijkt u expliciet het FabrikamFiberLib, door een - checkout: git://FabrikamFiber/FabrikamFiberLib stap toe te voegen voor de -checkout: FabrikamFiber stap.

De voorbeeldpijplijn slaagt.

De uiteindelijke broncode van de YAML-pijplijn ziet eruit als het volgende codefragment.

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

Probleemoplossing

Gebruik de volgende oplossingen voor eventuele problemen die zich voordoen.

U gebruikt Git in de opdrachtregel om opslagplaatsen in dezelfde organisatie te uitchecken

U gebruikt - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/bijvoorbeeld . De opdracht mislukt wanneer de instelling Toegang tot opslagplaatsen beveiligen in YAML-pijplijnen is ingeschakeld.

Als u het probleem wilt oplossen, bekijkt u de OtherRepo opslagplaats met behulp van de checkout opdracht, zoals - checkout: git://FabrikamFiber/OtherRepo.

Een opslagplaats gebruikt een andere opslagplaats als submodule

Stel dat een van de opslagplaatsen die uw pijplijn uitcheckt, een andere opslagplaats (in hetzelfde project) gebruikt als submodule, zoals in ons voorbeeld voor de FabrikamFiber opslagplaatsen en FabrikamFiberLib opslagplaatsen. Lees meer over het uitchecken van submodules.

Stel dat u de SpaceGame build-id Leestoegang tot deze opslagplaats hebt gegeven, maar dat het uitchecken van de FabrikamFiber opslagplaats nog steeds mislukt bij het uitchecken van de FabrikamFiberLib submodule.

Als u dit probleem wilt oplossen, bekijkt u expliciet het FabrikamFiberLib, door een - checkout: git://FabrikamFiber/FabrikamFiberLib stap voor de -checkout: FabrikamFiber stap toe te voegen.

Klassieke build-pijplijnen

In klassieke build-pijplijnen kunt u niet expliciet andere opslagplaatsen declareren als resources. Bekijk meer Opslagplaatsen voor Azure-opslagplaatsen door opdrachtregeltaken met opdrachten toe te voegen, vergelijkbaar met git clone de volgende opdracht om de FabrikamFiber opslagplaats te uitchecken: git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --recurse-submodules https://dev.azure.com/silviuandrica/FabrikamFiber/_git/FabrikamFiber

De instelling Toegang tot opslagplaatsen beveiligen in YAML-pijplijnen

De instelling Toegang tot opslagplaatsen in YAML-pijplijnen beveiligen maakt dat een YAML-pijplijn expliciet om toestemming wordt gevraagd om toegang te krijgen tot alle Opslagplaatsen van Azure-opslagplaatsen, ongeacht het project waartoe ze behoren. Zie Toegangstokens, Toegangstokens beveiligen voor opslagplaatsen in YAML-pijplijnen voor meer informatie.

Wees voorzichtig bij het inschakelen van de instelling Toegang tot opslagplaatsen beveiligen in YAML-pijplijnen . Als u dit doet, hebben uw klassieke build-pijplijnen geen toegang tot een andere Azure DevOps-opslagplaats, met uitzondering van de opslagplaats die is opgegeven in de instellingen. In onze voorbeeldpijplijn krijgt u een foutmelding en het logboekbericht TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Als uw project zowel YAML- als klassieke build-pijplijnen gebruikt en uw klassieke build-pijplijnen bekijkt u meer Azure DevOps-opslagplaatsen dan de opslagplaatsen die zijn opgegeven in hun instellingen, twee projecten, één voor de YAML-pijplijnen en één voor klassieke build-pijplijnen. Schakel vervolgens in het YAML-pijplijnproject de gewenste instelling in.

De instelling Toegang tot opslagplaatsen beveiligen in YAML-pijplijnen is niet van toepassing op opslagplaatsen die worden gehost op andere services, zoals GitHub.

De instelling voor het autorisatiebereik van de buildtaak

Het bereik taakautorisatie beperken tot het huidige project voor niet-release-pijplijnen overschrijft de instelling voor het autorisatiebereik van de buildtaak. Als u de vorige functie inschakelt, wordt uw pijplijn uitgevoerd met een projectidentiteit, zelfs als het autorisatiebereik van de buildtaak projectverzameling aangeeft.

Klassieke release-pijplijnen

Het proces voor het beveiligen van de toegang tot opslagplaatsen voor release-pijplijnen is vergelijkbaar met het proces voor build-pijplijnen.

Ter illustratie van de stappen die u moet uitvoeren, gebruiken we een actief voorbeeld. In ons voorbeeld is er een release-pijplijn met de naam FabrikamFiberDocRelease in het fabrikam-tailspin/FabrikamFiberDocRelease project. Stel dat de pijplijn de FabrikamFiber opslagplaats in het fabrikam-tailspin/FabrikamFiber project uitcheckt, een opdracht uitvoert om openbare documentatie te genereren en deze vervolgens naar een website publiceert. Stel dat de FabrikamFiber opslagplaats gebruikmaakt van de FabrikamFiberLib opslagplaats (in hetzelfde project) als een submodule.

Een build-identiteit op basis van Project gebruiken voor klassieke release-pijplijnen

Wanneer een pijplijn wordt uitgevoerd, gebruikt deze een identiteit voor toegang tot verschillende resources, zoals opslagplaatsen, serviceverbindingen, variabele groepen. Er zijn twee typen identiteiten die een pijplijn kan gebruiken: een projectniveau één en een verzamelingsniveau één. De voormalige biedt betere beveiliging. De laatste biedt gebruiksgemak. Lees meer over scoped build-identiteiten en taakautorisatiebereik.

U wordt aangeraden identiteiten op projectniveau te gebruiken voor het uitvoeren van uw pijplijnen. Identiteiten op projectniveau hebben standaard alleen toegang tot resources in het project waarvan ze lid zijn. Het gebruik van deze identiteit verbetert de beveiliging, omdat dit de toegang vermindert die wordt verkregen door een kwaadwillende persoon bij het kapen van uw pijplijn.

Als u van uw pijplijn een identiteit op projectniveau wilt gebruiken, schakelt u het bereik taakautorisatie beperken in op het huidige project voor de instelling voor releasepijplijnen .

In ons actieve voorbeeld, wanneer deze wisselknop is uitgeschakeld, heeft de FabrikamFiberDocRelease release-pijplijn toegang tot alle opslagplaatsen in alle projecten, inclusief de FabrikamFiber opslagplaats. Wanneer de wisselknop is ingeschakeld, FabrikamFiberDocRelease hebt u alleen toegang tot resources in het fabrikam-tailspin/FabrikamFiberDocRelease project, zodat de FabrikamFiber opslagplaats ontoegankelijk wordt.

Als u onze voorbeeldpijplijn uitvoert wanneer u de wisselknop inschakelt, mislukt de pijplijn en de logboeken u 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.

Volg de stappen in de sectie Basisproces van dit artikel om deze problemen op te lossen.

Onze voorbeeldpijplijn slaagt.

Verwante artikelen:

• Scoped build-identiteiten
• Bereik voor taakautorisatie
• De build-identiteit van een pijplijn toegang verlenen tot een project
• De build-identiteit van een pijplijn leestoegang verlenen tot een opslagplaats
• Submodules uitchecken