Förbättrad säkerhetshantering
Med den här uppdateringen har du nu möjlighet att aktivera eller inaktivera Avancerad säkerhet för hela projektet eller organisationen. Du kan också automatiskt aktivera Advanced Security för alla nyligen skapade lagringsplatser eller projekt.
I Azure Pipelines har vi lagt till en centraliserad kontroll för att förbättra säkerheten för pull-begäranden som skapats från förgrenade GitHub-lagringsplatser.
Läs viktig information om du vill veta mer om de här funktionerna.
Allmänt
Aktivering på projekt- och organisationsnivå för Avancerad säkerhet
Beräknat antal incheckningar under aktivering av avancerad säkerhet
Azure-pipelines
Azure-lagringsplatser
Azure Artifacts
Allmänt
Aktivering på projekt- och organisationsnivå för Avancerad säkerhet
Nu kan du aktivera eller inaktivera Avancerad säkerhet för hela projektet eller organisationen. I kombination med det nya tillägget för att visa antal incheckningar före aktivering ger val av "Aktivera alla" på projekt- eller organisationsnivå en uppskattning av hur många nya aktiva incheckningar du kan debiteras för. Du kan också välja att automatiskt aktivera Avancerad säkerhet för alla nyligen skapade lagringsplatser eller projekt under ditt respektive projekt eller din organisation. Alla lagringsplatser som aktiveras via den här inställningen har hemlig genomsökning av lagringsplatsen och push-skydd aktivt.
Aktivering på projektnivå:
Aktivering på organisationsnivå:
Beräknat antal incheckningar under aktivering av avancerad säkerhet
Som en del av integreringen av Advanced Security kan du nu se en uppskattning av hur många aktiva incheckningar som kan ha lagts till som ett resultat av aktivering av Avancerad säkerhet för en viss lagringsplats, ett visst projekt eller en viss organisation. Det här antalet är en uppskattning och du kan se små skillnader mellan den angivna uppskattningen och vad som rapporteras för fakturering efter aktiveringen. Den här uppskattningen kan också hämtas via API med ytterligare dokumentation som förklarar att den här processen kommer snart.
Azure-pipelines
Försök igen när godkännanden och tidsgränsen för checkar ut
När tidsgränsen för godkännanden och checkar ut hoppas över den fas som de tillhör. Faser som är beroende av den överhoppade fasen hoppas också över.
Nu kan du försöka igen när godkännanden och kontrollerar tidsgränsen. Tidigare var detta bara möjligt när ett godkännande överse.
Administratörsroll för alla miljöer
Miljöer i YAML-pipelines representerar en beräkningsresurs som du distribuerar ditt program till, till exempel ett AKS-kluster eller en uppsättning virtuella datorer. De ger dig säkerhetskontroller och spårbarhet för dina distributioner.
Det kan vara svårt att hantera miljöer. Detta beror på att när en miljö skapas blir den person som skapar den automatiskt den enda administratören. Om du till exempel vill hantera godkännanden och kontroller av alla miljöer på ett centraliserat sätt var du tvungen att be varje miljöadministratör att lägga till en specifik användare eller grupp som administratör och sedan använda REST API för att konfigurera kontrollerna. Den här metoden är omständlig, felbenägen och skalas inte när nya miljöer läggs till.
I den här sprinten har vi lagt till en administratörsroll på nivån environments-hub. Detta gör att miljöer är i nivå med tjänstanslutningar eller agentpooler. Om du vill tilldela rollen Administratör till en användare eller grupp måste du redan vara administratör för miljöhubben eller organisationsägare.
En användare med den här administratörsrollen kan administrera behörigheter, hantera, visa och använda valfri miljö. Detta inkluderar att öppna miljöer för alla pipelines.
När du beviljar en användaradministratörsroll på miljö-hubbnivå blir de administratörer för alla befintliga miljöer och för framtida miljöer.
Centraliserad kontroll för att skapa PULL-begäran från förgrenade GitHub-lagringsplatser
Om du skapar offentliga lagringsplatser från GitHub måste du överväga din inställning till förgreningsversioner. Gafflarna är särskilt farliga eftersom de kommer utanför organisationen.
Du kan förbättra säkerheten för pipelines som skapar offentliga GitHub-lagringsplatser genom att granska våra rekommendationer om hur du skapar GitHub-lagringsplatser och lagringsplatsskydd. Tyvärr kan det krävas mycket arbete för att hantera flera pipelines och se till att de följer bästa praxis.
För att förbättra säkerheten för dina pipelines har vi lagt till en kontroll på organisationsnivå för att definiera hur pipelines skapar PR från förgrenade GitHub-lagringsplatser. Den nya inställningen heter Limit building pull requests from forked GitHub repositories (Begränsa hämtningsbegäranden från förgrenade GitHub-lagringsplatser ) och fungerar på organisations- och projektnivå.
Inställningen på organisationsnivå begränsar vilka inställningar projekt kan ha och inställningen på projektnivå begränsar vilka inställningar pipelines kan ha.
Nu ska vi titta på hur växlingsknappen fungerar på organisationsnivå. Den nya kontrollen är inaktiverad som standard, så inga inställningar tillämpas universellt.
När du aktiverar växlingsknappen kan du välja att inaktivera skapande av pull-begäran från förgrenade GitHub-lagringsplatser. Det innebär att ingen pipeline körs när en sådan pull-begäran skapas.
När du väljer alternativet Skapa pull-begäranden på ett säkert sätt från förgrenade lagringsplatser kan inte alla pipelines, i hela organisationen, göra hemligheter tillgängliga för versioner av PULL-begäranden från förgrenade lagringsplatser, inte göra att dessa versioner har samma behörigheter som vanliga byggen och måste utlösas av en PR-kommentar. Projekt kan fortfarande välja att inte tillåta pipelines att skapa sådana PR.
När du väljer alternativet Anpassa kan du definiera hur du begränsar pipelineinställningarna. Du kan till exempel se till att alla pipelines kräver en kommentar för att skapa en pull-begäran från en förgrenad GitHub-lagringsplats, när pull-begäran tillhör icke-teammedlemmar och icke-deltagare. Men du kan välja att låta dem göra hemligheter tillgängliga för sådana versioner. Projekt kan välja att inte tillåta att pipelines skapar sådana pull-flöden, skapar dem på ett säkert sätt eller har ännu mer restriktiva inställningar än vad som anges på organisationsnivå.
Azure-lagringsplatser
Ny "grenprincip" hindrar användare från att godkänna sina egna ändringar
För att förbättra kontrollen kring vilka ändringar som användaren godkänner och matchar strängare regel-/efterlevnadskrav tillhandahåller vi ett alternativ för att förhindra att användaren godkänner sina egna ändringar om det inte uttryckligen tillåts.
Användare med möjlighet att hantera förgreningsprinciper kan nu växla det nyligen tillagda alternativet "Kräv minst ett godkännande för varje iteration" under "När nya ändringar skickas". När det här alternativet väljs krävs minst en godkännanderöst för den senaste ändringen av källgrenen. Användarens godkännande räknas inte mot någon tidigare icke-godkänd iteration som push-överförts av användaren. Därför krävs ytterligare godkännande för den senaste iterationen för att göras av en annan användare.
Följande bild visar pull-begäran som skapats av användare A och ytterligare 4 incheckningar (iterationer) som gjorts till pull-begäran av användarna B, C, A igen och C. När den andra iterationen (incheckning som utförts av användare B) var klar godkände användaren C detta. Vid den tidpunkten innebar det godkännande av den första incheckningen av användare A (när pull-begäran skapades) och den nyligen introducerade principen kommer att lyckas. Efter den femte iterationen (senaste incheckning av användare C) gjordes godkännandet av användare A. Detta underförstådda godkännande för tidigare incheckning som utförts av användare C, men innebar inte godkännande för den andra incheckningen som utförts av användare A i den fjärde iterationen. För att den nyligen introducerade principen ska lyckas måste den icke godkända iterationen fyra godkännas antingen genom godkännande från användare B, C eller någon annan användare som inte har gjort några ändringar i pull-begäran.
Azure Artifacts
Introduktion till Azure Artifacts-stöd för Cargo Crates (offentlig förhandsversion)
Vi är glada över att kunna meddela att Azure Artifacts nu erbjuder inbyggt stöd för Cargo-crates. Det här stödet omfattar funktionsparitet med avseende på våra befintliga protokoll, förutom att crates.io är tillgänglig som en överordnad källa. Rust-utvecklare och team kan nu använda, publicera, hantera och dela sina Cargo-crates sömlöst, samtidigt som de använder Azures robusta infrastruktur och håller sig kvar i den välbekanta Azure DevOps-miljön.
Ingen registrering krävs för förhandsversionen. Du kan komma igång genom att gå till ditt Azure DevOps-projekt, välja Artefakter och följa anvisningarna för att ansluta Rust-projektet till azure artifacts-feeden.
Nästa steg
Anteckning
Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.
Gå till Azure DevOps och ta en titt.
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.
Tack,
Silviu Andrica
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för