Federatie van workloadidentiteit voor openbare preview van Azure Pipelines

We zijn verheugd aan te kondigen dat workloadidentiteitsfederatie voor Azure Pipelines nu beschikbaar is als openbare preview! Azure-serviceverbindingen (ARM) zijn bijgewerkt met een extra schema ter ondersteuning van workloadidentiteitsfederatie.

Bekijk de releaseopmerkingen voor meer informatie over hoe u zich kunt registreren voor de openbare preview.

Azure Boards

• limieten voor gebieds- en iteratiepaden

Azure-pipelines

• Federatie van workloadidentiteit in Azure Pipelines (publieke preview)

• Pijplijnagents kunnen worden geregistreerd met behulp van Microsoft Entra-id in plaats van een PAT

• REST API's voor omgevingen

• Onbedoelde pijplijnuitvoeringen voorkomen

• GitHub-opslagplaatsen standaard veilig bouwen

• Uitgeschakelde overschrijving van de status van het codedekkingsbeleid naar Mislukt als de build faalt

Azure Repos

• Ondersteuning voor blobloze en boomloze filters

Azure Boards

Limieten voor gebieds- en iteratiepaden

Limieten spelen een belangrijke rol bij het handhaven van de gezondheid en efficiëntie van een grote, wereldwijde service. In deze sprint introduceren we vaste limieten van 10.000 per project voor zowel gebieds- als iteratiepaden. Ga naar de pagina Werktracking, proces en projectlimieten voor meer informatie over verschillende limieten in de service.

Azure-pipelines

Workload-identiteitsfederatie in Azure Pipelines (publieke preview)

Wilt u stoppen met het opslaan van geheimen en certificaten in Azure-serviceverbindingen? Wilt u stoppen met u zorgen maken over het roteren van deze inloggegevens zodra ze verlopen? We kondigen nu een openbare preview aan van federatie van workloadidentiteit voor Azure-serviceverbindingen. Federatie van workloadidentiteiten maakt gebruik van een industriestandaardtechnologie, Open ID Connect (OIDC), om de verificatie tussen Azure Pipelines en Azure te vereenvoudigen. In plaats van geheimen wordt een federatieonderwerp gebruikt om deze verificatie te vergemakkelijken.

Als onderdeel van deze functie is de Azure-serviceverbinding (ARM) bijgewerkt met een ander schema ter ondersteuning van workloadidentiteitsfederatie. Hierdoor kunnen pijplijntaken die gebruikmaken van de Azure-serviceverbinding, worden geverifieerd met behulp van een federatieonderwerp (sc://<org>/<project>/<service connection name>). De belangrijkste voordelen van het gebruik van dit schema ten opzichte van bestaande verificatieschema's zijn als volgt:

• Vereenvoudigd beheer: u hoeft geen geheimen meer te genereren, te kopiëren en op te slaan van service-principals in Azure AD naar Azure DevOps. Geheimen die worden gebruikt in andere verificatieschema's van Azure-serviceverbindingen (bijvoorbeeld service-principal) verlopen na een bepaalde periode (momenteel twee jaar). Wanneer ze verlopen, mislukken pijplijnen. U moet een nieuw geheim opnieuw genereren en de serviceverbinding bijwerken. Door over te schakelen op workload-identiteitsfederatie, hoeft u deze geheimen niet meer te beheren en verbetert u de algehele ervaring van het maken en beheren van serviceverbindingen.
• Verbeterde beveiliging: Met federatie van workloadidentiteit is er geen blijvend geheim nodig bij de communicatie tussen Azure Pipelines en Azure. Als gevolg hiervan kunnen taken die in pipelines worden uitgevoerd, geen geheimen lekken of exfiltreren die toegang hebben tot uw productieomgevingen. Dit is vaak een zorg geweest voor onze klanten.

U kunt op twee manieren profiteren van deze functies:

• Gebruik het nieuwe federatieschema voor workloadidentiteit wanneer u een nieuwe Azure-serviceverbinding maakt. In de toekomst is dit het aanbevolen mechanisme.
• Converteer uw bestaande Azure-serviceverbindingen (die zijn gebaseerd op geheimen) naar het nieuwe schema. U kunt deze conversie per verbinding tegelijk uitvoeren. Het beste van alles is dat u geen van de pijplijnen hoeft te wijzigen die gebruikmaken van deze serviceverbindingen. Ze passen het nieuwe schema automatisch toe zodra u de conversie hebt voltooid.

Als u een nieuwe Azure-serviceverbinding wilt maken met behulp van workloadidentiteitsfederatie, selecteert u eenvoudigweg workloadidentiteitsfederatie (automatisch) of (handmatig) in de ervaring voor het maken van een Azure-serviceverbinding:

Als u een eerder gemaakte Azure-serviceverbinding wilt converteren, selecteert u de actie Converteren nadat u de verbinding hebt geselecteerd:

Alle Azure-taken die deel uitmaken van Azure Pipelines ondersteunen nu dit nieuwe schema. Als u echter een taak uit de Marketplace of een zelfontwikkelde aangepaste taak gebruikt om te implementeren in Azure, biedt het mogelijk nog geen ondersteuning voor federatie van workloadidentiteiten. In deze gevallen vragen we u om uw taak bij te werken ter ondersteuning van federatie van workloadidentiteiten om de beveiliging te verbeteren. Hier vindt u een volledige lijst met ondersteunde taken.

Voor deze preview ondersteunen we alleen federatie van workloadidentiteiten voor Azure-serviceverbindingen. Dit schema werkt niet met andere typen serviceverbindingen. Zie onze documenten voor meer informatie.

Dit blogbericht bevat meer informatie.

Pijplijnagents kunnen worden geregistreerd met behulp van Microsoft Entra-id in plaats van een PAT

De Pipeline-agent ondersteunt nu meer argumenten voor het gebruik van een Service Principal of een gebruiker om een agent te registreren. U zou de identiteit die wordt gebruikt toegang moeten verlenen tot de agentenpool in de beveiligingsinstellingen. Hierdoor hoeft u geen persoonlijk toegangstoken (PAT) te gebruiken voor eenmalige installatie van agents.

Een agent registreren met behulp van een service-principal

Als u een service-principal wilt gebruiken om een Pipelines-agent te registreren bij Azure DevOps Services, geeft u de volgende argumenten op:

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

Een service-principal gebruiken in de agent-VM-extensie

Virtuele Azure-machines kunnen worden opgenomen in implementatiegroepen met behulp van een VM-extensie. De VM-extensie is bijgewerkt om een service-principal te gebruiken in plaats van een PAT om de agent te registreren:

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

Een agent interactief registreren met behulp van apparaatcodestroom

U kunt een webbrowser gebruiken om de installatie eenvoudig te voltooien. Wanneer u het agentconfiguratiescript uitvoert, voert u AAD in voor het verificatietype. Het script begeleidt u bij de volgende stappen, waaronder waar u op internet kunt gaan en welke code u moet invoeren. Nadat u de code op internet hebt ingevoerd, gaat u terug naar de console om het instellen van de agent te voltooien.

REST API's voor omgevingen

Een Environment is een verzameling resources waarnaar u implementaties vanuit een pijplijn kunt richten. Omgevingen bieden u de implementatiegeschiedenis, traceerbaarheid voor werkitems en doorvoeringen en mechanismen voor toegangsbeheer.

Wij weten dat u omgevingen programmatischwilt maken, dus hebben we documentatie gepubliceerd voor de REST API.

Onbedoelde pijplijnuitvoeringen voorkomen

Als uw YAML-pijplijn vandaag geen trigger sectie opgeeft, wordt deze uitgevoerd voor alle wijzigingen die naar de opslagplaats zijn gepusht. Dit kan verwarring veroorzaken over waarom een pijplijn is uitgevoerd en kan leiden tot veel onbedoelde uitvoeringen.

We hebben een instelling pijplijnen op organisatie- en projectniveau toegevoegd met de naam Impliciete YAML CI-trigger uitschakelen waarmee u dit gedrag kunt wijzigen. U kunt ervoor kiezen om pijplijnen niet te starten als de triggersectie ontbreekt.

GitHub-opslagplaatsen standaard veilig creëren

Tijdens de laatste sprint hebben we een gecentraliseerd besturingselement geïntroduceerd voor het bouwen van pull requests vanuit geforkte GitHub-repositories.

Met deze sprint schakelen we de Securely build pull requests from forked repositories optie op organisatieniveau in voor nieuwe organisaties. Bestaande organisaties worden niet beïnvloed.

Uitschakelen van het overschrijven van de status van het code-dekkingsbeleid naar Mislukt wanneer de build mislukt

Voorheen werd de status van het codedekkingsbeleid overschreven naar 'Mislukt' als uw build in pull-aanvraag mislukte. Dit was een blokkade voor sommigen van jullie die de build als een optionele controle hadden en het codedekkingsbeleid als een verplichte controle voor PR's, resulterend in PR's die worden geblokkeerd.

Met deze sprint wordt het codedekkingsbeleid niet gewijzigd naar 'Mislukt' indien de build mislukt. Deze functie wordt ingeschakeld voor alle klanten.

Azure Repos

Ondersteuning voor filter zonder blob en zonder boomstructuur

Azure DevOps ondersteunt nu twee extra filters tijdens het klonen/ophalen. Hieronder vallen: --filter=blob:none en --filter=tree:0 De eerste optie (blobloze kloon) wordt het beste gebruikt voor regelmatige ontwikkeling, terwijl de tweede optie (boomloze kloon) beter geschikt is voor die gevallen waarin u de kloon verwijdert, bijvoorbeeld na het uitvoeren van een build.

Volgende stappen

Ga naar Azure DevOps en kijk eens.

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Bedankt

Gepleiu Andrica