Workload identity federation for Azure Pipelines public preview
Wir freuen uns, ihnen mitzuteilen, dass sich der Workload-Identitätsverbund für Azure Pipelines jetzt in der öffentlichen Vorschau befindet! Azure (ARM)-Dienstverbindungen wurden mit einem zusätzlichen Schema aktualisiert, um den Workload-Identitätsverbund zu unterstützen.
Schauen Sie sich die Versionshinweise an, um zu erfahren, wie Sie sich für die öffentliche Vorschau registrieren können.
Azure Boards
Azure Pipelines
Workload-Identitätsverbund in Azure Pipelines (öffentliche Vorschau)
Pipeline-Agents können mithilfe der Microsoft Entra-ID anstelle eines PAT registriert werden.
Azure Repos
Azure Boards
Grenzwerte für Bereiche und Iterationspfade
Beschränkungen spielen eine wichtige Rolle bei der Standard Beibehaltung der Gesundheit und Effizienz eines großen, globalen Dienstes. In diesem Sprint führen wir harte Grenzwerte von 10.000 pro Projekt für Flächen- und Iterationspfade ein. Besuchen Sie die Seite "Work tracking", "Process" und "Project Limits ", um mehr über unterschiedliche Grenzwerte im Dienst zu erfahren.
Azure Pipelines
Workload-Identitätsverbund in Azure Pipelines (öffentliche Vorschau)
Möchten Sie das Speichern von geheimen Schlüsseln und Zertifikaten in Azure-Dienstverbindungen beenden? Möchten Sie sich keine Gedanken mehr machen, diese Geheimnisse zu drehen, wenn sie ablaufen? Wir kündigen nun eine öffentliche Vorschau der Workload Identity Federation für Azure-Dienstverbindungen an.Der Workload-Identitätsverbund verwendet eine Industriestandardtechnologie, Open ID Verbinden (OIDC), um die Authentifizierung zwischen Azure-Pipelines und Azure zu vereinfachen. Anstelle von geheimen Schlüsseln wird ein Verbundbetreff verwendet, um diese Authentifizierung zu erleichtern.
Im Rahmen dieses Features wurde die Azure-Dienstverbindung (ARM) mit einem anderen Schema aktualisiert, um den Workload-Identitätsverbund zu unterstützen. Dies ermöglicht Pipelineaufgaben, die die Azure-Dienstverbindung verwenden, um sich mit einem Partnerverbundbetreff (sc://<org>/<project>/<service connection name>) zu authentifizieren. Die Standard Vorteile dieser Regelung gegenüber vorhandenen Authentifizierungsschemas sind wie folgt:
- Vereinfachte Verwaltung: Sie müssen geheime Schlüssel nicht mehr aus Dienstprinzipalen in Azure AD zu Azure DevOps generieren, kopieren und speichern. Geheime Schlüssel, die in anderen Authentifizierungsschemas von Azure-Dienstverbindungen (z. B. Dienstprinzipal) verwendet werden, laufen nach einem bestimmten Zeitraum (derzeit zwei Jahre) ab. Wenn sie ablaufen, schlagen Pipelines fehl. Sie müssen einen neuen geheimen Schlüssel neu generieren und die Dienstverbindung aktualisieren. Durch den Wechsel zum Arbeitsauslastungsidentitätsverbund wird die Notwendigkeit beseitigt, diese geheimen Schlüssel zu verwalten und die Gesamterfahrung beim Erstellen und Verwalten von Dienstverbindungen zu verbessern.
- Verbesserte Sicherheit: Mit dem Identitätsverbund "Workload" gibt es keinen dauerhaften Geheimschlüssel, der an der Kommunikation zwischen Azure-Pipelines und Azure beteiligt ist. Daher können Aufgaben, die in Pipelineaufträgen ausgeführt werden, geheime Schlüssel, die Zugriff auf Ihre Produktionsumgebungen haben, nicht durchlecken oder exfiltrieren. Dies ist für unsere Kunden oft ein Problem.
Sie können diese Features auf zwei Arten nutzen:
- Verwenden Sie das neue Workload-Identitätsverbundschema , wenn Sie eine neue Azure-Dienstverbindung erstellen. In Zukunft wird dies der empfohlene Mechanismus sein.
- Konvertieren Sie Ihre vorhandenen Azure-Dienstverbindungen (die auf geheimen Schlüsseln basieren) in das neue Schema. Sie können diese Konvertierung jeweils eine Verbindung ausführen. Am besten müssen Sie keine der Pipelines ändern, die diese Dienstverbindungen verwenden. Sie wenden das neue Schema automatisch an, nachdem Sie die Konvertierung abgeschlossen haben.
Wenn Sie eine neue Azure-Dienstverbindung mithilfe des Workload-Identitätsverbunds erstellen möchten, wählen Sie einfach den Workload-Identitätsverbund (automatisch) oder (manuell) in der Azure-Dienstverbindungserstellungsumgebung aus:
Um eine zuvor erstellte Azure-Dienstverbindung zu konvertieren, wählen Sie die Aktion "Konvertieren" aus, nachdem Sie die Verbindung ausgewählt haben:
Alle Azure-Aufgaben, die in Azure-Pipelines enthalten sind, unterstützen jetzt dieses neue Schema. Wenn Sie jedoch eine Aufgabe aus dem Marketplace oder eine hausgemachte benutzerdefinierte Aufgabe für die Bereitstellung in Azure verwenden, wird der Workload-Identitätsverbund möglicherweise noch nicht unterstützt. In diesen Fällen bitten wir Sie, Ihre Aufgabe zu aktualisieren, um den Workloadidentitätsverbund zu unterstützen, um die Sicherheit zu verbessern. Eine vollständige Liste der unterstützten Aufgaben finden Sie hier.
Für diese Vorschau unterstützen wir den Workload-Identitätsverbund nur für Azure-Dienstverbindungen. Dieses Schema funktioniert nicht mit anderen Arten von Dienstverbindungen. Weitere Informationen finden Sie in unseren Dokumenten.
Dieser Blogbeitrag enthält weitere Details.
Pipeline-Agents können mithilfe der Microsoft Entra-ID anstelle eines PAT registriert werden.
Der Pipeline-Agent unterstützt jetzt weitere Argumente, um entweder einen Dienstprinzipal oder einen Benutzer zum Registrieren eines Agents zu verwenden. Sie sollten der Identität den verwendeten Zugriff auf den Agentpool in den Sicherheitseinstellungen gewähren. Dadurch wird die Notwendigkeit entfernt, ein persönliches Zugriffstoken (PERSONAL Access Token, PAT) für die einmalige Einrichtung von Agents zu verwenden.
Registrieren eines Agents mithilfe eines Dienstprinzipals
Um einen Dienstprinzipal zum Registrieren eines Pipeline-Agents bei Azure DevOps Services zu verwenden, stellen Sie die folgenden Argumente bereit:
--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee
Verwenden eines Dienstprinzipals in der Agent-VM-Erweiterung
Azure-VMs können mithilfe einer VM-Erweiterung in Bereitstellungsgruppen eingeschlossen werden. Die VM-Erweiterung wurde aktualisiert, um einen Dienstprinzipal anstelle eines PAT zu verwenden, um den Agent zu registrieren:
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "[parameters('clientId')]"
"clientSecret": "[parameters('clientSecret')]"
"tenantId": "[parameters('tenantId')]"
}
Interaktives Registrieren eines Agents mithilfe des Gerätecodeflusses
Sie können einen Webbrowser verwenden, um die Einrichtung ganz einfach abzuschließen. Wenn Sie das Agentkonfigurationsskript ausführen, geben Sie "AAD" für den Authentifizierungstyp ein. Das Skript führt Sie durch die nächsten Schritte, einschließlich des Speicherorts im Web und dem Code, der eingegeben werden soll. Nachdem Sie Ihren Code im Web eingegeben haben, kehren Sie zur Konsole zurück, um die Einrichtung des Agents abzuschließen.
REST-APIs für Umgebungen
Eine Umgebung ist eine Sammlung von Ressourcen, auf die Sie mit Bereitstellungen aus einer Pipeline abzielen können. Umgebungen bieten Bereitstellungsverlauf, Rückverfolgbarkeit für Arbeitsaufgaben und Commits sowie Zugriffssteuerungsmechanismen.
Wir wissen, dass Sie Umgebungen programmgesteuert erstellen möchten, daher haben wir die Dokumentation für ihre REST-API veröffentlicht.
Verhindern unbeabsichtigter Pipelineausführungen
Wenn Ihre YAML-Pipeline heute keinen Abschnitt angibt trigger , wird er für änderungen ausgeführt, die an das Repository übertragen wurden. Dies kann Verwirrung darüber erzeugen, warum eine Pipeline ausgeführt wurde und zu vielen unbeabsichtigten Läufen führen kann.
Wir haben eine Pipelines-Einstellung auf Organisation und Projektebene namens "Konkludente YAML CI-Trigger deaktivieren" hinzugefügt, mit der Sie dieses Verhalten ändern können. Sie können auswählen, dass Pipelines nicht ausgelöst werden, wenn deren Triggerabschnitt fehlt.
Sicheres Erstellen von GitHub-Repositorys
Im letzten Sprint haben wir ein zentrales Steuerelement zum Erstellen von PRs aus verzweigten GitHub-Repositorys eingeführt.
Mit diesem Sprint aktivieren wir die Securely build pull requests from forked repositories Option auf Organisationsebene für neue Organisationen. Vorhandene Organisationen sind nicht betroffen.
Deaktivierte Außerkraftsetzung des Codeabdeckungsrichtlinienstatus auf "Fehlgeschlagen", wenn der Build fehlschlägt
Zuvor wurde der Codeabdeckungsrichtlinienstatus auf "Fehlgeschlagen" überschrieben, wenn ihr Build in der PR fehlschlug. Dies war ein Blocker für einige von Ihnen, die den Build als optionale Überprüfung und die Codeabdeckungsrichtlinie als erforderliche Überprüfung für PRs hatten, was dazu führt, dass PRs blockiert werden.
Bei diesem Sprint wird die Codeabdeckungsrichtlinie nicht auf "Failed" überschrieben, wenn der Build fehlschlägt. Dieses Feature wird für alle Kunden aktiviert.
Azure Repos
Unterstützung für bloblose und baumlose Filter
Azure DevOps unterstützt jetzt zwei zusätzliche Filter beim Klonen/Abrufen. Dies sind: --filter=blob:none Und --filter=tree:0Die erste Option (Blobless Clone) wird am besten für die normale Entwicklung verwendet, während die zweite Option (baumloses Klonen) besser für fälle geeignet ist, in denen Sie sich nicht Karte des Klons nach dem Ausführen eines Builds befinden.
Nächste Schritte
Hinweis
Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.
Wechseln Sie zu Azure DevOps, und sehen Sie sich an.
Senden von Feedback
Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.
Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.
Vielen Dank,
Silviu Andrica