Azure Pipelines - Sprint 227-update
Functies
Federatie van workloadidentiteit in Azure Pipelines (openbare preview)
Pijplijnagents kunnen worden geregistreerd met behulp van Microsoft Entra-id in plaats van een PAT
Federatie van workloadidentiteit in Azure Pipelines (openbare preview)
Wilt u stoppen met het opslaan van geheimen en certificaten in Azure-serviceverbindingen? Wilt u stoppen met het roteren van deze geheimen wanneer ze verlopen? We kondigen nu een openbare preview aan van workloadidentiteitsfederatie voor Azure-serviceverbindingen. Federatie van workloadidentiteiten maakt gebruik van een industriestandaard technologie, Open ID Verbinding maken (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. Als u overschakelt naar workloadidentiteitsfederatie, hoeft u deze geheimen niet te beheren en verbetert u de algehele ervaring van het maken en beheren van serviceverbindingen.
- Verbeterde beveiliging: Met federatie van workloadidentiteit is er geen permanent geheim betrokken bij de communicatie tussen Azure Pipelines en Azure. Als gevolg hiervan kunnen taken die worden uitgevoerd in pijplijntaken, 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 één voor één verbinding 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 van Marketplace of een aangepaste taak voor thuisgebruik gebruikt om te implementeren in Azure, biedt dit mogelijk nog geen ondersteuning voor federatie van workloadidentiteitsidentiteiten. 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 pijplijnagent ondersteunt nu meer argumenten om een service-principal of een gebruiker te gebruiken om een agent te registreren. U moet de identiteit die wordt gebruikt toegang verlenen tot de agentgroep 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 omgeving is een verzameling resources die u kunt richten op implementaties vanuit een pijplijn. Omgevingen bieden u de implementatiegeschiedenis, traceerbaarheid voor werkitems en doorvoeringen en mechanismen voor toegangsbeheer.
We weten dat u programmatisch omgevingen wilt maken, dus hebben we documentatie gepubliceerd voor hun REST API.
Onbedoelde pijplijnuitvoeringen voorkomen
Als uw YAML-pijplijn momenteel geen sectie opgeeft trigger , wordt deze uitgevoerd voor wijzigingen die naar de opslagplaats zijn gepusht. Dit kan verwarring veroorzaken over de reden waarom een pijplijn is uitgevoerd en leidt 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 activeren als hun triggersectie ontbreekt.
GitHub-opslagplaatsen veilig bouwen
Laatste sprint hebben we een gecentraliseerd besturingselement geïntroduceerd voor het bouwen van PULL's vanuit geforkte GitHub-opslagplaatsen.
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.
Uitgeschakelde onderdrukking van de status van het codedekkingsbeleid op 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 obstakel voor sommigen van u die de build als een optionele controle hadden en het codedekkingsbeleid als een vereiste controle voor PULL's, waardoor PULL's worden geblokkeerd.
Met deze sprint wordt het codedekkingsbeleid niet overschreven naar Mislukt als de build mislukt. Deze functie wordt ingeschakeld voor alle klanten.
Volgende stappen
Notitie
Deze functies worden de komende twee tot drie weken uitgerold.
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.