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

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

Dina lagringsplatser är viktiga för din affärsframgång eftersom de rymmer den kod som driver din verksamhet. Åtkomst till lagringsplatser bör kontrolleras noggrant. Den här artikeln beskriver hur du förbättrar säkerheten för bygg-pipeline och klassisk versionspipeline vid åtkomst till Azure Repos för att minska risken för obehörig åtkomst.

Aktivera följande reglage för att säkerställa säker åtkomst till Azure-lagringsplatser:

• Begränsa omfånget för jobbauktorisering till aktuellt projekt för pipelines som inte släpps
• Begränsa jobbauktoriseringsomfånget till aktuellt projekt för versionspipelines
• Skydda åtkomsten till lagringsplatser i YAML-pipelines

Basic-processen

Följande steg för att skydda dina pipelines liknar alla pipelines:

1. Identifiera de Azure Repos-lagringsplatser som din pipeline kräver åtkomst till inom samma organisation men i olika projekt.
   Gör det genom att inspektera pipelinen eller aktivera Begränsa jobbets auktoriseringsomfång 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. Ge pipelinens byggidentitet åtkomst till projektet för varje projekt som innehåller en lagringsplats som din pipeline behöver åtkomst till.
3. Ge pipelinens byggidentitet läsbehörighet till lagringsplatsen för varje lagringsplats som pipelinen checkar ut.
4. Ge pipelinens byggidentitet läsbehörighet till lagringsplatsen för varje lagringsplats som används som en undermodul av en lagringsplats som pipelinen checkar ut och finns i samma projekt.
5. Aktivera Begränsa omfånget för jobbauktorisering till aktuellt projekt för pipelines som inte släpps, Begränsa omfånget för jobbauktorisering till aktuellt projekt för versionspipelines och Skydda åtkomsten till lagringsplatser i YAML-pipelines.

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 följande exempel.

• Anta att du arbetar med pipelinen SpaceGameWeb som finns i fabrikam-tailspin/SpaceGameWeb projektet på SpaceGameWeb Azure Repos-lagringsplatsen.
• Din SpaceGameWeb pipeline checkar ut lagringsplatsen SpaceGameWebReact i samma projekt och lagringsplatserna FabrikamFiber och FabrikamChat i fabrikam-tailspin/FabrikamFiber projektet.
• Lagringsplatsen FabrikamFiber använder lagringsplatsen FabrikamFiberLib som en undermodul som finns i samma projekt.
• 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

Under pipelinekörningen används en identitet för att komma åt resurser, till exempel lagringsplatser, tjänstanslutningar och variabelgrupper. Pipelines kan använda två typer av identiteter: projektnivå och samlingsnivå. Den förstnämnda prioriterar säkerhet, medan den senare betonar användarvänlighet. Mer information finns i omfångsbegränsade byggidentiteter och jobbauktoriseringsomfång.

För förbättrad säkerhet använder du identiteter på projektnivå när du kör dina pipelines. Dessa identiteter kan bara komma åt resurser i deras associerade projekt, vilket minimerar risken för obehörig åtkomst av skadliga aktörer.

Om du vill konfigurera din pipeline för att använda en identitet på projektnivå aktiverar du inställningen Begränsa jobbauktorisering 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 berättar för 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 avsnittet Grundläggande process i den här artikeln för att åtgärda utcheckningsproblemen.

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

Om du kör vår exempelpipeline lyckas den.

Ytterligare konfiguration

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

YAML-pipelines

Anta att pipelinen SpaceGameWeb är en YAML-pipeline och att dess YAML-källkod liknar följande kod.

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

Skydda åtkomsten till lagringsplatser i YAML-pipelines

Azure DevOps tillhandahåller en detaljerad behörighetsmekanism för Azure Repos-lagringsplatser i form av inställningen Skydda åtkomst till lagringsplatser i YAML-pipelines . Den här inställningen gör att en YAML-pipeline uttryckligen ber om behörighet att komma åt alla Azure Repos-lagringsplatser, oavsett vilket projekt de tillhör. Mer information finns i åtkomstdatabaser. Den här inställningen påverkar inte att checka ut andra typer av lagringsplatser, till exempel GitHub-värdbaserade.

När den här inställningen är aktiverad i vårt exempel ber pipelinen SpaceGameWeb om behörighet att komma åt SpaceGameWebReact lagringsplatsen i fabrikam-tailspin/SpaceGameWeb projektet och FabrikamFiber lagringsplatserna och FabrikamChat i fabrikam-tailspin/FabrikamFiber projektet.

När du kör exempelpipelinen bygger den på ett liknande sätt som i följande exempel.

Bevilja behörighet till dina pipelinelagringsplatser eller resurser.

Din pipeline körs, men misslyckas eftersom den inte kan checka ut lagringsplatsen FabrikamFiberLib som en undermodul av FabrikamFiber. Lös problemet genom att uttryckligen ta en titt på FabrikamFiberLib, genom att lägga till ett - checkout: git://FabrikamFiber/FabrikamFiberLib steg före steget -checkout: FabrikamFiber .

Exempelpipelinen lyckas.

Vår sista YAML-pipeline källkod ser ut som följande kodfragment.

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

Felsökning

Använd följande lösningar för eventuella problem som uppstår.

Du använder git på kommandoraden för att checka ut lagringsplatser i samma organisation

Du använder - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/till exempel . Kommandot misslyckas när inställningen Skydda åtkomst till lagringsplatser i YAML-pipelines är aktiverad.

Lös problemet genom att checka ut lagringsplatsen OtherRepo med kommandot checkout , till exempel - checkout: git://FabrikamFiber/OtherRepo.

En lagringsplats använder en annan lagringsplats som undermodul

Anta att en av lagringsplatserna som din pipeline checkar ut använder en annan lagringsplats (i samma projekt) som undermodul, vilket är fallet i vårt exempel för lagringsplatserna FabrikamFiber och FabrikamFiberLib . Läs mer om hur du checkar ut undermoduler.

Anta dessutom att du gav byggidentiteten SpaceGame läsbehörighet till den här lagringsplatsen, men att utcheckningen av FabrikamFiber lagringsplatsen fortfarande misslyckas när du checkar ut undermodulen FabrikamFiberLib .

Lös problemet genom att uttryckligen FabrikamFiberLibkolla in , genom att lägga till ett - checkout: git://FabrikamFiber/FabrikamFiberLib steg före det -checkout: FabrikamFiber .

Klassiska byggpipelines

I klassiska byggpipelines kan du inte uttryckligen deklarera andra lagringsplatser som resurser. Kolla in fler Azure Repos-lagringsplatser genom att lägga till kommandoradsuppgifter med git clone kommandon, ungefär som följande kommando för att kolla in FabrikamFiber lagringsplatsen: git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --recurse-submodules https://dev.azure.com/silviuandrica/FabrikamFiber/_git/FabrikamFiber.

Inställningen Skydda åtkomst till lagringsplatser i YAML-pipelines

Inställningen Skydda åtkomst till lagringsplatser i YAML-pipelines gör att en YAML-pipeline uttryckligen ber om behörighet att komma åt alla Azure Repos-lagringsplatser, oavsett vilket projekt de tillhör. Mer information finns i Åtkomsttoken, Skydda åtkomst till lagringsplatser i YAML-pipelines.

Var försiktig när du aktiverar inställningen Skydda åtkomst till lagringsplatser i YAML-pipelines . Om du gör det kan dina klassiska byggpipelines inte komma åt någon annan Azure DevOps-lagringsplats, förutom den som anges i dess inställningar. I vår exempelpipeline får du ett fel och loggmeddelandet TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Om projektet använder både YAML- och klassiska byggpipelines och dina klassiska byggpipelines kan du kolla in fler Azure DevOps-lagringsplatser utöver de som anges i deras inställningar, skapa två projekt, ett för YAML-pipelines och ett för klassiska byggpipelines. Aktivera sedan önskad inställning i YAML-pipelines-projektet.

Inställningen Skydda åtkomst till lagringsplatser i YAML-pipelines gäller inte för lagringsplatser som finns på andra tjänster, till exempel GitHub.

Omfångsinställningen Skapa jobbauktorisering

Inställningen Begränsa jobbauktoriseringsomfånget till det aktuella projektet för pipelines som inte släpps åsidosätter inställningen Omfång för byggjobbauktorisering . Om du aktiverar det förstnämnda körs pipelinen med projektbaserad identitet, även om omfånget För att skapa jobbauktorisering anger Project-samling.

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. Det 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, när du aktiverar växlingsknappen, misslyckas pipelinen och loggarna visar 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 avsnittet Grundläggande process i den här artikeln för att åtgärda dessa problem.

Vår exempelpipeline lyckas.

Relaterade artiklar

• 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