Säker åtkomst till Azure-lagringsplatser från pipelines

Dina lagringsplatser är en viktig resurs för företagets framgång, eftersom de innehåller den kod som driver ditt företag. Åtkomst till lagringsplatser bör inte beviljas på ett enkelt sätt.

Den här artikeln visar hur du förbättrar säkerheten för dina pipelines som kommer åt Azure Repos, för att begränsa risken för att källkoden hamnar i fel händer.

I konfigurationen av pipelines för säker åtkomst till Azure-lagringsplatser är växling av Begränsa jobbets auktoriseringsområde till aktuellt projekt för icke-versionspipelines, Begränsa jobbets auktoriseringsområde till aktuellt projekt för versionspipelines och Skydda åtkomsten till lagringsplatser i YAML-pipelines aktiverat.

Vi går igenom både bygg-pipelines och klassiska versionspipelines:

• Skapa pipelines
• Klassiska versionspipelines

Basic-processen

Stegen liknar alla pipelines:

1. Fastställ listan över Azure Repos-lagringsplatser som din pipeline behöver åtkomst till som ingår i samma organisation, men som finns i olika projekt.

   Du kan kompilera listan över lagringsplatser genom att inspektera pipelinen. Eller så kan du aktivera omfånget Begränsa jobbauktorisering till det aktuella projektet för (icke-)versionspipelines och notera vilka lagringsplatser pipelinen inte kan checka ut. Undermodullagringsplatser kanske inte visas i den första misslyckade körningen.

2. Följ stegen för att ge pipelinens byggidentitet åtkomst till projektet för varje Azure DevOps-projekt som innehåller en lagringsplats som din pipeline behöver åtkomst till.

3. För varje Azure Repos-lagringsplats som pipelinen checkar ut följer du stegen för att ge pipelinens byggidentitet läsbehörighet till lagringsplatsen.

4. För varje lagringsplats som används som en undermodul av en lagringsplats checkar pipelinen ut och finns i samma projekt genom att följa stegen för att ge pipelinens byggidentitet läsbehörighet till lagringsplatsen.

5. Aktivera omfånget Begränsa jobbauktorisering till aktuellt projekt för pipelines som inte är släppt, Begränsa omfånget för jobbauktorisering till aktuellt projekt för versionspipelines och Skydda åtkomsten till lagringsplatser i YAML-pipelines växlar.

Skapa pipelines

För att illustrera de steg som ska utföras för att förbättra säkerheten för dina pipelines när de får åtkomst till Azure Repos använder vi ett exempel som körs.

Anta att du arbetar med pipelinen SpaceGameWeb som finns i fabrikam-tailspin/SpaceGameWeb projektet på SpaceGameWeb Azure Repos-lagringsplatsen. Dessutom ska vi säga att din SpaceGameWeb pipeline checkar ut SpaceGameWebReact lagringsplatsen i samma projekt och lagringsplatserna FabrikamFiber och FabrikamChat i fabrikam-tailspin/FabrikamFiber projektet.

Anta slutligen att lagringsplatsen FabrikamFiber använder lagringsplatsen FabrikamFiberLib som en undermodul som finns i samma projekt. Läs mer om hur du checkar ut undermoduler.

Projektets SpaceGameWeb lagringsplatsstrukturer ser ut så här i följande skärmbild.

Projektets FabrikamFiber lagringsplatsstrukturer ser ut så här i följande skärmbild.

Anta att projektet inte är konfigurerat för att använda en projektbaserad byggidentitet eller för att skydda åtkomsten till lagringsplatser i YAML-pipelines. Anta också att du redan har kört pipelinen.

Använda en projektbaserad byggidentitet för bygg-pipelines

När en pipeline körs använder den en identitet för att komma åt olika resurser, till exempel lagringsplatser, tjänstanslutningar, variabelgrupper. Det finns två typer av identiteter som en pipeline kan använda: en på projektnivå en och en samlingsnivå. Den förra ger bättre säkerhet, den senare ger enkel användning. Läs mer om begränsade byggidentiteter och omfång för jobbauktorisering.

Vi rekommenderar att du använder identiteter på projektnivå för att köra dina pipelines. Som standard kan identiteter på projektnivå bara komma åt resurser i projektet som de är medlemmar i. Att använda den här identiteten förbättrar säkerheten eftersom det minskar den åtkomst som en obehörig person får när du kapar din pipeline.

Om du vill att din pipeline ska använda en identitet på projektnivå aktiverar du inställningen Begränsa jobbauktoriseringsomfång till aktuellt projekt för pipelines som inte släpps.

När den här växlingsknappen är inaktiverad i vårt exempel kan pipelinen SpaceGameWeb komma åt alla lagringsplatser i alla projekt. När växlingsknappen är på SpaceGameWeb kan du bara komma åt resurser i fabrikam-tailspin/SpaceGameWeb projektet, så endast lagringsplatserna SpaceGameWeb och SpaceGameWebReact .

Om du kör vår exempelpipeline, när du aktiverar växlingsknappen, misslyckas pipelinen och felloggarna meddelar dig 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. och 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ölj stegen som beskrivs i Grundläggande process för att åtgärda utcheckningsproblemen.

Dessutom måste du uttryckligen checka ut undermodullagringsplatserna före de lagringsplatser som använder dem. I vårt exempel innebär det lagringsplatsen FabrikamFiberLib .

Om du nu kör vår exempelpipeline kommer den att lyckas.

Ytterligare konfiguration

Om du vill förbättra säkerheten ytterligare vid åtkomst till Azure Repos kan du överväga att aktivera inställningen Skydda åtkomst till lagringsplatser i YAML-pipelines .

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

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

Klassiska versionspipelines

Processen för att skydda åtkomst till lagringsplatser för versionspipelines liknar den för bygg-pipelines.

För att illustrera de steg du behöver vidta använder vi ett exempel som körs. I vårt exempel finns det en versionspipeline med namnet FabrikamFiberDocRelease i fabrikam-tailspin/FabrikamFiberDocRelease projektet. Anta att pipelinen checkar ut FabrikamFiber lagringsplatsen i fabrikam-tailspin/FabrikamFiber projektet, kör ett kommando för att generera offentlig dokumentation och publicerar den sedan på en webbplats. Tänk dig dessutom att lagringsplatsen FabrikamFiber använder FabrikamFiberLib lagringsplatsen (i samma projekt) som en undermodul

Använda en projektbaserad byggidentitet för klassiska versionspipelines

När en pipeline körs använder den en identitet för att komma åt olika resurser, till exempel lagringsplatser, tjänstanslutningar, variabelgrupper. Det finns två typer av identiteter som en pipeline kan använda: en på projektnivå en och en samlingsnivå. Den förra ger bättre säkerhet, den senare ger enkel användning. Läs mer om begränsade byggidentiteter och omfång för jobbauktorisering.

Vi rekommenderar att du använder identiteter på projektnivå för att köra dina pipelines. Som standard kan identiteter på projektnivå bara komma åt resurser i projektet som de är medlemmar i. Att använda den här identiteten förbättrar säkerheten eftersom det minskar den åtkomst som en obehörig person får när du kapar din pipeline.

Om du vill att pipelinen ska använda en identitet på projektnivå aktiverar du inställningen Begränsa jobbauktorisering till aktuellt projekt för versionspipelines .

När den här växlingsknappen är avstängd FabrikamFiberDocRelease i vårt exempel kan versionspipelinen komma åt alla lagringsplatser i alla projekt, inklusive lagringsplatsen FabrikamFiber . När växlingsknappen är på FabrikamFiberDocRelease kan du bara komma åt resurser i fabrikam-tailspin/FabrikamFiberDocRelease projektet, så lagringsplatsen FabrikamFiber blir otillgänglig.

Om du kör vår exempelpipeline misslyckas pipelinen när du aktiverar växlingsknappen och loggarna meddelar dig 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ölj stegen i Basic-processen för att åtgärda dessa problem.

Om du nu kör vår exempelpipeline kommer den att lyckas.

Se även

• Begränsade byggidentiteter
• Omfång för jobbauktorisering
• Bevilja en pipelines byggidentitet åtkomst till ett projekt
• Bevilja en pipelines byggidentitet läsbehörighet till en lagringsplats
• Så här checkar du ut undermoduler