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:
Basic-processen
Stegen liknar alla pipelines:
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.
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.
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.
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.
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 .
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. Läs mer om den här inställningen. Att checka ut andra typer av lagringsplatser, till exempel GitHub-värdbaserade, påverkas inte av den här inställningen.
När den här växlingsknappen ä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 visas ett bygge som liknar följande skärmbild.
Du uppmanas att bevilja behörighet till de lagringsplatser som din pipeline checkar ut eller har definierat som resurser.
När du gör det körs pipelinen, men den misslyckas eftersom den FabrikamFiberLib inte kan checka ut lagringsplatsen som en undermodul av FabrikamFiber. Lös det här problemet genom att uttryckligen ta en titt på FabrikamFiberLib, till exempel lägga till ett - checkout: git://FabrikamFiber/FabrikamFiberLib steg före -checkout: FabrikamFiber steget.
Om du nu kör exempelpipelinen kommer den att 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
Här är ett par problematiska situationer och hur du hanterar dem.
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 växlingsknappen Skydda åtkomst till lagringsplatser i YAML-pipelines är aktiverad.
Du kan lösa problemet genom att checka ut OtherRepo lagringsplatsen med hjälp av checkout kommandot, - checkout: git://FabrikamFiber/OtherRepotill exempel .
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 SpaceGamelä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 ta en titt på FabrikamFiberLib, till exempel lägga till ett - checkout: git://FabrikamFiber/FabrikamFiberLib steg före det -checkout: FabrikamFiber .
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.