Azure Pipelines – Sprint 227-uppdatering

Funktioner

• Arbetsbelastningsidentitetsfederation i Azure Pipelines (offentlig förhandsversion)

• Pipelineagenter kan registreras med Microsoft Entra-ID i stället för en PAT

• REST-API:er för miljöer

• Förhindra oavsiktliga pipelinekörningar

• Skapa GitHub-lagringsplatser på ett säkert sätt som standard

• Inaktiverad åsidosättning av kodtäckningsprincipens status till Misslyckades när bygget misslyckas

Arbetsbelastningsidentitetsfederation i Azure Pipelines (offentlig förhandsversion)

Vill du sluta lagra hemligheter och certifikat i Azure-tjänstanslutningar? Vill du sluta oroa dig för att rotera dessa hemligheter när de upphör att gälla? Nu presenterar vi en offentlig förhandsversion av arbetsbelastningsidentitetsfederationen för Azure-tjänstanslutningar.Arbetsbelastningsidentitetsfederationen använder en branschstandardteknik, Open ID Anslut (OIDC), för att förenkla autentiseringen mellan Azure Pipelines och Azure. I stället för hemligheter används ett federationsämne för att underlätta den här autentiseringen.

Som en del av den här funktionen har Azure-tjänstanslutningen (ARM) uppdaterats med ett annat schema för att stödja arbetsbelastningsidentitetsfederation. På så sätt kan Pipeline-uppgifter som använder Azure-tjänstanslutningen autentiseras med hjälp av ett federationsämne (sc://<org>/<project>/<service connection name>). De största fördelarna med att använda det här schemat jämfört med befintliga autentiseringsscheman är följande:

• Förenklad hantering: Du behöver inte längre generera, kopiera och lagra hemligheter från tjänstens huvudnamn i Azure AD till Azure DevOps. Hemligheter som används i andra autentiseringsscheman för Azure-tjänstanslutningar (t.ex. tjänstens huvudnamn) upphör att gälla efter en viss period (för närvarande två år). När de upphör att gälla misslyckas pipelines. Du måste återskapa en ny hemlighet och uppdatera tjänstanslutningen. Om du byter till arbetsbelastningsidentitetsfederation eliminerar du behovet av att hantera dessa hemligheter och förbättrar den övergripande upplevelsen av att skapa och hantera tjänstanslutningar.
• Förbättrad säkerhet: Med arbetsbelastningsidentitetsfederation finns det ingen beständiga hemlighet som är involverad i kommunikationen mellan Azure Pipelines och Azure. Därför kan uppgifter som körs i pipelinejobb inte läcka eller exfiltra hemligheter som har åtkomst till dina produktionsmiljöer. Detta har ofta varit ett bekymmer för våra kunder.

Du kan dra nytta av dessa funktioner på två sätt:

• Använd det nya identitetsfederationsschemat för arbetsbelastningar när du skapar en ny Azure-tjänstanslutning. Framöver kommer detta att vara den rekommenderade mekanismen.
• Konvertera dina befintliga Azure-tjänstanslutningar (som baseras på hemligheter) till det nya schemat. Du kan utföra den här konverteringen en anslutning i taget. Bäst av allt är att du inte behöver ändra någon av de pipelines som använder dessa tjänstanslutningar. De tillämpar automatiskt det nya schemat när du har slutfört konverteringen.

Om du vill skapa en ny Azure-tjänstanslutning med hjälp av arbetsbelastningsidentitetsfederation väljer du helt enkelt Arbetsbelastningsidentitetsfederation (automatisk) eller (manuell) i azure-tjänstens anslutningsupplevelse:

Om du vill konvertera en tidigare skapad Azure-tjänstanslutning väljer du åtgärden "Konvertera" när du har valt anslutningen:

Alla Azure-uppgifter som ingår i Azure Pipelines stöder nu det här nya schemat. Men om du använder en uppgift från Marketplace eller en egen anpassad uppgift för att distribuera till Azure kanske den inte har stöd för arbetsbelastningsidentitetsfederation ännu. I dessa fall ber vi dig att uppdatera din uppgift för att stödja arbetsbelastningsidentitetsfederation för att förbättra säkerheten. En fullständig lista över aktiviteter som stöds finns här.

För den här förhandsversionen stöder vi endast arbetsbelastningsidentitetsfederation för Azure-tjänstanslutningar. Det här schemat fungerar inte med andra typer av tjänstanslutningar. Mer information finns i våra dokument.

Det här blogginlägget innehåller mer information.

Pipelineagenter kan registreras med Microsoft Entra-ID i stället för en PAT

Pipeline-agenten har nu stöd för fler argument för att använda antingen tjänstens huvudnamn eller en användare för att registrera en agent. Du bör ge den identitet som används åtkomst till agentpoolen i dess säkerhetsinställningar. Detta tar bort behovet av att använda en personlig åtkomsttoken (PAT) för engångskonfiguration av agenter.

Registrera en agent med hjälp av tjänstens huvudnamn

Om du vill använda tjänstens huvudnamn för att registrera en Pipelines-agent med Azure DevOps Services anger du följande argument:

--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee

Använda tjänstens huvudnamn i tillägget för den virtuella agentdatorn

Virtuella Azure-datorer kan ingå i distributionsgrupper med hjälp av ett VM-tillägg. Vm-tillägget har uppdaterats för att använda tjänstens huvudnamn i stället för en PAT för att registrera agenten:

"settings": {
  "userServicePrincipal": true     
}
"protectedSettings": {
  "clientId": "[parameters('clientId')]"      
  "clientSecret": "[parameters('clientSecret')]"      
  "tenantId": "[parameters('tenantId')]"      
}

Registrera en agent interaktivt med hjälp av enhetskodflöde

Du kan använda en webbläsare för att enkelt slutföra installationen. När du kör agentkonfigurationsskriptet anger du "AAD" som autentiseringstyp . Skriptet vägleder dig genom nästa steg, inklusive var du ska gå på webben och vilken kod du ska ange. När du har angett koden på webben går du tillbaka till konsolen för att slutföra konfigurationen av agenten.

REST-API:er för miljöer

En miljö är en samling resurser som du kan rikta in dig på med distributioner från en pipeline. Miljöer ger dig distributionshistorik, spårbarhet för arbetsobjekt och incheckningar samt mekanismer för åtkomstkontroll.

Vi vet att du vill skapa miljöer programmatiskt, så vi publicerade dokumentation för deras REST API.

Förhindra oavsiktliga pipelinekörningar

Om YAML-pipelinen i dag inte anger något trigger avsnitt körs den för ändringar som skickas till dess lagringsplats. Detta kan skapa förvirring om varför en pipeline kördes och ledde till många oavsiktliga körningar.

Vi har lagt till en inställning för pipelines på organisations- och projektnivå med namnet Inaktivera underförstådd YAML CI-utlösare som gör att du kan ändra det här beteendet. Du kan välja att inte utlösa pipelines om deras utlösaravsnitt saknas.

Skapa GitHub-lagringsplatser på ett säkert sätt som standard

Förra sprinten introducerade vi en centraliserad kontroll för att skapa PR från förgrenade GitHub-lagringsplatser.

Med den här sprinten Securely build pull requests from forked repositories aktiverar vi alternativet på organisationsnivå för nya organisationer. Befintliga organisationer påverkas inte.

Inaktiverad åsidosättning av kodtäckningsprincipens status till Misslyckades när bygget misslyckas

Tidigare i åsidosättades statusen för kodtäckningsprincipen till "Misslyckades" om ditt bygge i PR misslyckades. Det här var en blockerare för vissa av er som hade bygget som en valfri kontroll och kodtäckningsprincipen som en nödvändig kontroll för pr-koder, vilket ledde till att PR blockerades.

Med den här sprinten kommer kodtäckningsprincipen inte att åsidosättas till "Failed" om bygget misslyckas. Den här funktionen aktiveras för alla kunder.

Nästa steg

Kommentar

Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.

Gå över till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om de här funktionerna. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.