Share via

Nya principer för personliga åtkomsttoken

  • Artikel

I den här sprinten har vi lagt till nya principer för att begränsa omfattningen och livslängden för personliga åtkomsttoken (PAT). Dessutom uppdaterade vi Windows Shell-tillägget Team Foundation Version Control (TFVC) för att stödja Visual Studio 2019.

Mer information finns i följande funktionsbeskrivningar.

Allmänt

Azure-pipelines

Azure-lagringsplatser

Allmänt

Begränsa omfång och livslängd för personlig åtkomsttoken (PAT) via Azure AD klientprincip

Personliga åtkomsttoken (PAT) gör det enkelt att autentisera mot Azure DevOps för att integrera med dina verktyg och tjänster. Läckta token kan dock äventyra ditt Azure DevOps-konto och dina data, vilket äventyrar dina program och tjänster.

Vi har fått feedback om att administratörer inte har de kontroller som krävs för att begränsa hotytan som orsakas av läckta PAT:er. Baserat på den här feedbacken har vi lagt till en ny uppsättning principer som kan användas för att begränsa omfattningen och livslängden för organisationens personliga åtkomsttoken för Azure DevOps (PAT)! Så här fungerar de:

Användare som har tilldelats rollen Azure DevOps-administratör i Azure Active Directory kan gå till fliken Azure Active Directory i organisationsinställningarna för alla Azure DevOps-organisationer som är länkade till deras Azure AD.

Bild-PAT-kontroller

Där kan administratörer:

  1. Begränsa skapandet av globala personliga åtkomsttoken (token som fungerar för alla Azure DevOps-organisationer som är tillgängliga för användaren)
  2. Begränsa skapandet av personliga åtkomsttoken med fullständigt omfång
  3. Definiera en maximal livslängd för nya personliga åtkomsttoken

Dessa principer gäller för alla nya PAT:n som skapats av användare för Azure DevOps-organisationer som är länkade till Azure AD klientorganisationen. Var och en av principerna har en lista över tillåtna användare och grupper som ska undantas från principen. Listan över användare och grupper i listan Tillåt har inte åtkomst till att hantera principkonfiguration.

Dessa principer gäller endast för nya PAT och påverkar inte befintliga PAT som redan har skapats och som används. När principerna har aktiverats måste dock alla befintliga, nu icke-kompatibla PAT:er uppdateras för att ligga inom begränsningarna innan de kan förnyas.

Stöd för principer för villkorsstyrd åtkomst för IPv6-trafik

Nu utökar vi stöd för principer för villkorsstyrd åtkomst (CAP) till att omfatta IPv6-stängselprinciper. När vi ser att personer i allt högre grad får åtkomst till Azure DevOps-resurser på enheter från IPv6-adresser vill vi se till att dina team är utrustade för att bevilja och ta bort åtkomst från alla IP-adresser, inklusive de som kommer från IPv6-trafik.

Azure-pipelines

Behåll pipelines som används i andra pipelines

Klassiska versioner hade möjlighet att automatiskt behålla byggen som de förbrukar. Detta var en av luckorna mellan klassiska versioner och YAML-pipelines, och det hindrade några av er från att flytta till YAML. Med den här versionen har vi åtgärdat den här klyftan.

Nu kan du skapa en YAML-pipeline i flera steg för att representera din version och använda en annan YAML-pipeline i den som en resurs. När du gör det behåller Azure Pipelines automatiskt resurspipelinen så länge versionspipelinen behålls. När versionspipelinen tas bort släpps lånet på resurspipelinen och dess egna kvarhållningsprinciper följs.

Ändringar i automatisk skapande av miljöer

När du skapar en YAML-pipeline och refererar till en miljö som inte finns skapar Azure Pipelines automatiskt miljön. Den här automatiska genereringen kan ske antingen i användarkontexten eller i systemkontexten. I följande flöden känner Azure Pipelines till användaren som utför åtgärden:

  • Du använder guiden Skapa YAML-pipeline i webbmiljön för Azure Pipelines och refererar till en miljö som inte har skapats ännu.
  • Du uppdaterar YAML-filen med hjälp av webbredigeraren för Azure Pipelines och sparar pipelinen när du har lagt till en referens till en miljö som inte finns.

I vart och ett av ovanstående fall har Azure Pipelines en tydlig förståelse för användaren som utför åtgärden. Därför skapas miljön och användaren läggs till i administratörsrollen för miljön. Den här användaren har alla behörigheter för att hantera miljön och/eller inkludera andra användare i olika roller för att hantera miljön.

I följande flöden har Azure Pipelines inte information om användaren som skapar miljön: du uppdaterar YAML-filen med hjälp av en annan extern kodredigerare, lägger till en referens till en miljö som inte finns och utlöser sedan en manuell eller kontinuerlig integreringspipeline. I det här fallet känner Inte Azure Pipelines till användaren. Tidigare hanterade vi det här ärendet genom att lägga till alla projektdeltagare i miljöns administratörsroll. Alla medlemmar i projektet kunde sedan ändra dessa behörigheter och hindra andra från att komma åt miljön.

Vi fick din feedback om att bevilja administratörsbehörigheter för en miljö till alla medlemmar i ett projekt. När vi lyssnade på din feedback hörde vi att vi inte bör skapa en miljö automatiskt om det inte är klart vem användaren som utför åtgärden är. Med den här versionen har vi gjort ändringar i hur miljöer skapas automatiskt:

  • Framöver skapar pipelinekörningar inte automatiskt en miljö om den inte finns och om användarkontexten inte är känd. I sådana fall misslyckas pipelinen med felet Miljö hittades inte. Du måste skapa miljöerna i förväg med rätt säkerhet och kontrollera konfigurationen innan du använder den i en pipeline.
  • Pipelines med känd användarkontext skapar fortfarande miljöer automatiskt precis som tidigare.
  • Slutligen bör det noteras att funktionen för att automatiskt skapa en miljö bara lades till för att förenkla processen för att komma igång med Azure Pipelines. Den var avsedd för testscenarier och inte för produktionsscenarier. Du bör alltid förskapa produktionsmiljöer med rätt behörigheter och kontroller och sedan använda dem i pipelines.

Ta bort insights-dialog från Build Pipeline

Baserat på din feedback har dialogrutan för uppgift/pipeline Insights som visas när du navigerar i byggpipelinen tagits bort för att förbättra arbetsflödet. Pipelineanalysen är fortfarande tillgänglig så att du får de insikter du behöver.

Azure-lagringsplatser

Uppdateringar till Team Foundation Version Control(TFVC) Windows Shell-tillägg för Visual Studio 2019

Den tidigare versionen av TFVC Windows Shell-tillägget fungerade bara på datorer som hade Visual Studio 2017 installerat.

Vi har släppt en ny version av det här verktyget som är kompatibel med Visual Studio 2019. Tillägget ger integrering med Utforskaren och de vanliga fildialogrutorna. Med den här integreringen kan du utföra många källkontrollåtgärder utan att behöva köra Visual Studio eller ett Team Foundation-kommandoradsverktyg.

Nästa steg

Anteckning

De här funktionerna kommer att lanseras under de kommande två till tre veckorna.

Gå 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 dessa funktioner. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Ge ett förslag

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

Tack,

Vijay Machiraju