Toegang tot Azure-opslagplaatsen beveiligen vanuit pijplijnen

Uw opslagplaatsen zijn een essentiële resource voor uw bedrijfsucces, omdat ze de code bevatten die uw bedrijf aangeeft. Toegang tot opslagplaatsen mag niet eenvoudig worden verleend.

In dit artikel wordt beschreven hoe u de beveiliging van uw pijplijnen die toegang hebben tot Azure-opslagplaatsen, kunt verbeteren om het risico te beperken dat uw broncode in verkeerde handen komt.

De instelling voor pijplijnen voor veilige toegang tot Azure-opslagplaatsen is een instelling waarin de wisselknoppen Taakautorisatiebereik beperken tot het huidige project voor niet-releasepijplijnen, Taakautorisatiebereik beperken tot het huidige project voor releasepijplijnen en Toegang tot opslagplaatsen in YAML-pijplijnen beveiligen zijn ingeschakeld.

We behandelen zowel build-pijplijnen als klassieke release-pijplijnen:

• Pijplijnen bouwen
• Klassieke release-pijplijnen

Basic-proces

De stappen zijn vergelijkbaar in alle pijplijnen:

1. Bepaal de lijst met Opslagplaatsen van Azure-opslagplaatsen waartoe uw pijplijn toegang nodig heeft die deel uitmaken van dezelfde organisatie, maar zich in verschillende projecten bevinden.

   U kunt de lijst met opslagplaatsen compileren door uw pijplijn te inspecteren. U kunt ook het bereik taakautorisatie beperken inschakelen op het huidige project voor (niet)release-pijplijnen en u kunt zien welke opslagplaatsen uw pijplijn niet kan uitchecken. Submoduleopslagplaatsen worden mogelijk niet weergegeven in de eerste mislukte uitvoering.

2. Voor elk Azure DevOps-project dat een opslagplaats bevat waartoe uw pijplijn toegang moet hebben, volgt u de stappen om de build-id van de pijplijn toegang te verlenen tot dat project.

3. Voor elke Opslagplaats van Azure-opslagplaatsen die uw pijplijn uitcheckt, volgt u de stappen om de build-identiteit van de pijplijn leestoegang te verlenen tot die opslagplaats.

4. Voor elke opslagplaats die wordt gebruikt als een submodule door een opslagplaats die door uw pijplijn wordt uitgecheckt en zich in hetzelfde project bevindt, volgt u de stappen om de build-id van de pijplijn leestoegang tot die opslagplaats te verlenen.

5. Schakel het bereik taakautorisatie beperken in op het huidige project voor niet-release-pijplijnen, beperk taakautorisatiebereik tot het huidige project voor releasepijplijnen en beveilig de toegang tot opslagplaatsen in YAML-pijplijnen.

Pijplijnen bouwen

Ter illustratie van de stappen die moeten worden uitgevoerd om de beveiliging van uw pijplijnen te verbeteren wanneer ze toegang hebben tot Azure-opslagplaatsen, gebruiken we een actief 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. Stel dat uw SpaceGameWeb pijplijn de SpaceGameWebReact opslagplaats in hetzelfde project en de FabrikamFiber opslagplaatsen FabrikamChat in het fabrikam-tailspin/FabrikamFiber project uitcheckt.

Ten slotte wordt ervan uitgegaan dat de FabrikamFiber opslagplaats de FabrikamFiberLib opslagplaats gebruikt als een submodule die wordt gehost in hetzelfde project. Lees meer over het uitchecken van submodules.

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 uw pijplijn al hebt uitgevoerd.

Een build-identiteit op basis van project gebruiken voor build-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 wilt dat uw pijplijn gebruikmaakt van een identiteit op projectniveau, schakelt u het bereik Taakautorisatie beperken in op het huidige project 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 worden in de foutenlogboeken aangegeven 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 het Basisproces om de problemen met het afrekenen op te lossen.

Daarnaast moet u de submoduleopslagplaatsen expliciet uitchecken voordat de opslagplaatsen die deze gebruiken. In ons voorbeeld betekent dit de FabrikamFiberLib opslagplaats.

Als u nu onze voorbeeldpijplijn uitvoert, slaagt dit.

Verdere configuratie

Als u de beveiliging verder wilt verbeteren bij het openen van Azure-opslagplaatsen, kunt u overwegen om de beveiligingstoegang tot opslagplaatsen in te schakelen in de instelling YAML-pijplijnen .

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. Lees meer over deze instelling. Het uitchecken van andere typen opslagplaatsen, bijvoorbeeld door GitHub gehoste opslagplaatsen, wordt niet beïnvloed door deze instelling.

Wanneer deze wisselknop 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, ziet u een build die vergelijkbaar is met de volgende schermopname.

U wordt gevraagd om toestemming te verlenen aan de opslagplaatsen die uw pijplijn uitcheckt of als resources heeft gedefinieerd.

Zodra u dit doet, wordt uw pijplijn uitgevoerd, maar deze mislukt omdat de FabrikamFiberLib opslagplaats niet kan worden uitgecheckt als submodule van FabrikamFiber. Als u dit probleem wilt oplossen, bekijkt u expliciet de FabrikamFiberLibstap , bijvoorbeeld een - checkout: git://FabrikamFiber/FabrikamFiberLib stap toevoegen, vóór de -checkout: FabrikamFiber stap.

Als u nu de voorbeeldpijplijn uitvoert, slaagt deze.

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

Problemen oplossen

Hier volgen enkele problematische situaties en hoe u deze kunt afhandelen.

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 wisselknop Toegang tot opslagplaatsen in YAML-pijplijnen beveiligen is ingeschakeld.

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

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 bijvoorbeeld expliciet de FabrikamFiberLib- checkout: git://FabrikamFiber/FabrikamFiberLib stap voor het -checkout: FabrikamFiber probleem.

Klassieke build-pijplijnen

In klassieke build-pijplijnen kunt u niet expliciet andere opslagplaatsen declareren als resources. De manier waarop u meer Opslagplaatsen van Azure-opslagplaatsen uitcheckt, is 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. Lees meer over deze instelling.

Wees voorzichtig bij het inschakelen van de instelling Toegang tot opslagplaatsen beveiligen in YAML-pijplijnen . Als u dit wel 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 en uw klassieke build-pijplijnen bevat, bekijkt u andere Azure DevOps-opslagplaatsen naast de opslagplaatsen die zijn opgegeven in hun instellingen, dan wilt u twee projecten maken, één voor de YAML-pijplijnen en één voor de klassieke build-pijplijnen. Vervolgens kunt u in het YAML-pijplijnproject de instelling inschakelen.

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 worden de logboeken u verteld 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 het Basisproces om deze problemen op te lossen.

Als u nu onze voorbeeldpijplijn uitvoert, slaagt dit.

Zie ook

• 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