Azure Pipelines – Sprint 227 Aktualisierung

Features

• Workload-Identitätsverbund in Azure Pipelines (öffentliche Vorschau)

• Pipeline-Agents können mithilfe der Microsoft Entra-ID anstelle eines PAT registriert werden.

• REST-APIs für Umgebungen

• Verhinderung unbeabsichtigter Pipelineausführungen

• GitHub-Repositorys standardmäßig sicher erstellen

• Deaktivieren des Überschreibens des Status der Codeabdeckungsrichtlinie auf "Fehlgeschlagen," wenn der Build fehlschlägt

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 darüber machen, diese Geheimnisse zu rotieren, wann immer sie ablaufen? Wir kündigen nun eine öffentliche Vorschau der Workload Identity Federation für Azure-Dienstverbindungen an. Der Workload-Identitätsverbund verwendet eine branchenübische Technologie, Open ID Connect (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, sich mit einem Föderationsbetreff (sc://<org>/<project>/<service connection name>) zu authentifizieren. Die wichtigsten Vorteile der Verwendung dieses Schemas 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, keine Geheimnisse, die Zugriff auf Ihre Produktionsumgebungen haben, leaken 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 für eine Verbindung nach der anderen durchführen. Das Beste daran ist, dass Sie keine der Pipelines, die diese Dienstverbindungen verwenden, ändern müssen. 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 die Sicherheitsverbesserung durch Unterstützung der Workload-Identitätsföderation zu ermöglichen. 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.

Einen Agenten mithilfe eines Dienstprinzipals registrieren

Um einen Dienstprinzipal zum Registrieren eines Pipeline-Agents bei Azure DevOps Services zu verwenden, geben Sie die folgenden Argumente an:

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

Verwenden Sie einen Dienstprinzipal 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 (Service Principal) anstelle eines Personal Access Token (PAT) zu verwenden, um den Agenten 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, wohin Sie im Web gehen müssen und welchen Code Sie eingeben sollen. 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 Ihnen Bereitstellungsverlauf, Nachverfolgbarkeit von 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.

Sichere Erstellung von GitHub-Repositories standardmäßig

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.

Deaktivierung der 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 Hindernis für einige von Ihnen, die den Build als optionale Prüfung und die Codeabdeckung als erforderliche Prüfung für PRs hatten, was dazu führte, dass PRs blockiert wurden.

Bei diesem Sprint wird die Codeabdeckungsrichtlinie nicht auf "Failed" überschrieben, wenn der Build fehlschlägt. Dieses Feature wird für alle Kunden aktiviert.

Nächste Schritte

Gehen Sie zu Azure DevOps und schauen Sie sich an.

So geben Sie Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. 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.