Azure-docs: Die Azure DevOps Build Pipeline kann keine Geheimnisse von Key Vault erhalten, wenn sie mit vnet und Firewall gesichert ist

Erstellt am 15. Sept. 2019  ·  50Kommentare  ·  Quelle: MicrosoftDocs/azure-docs

Ich möchte Geheimnisse verwenden, die im Schlüsseldepot der DevOps Build Pipeline-Aufgabe gespeichert sind, und ich möchte die bewährten Sicherheitsmethoden und die Verteidigung eingehend befolgen. Als bewährte Sicherheitsmethode möchte ich, dass auf Key Vault über ausgewählte virtuelle Netzwerke, ausgewählte Azure-Dienste und vertrauenswürdige Internet-IPs zugegriffen werden kann. Natürlich würde ich einen Service-Principal und entsprechende Berechtigungen (list / get) verwenden.

Leider gehört Azure DevOps nicht zu den vertrauenswürdigen Diensten. Meine Alternative besteht also darin, die DevOps-IPs auf die weiße Liste zu setzen. Ich habe herausgefunden, dass sich mein DevOps in der Region US East 2 befindet, und habe Azure Datacenter-IPs heruntergeladen (gefiltert mit US East2). Es gibt ungefähr 285 IPs in US East2. Die Anzahl der Firewall-Regeln, die Sie hinzufügen können, ist in der Key Vault-Firewall begrenzt und beträgt 127! Ich habe also kein Glück!

Im Moment kann ich nur dann Geheimnisse aus dem Schlüsseldepot bei der Build-Pipeline erhalten, wenn ich alle Netzwerke zulasse! Ja, ich muss mich noch authentifizieren, um die Geheimnisse zu erfahren, aber ich verliere an Verteidigung in der Tiefe. Ich muss den Schlüsseldepot wirklich für vertrauenswürdige Netzwerke sperren, kann es aber nicht. Warum? Ich kann nicht mehr als 127 Firewall-Regeln hinzufügen (um die Region abzudecken) und DevOps ist keiner der vertrauenswürdigen Azure-Dienste!


Dokumentdetails

Bearbeiten Sie diesen Abschnitt nicht.

Pri2 awaiting-product-team-response key-vaulsvc product-question triaged

Hilfreichster Kommentar

Übrigens sagen die oben genannten Artikel, dass sich die IP-Bereiche wöchentlich ändern können. Es ist ziemlich lächerlich vorzuschlagen, dass wir die Firewall wöchentlich aktualisieren und sogar versuchen, die Änderungen im Auge zu behalten.

Alle 50 Kommentare

@ aspnet4you Danke für das Feedback.
Wir untersuchen aktiv und werden uns bald bei Ihnen melden.

@ KalyanChanumolu-MSFT - Vielen Dank, dass Sie sich mit dem Problem befasst haben. Key Vault ist eine wichtige Infrastrukturkomponente, und aufgrund der Art des Geschäfts möchten wir es nicht nicht vertrauenswürdigen Netzwerken aussetzen. Wenn ich eine Maschine in meiner Entlüftung gebaut hätte, wäre das in Ordnung gewesen, aber mein Ziel ist es, Azure DevOps für CI / CD zu verwenden. Ich muss die Schlüssel und Geheimnisse aufbewahren und sie sicher abrufen können.

@ aspnet4you , Vielen Dank, dass Sie die Anfrage geteilt haben. Das Whitelisting der IPs ist kein effizienter Weg, aber definitiv eine Problemumgehung. Wir arbeiten mit dem Produktteam zusammen, um Azure Dev Ops als vertrauenswürdigen Dienst für Azure Key Vault zu erhalten. Dies wäre in jeder Hinsicht eine vollständige Lösung. Erlauben Sie uns irgendwann und ich werde meine nächsten Updates mit Ihnen teilen.

Sie können der Build-Definition einen Schritt hinzufügen, um die IP-Adresse des Agenten auf die Whitelist zu setzen, und sie dann am Ende des Builds aus der Whitelist entfernen. Dies ist keine Lösung, sondern eine Problemumgehung, bis das Azure-Produktteam Azure DevOps als vertrauenswürdigen Dienst hinzufügt. Vielen Dank an @ Daniel Mann für die Idee.

Die Lösung ist einfach, aber ich wollte ipify.org nicht als REST-API-Endpunkt vertrauen, um die IP-Adresse meines Build-Agenten zu erhalten. Stattdessen habe ich meinen eigenen (und vertrauenswürdigen) Dienst bei Azure Function-GetClientIP erstellt. DevOps ist nicht mein Tagesjob und es fiel mir schwer herauszufinden, wie man benutzerdefinierte Variablen zuweist und verwendet und sie an den nächsten Schritt / die nächste Aufgabe / Stufe in der Pipeline weitergibt! Die Microsoft-Dokumentation zur Verwendung von Variablen hat mir nicht genug geholfen, aber ich habe es nach vielen erfolglosen Läufen herausgefunden!

Die vollständige Lösung finden Sie in meinem Blog - Azure DevOps Build Pipeline -. Verwenden Sie Schlüssel und Geheimnisse aus Key Vault .

@ aspnet4you , Es gibt Gespräche darüber, Azure DevOps als vertrauenswürdigen Dienst zu erhalten. Azure DevOps verfügt über ein bestimmtes Szenario, in dem die Identität, die auf Key Vault zugreift, dem Kunden und nicht Microsoft gehört. Dies verstößt gegen die Skalierbarkeits- und Sicherheitsanforderungen für "vertrauenswürdige Dienste".

Derzeit scheint die einzige Problemumgehung darin zu bestehen, die IP-Adressen von DevOps-Computern zur AKV-Firewall hinzuzufügen. Dies ist eine kleinere Teilmenge als alle IPs von Datacenter und entspricht dem Limit von 127 IP-Regeln.

Ich arbeite derzeit daran, die IPs zu erhalten, und werde den Thread in Kürze aktualisieren.

@ aspnet4you , Die Details zu den IPs finden Sie unten:

Informationen zur Whitelist von AzureDevops-Diensten finden Sie unter https://docs.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops

Für die Whitelist von gehosteten Agenten - https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#agent -ip-Bereiche

Hoffe das hilft.

@ aspnet4you , hoffe das hilft. Bitte wenden Sie sich an uns, falls Sie weitere Fragen dazu haben. Wir schließen diesen Thread vorerst.

@ saueravmishra-msft es scheint, dass die Whitelist Azure Devops Dienste, die IPs im Link sind es nicht genug.
Zum Beispiel beim Versuch, die Variablengruppe von Devops mit den Geheimnissen von Keyvault zu verknüpfen, musste ich auch die IP hinzufügen: 52.236.xx (ich habe absichtlich die Lat 2 Bytes versteckt). Wissen Sie, woher diese IPs stammen? Können Sie die gesamte Palette von IPs für die Verknüpfung von Devops-Variablengruppen bereitstellen?

@ aspnet4you , Vielen Dank, dass Sie die Anfrage geteilt haben. Das Whitelisting der IPs ist kein effizienter Weg, aber definitiv eine Problemumgehung. Wir arbeiten mit dem Produktteam zusammen, um Azure Dev Ops als vertrauenswürdigen Dienst für Azure Key Vault zu erhalten. Dies wäre in jeder Hinsicht eine vollständige Lösung. Erlauben Sie uns irgendwann und ich werde meine nächsten Updates mit Ihnen teilen.

Gibt es ein Update zu dieser Funktion? Gibt es einen Link zum Verfolgen der Funktion "Azure Dev Ops als vertrauenswürdiger Dienst für Azure Key Vault"?

@ aspnet4you , wie reicht es aus, die IP allein auf die Whitelist zu setzen, um Geheimnisse / Schlüssel ohne eine relevante Key Vault-Zugriffsrichtlinie zu erhalten?

@oviliz - Sehr gute Frage. Die Whitelist von IP ist eine der letzten Abwehrmaßnahmen gegen unbefugten Zugriff auf den Tresor. Service Principal muss mit der Key Vault-Zugriffsrichtlinie konfiguriert werden, um Schlüssel und Geheimnisse aufzulisten und abzurufen. Dies ist die zweite Anforderung in meinem Beitrag - Azure DevOps Build Pipeline -. Verwenden Sie Schlüssel und Geheimnisse aus Key Vault .

Hallo @ KalyanChanumolu-MSFT irgendwelche Updates? Heute stand ich vor dem gleichen Problem. Ich kann in meiner Release-Pipeline (Azure DevOps) kein Geheimnis von meinem KV im Azure Key Vault-Schritt abrufen. Links zu den oben genannten IPs sind unterbrochen ... Wie kann ich also Geheimnisse in meiner Pipeline abrufen? Erlauben Sie vertrauenswürdigen Microsoft-Diensten, diese Firewall zu umgehen? (Ja) - hat auch nicht geholfen.

Ich stehe auch vor diesem Problem und es ist klar, welche IPs auf die Whitelist gesetzt werden müssen. Außerdem öffnet dies unseren Tresor für Dienste, die wir nicht kontrollieren, sodass ich mit dieser Lösung ziemlich unzufrieden bin.

Übrigens sagen die oben genannten Artikel, dass sich die IP-Bereiche wöchentlich ändern können. Es ist ziemlich lächerlich vorzuschlagen, dass wir die Firewall wöchentlich aktualisieren und sogar versuchen, die Änderungen im Auge zu behalten.

Ich stehe vor dem gleichen Problem, und die wöchentliche Whitelist von IPs ist überhaupt keine Option.

Wäre es möglich, einen selbst gehosteten Agenten für die Build-Pipeline in einer VM zu haben, diese VM in einem VNet einzurichten und dann den Zugriff im Key Vault zuzulassen? Ich bin keineswegs ein Profi. Wie absurd ist dieser Ansatz?

FWIW Diese Lösung hat mich hier inspiriert: https://www.visualstudiogeeks.com/DevOps/PrivateAzureAseV2AppServiceVstsDeploymentUsingAzureDtl

Fügen Sie uns der Liste hinzu. Wie kann es sein, dass ADO kein vertrauenswürdiger Dienst für Key Vaults ist?

Wenn Sie die wöchentlichen Dateien nach Entwicklern oder gehosteten Agenten durchsuchen, werden keine IPs hervorgehoben. Welche IPs verwenden Sie in https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519 ??? und wenn Sie nach Datacenter suchen, gibt es Appservice, Devspaces usw., aber was korreliert mit Devops und Host-Agenten?

@ ShaneBala-keyvault, Wie gewünscht, füge dich diesem Thread hinzu.

Fügen Sie uns der Liste hinzu. Wie kann es sein, dass ADO kein vertrauenswürdiger Dienst für Key Vaults ist?

Wenn Sie dort sind, möchten Sie viele Projekte zu AZ Devops verschieben, aber dies ist ein Problem

+1, dies sollte so schnell wie möglich behoben werden. Selbst wenn geheime Pipeline-Variablen für Releases verwendet werden können, hätte ich gerne eine einzige Quelle der Wahrheit. Der Wert der geheimen Pipeline-Variablen kann nach dem Speichern nicht mehr angezeigt werden. Auf jeden Fall müssen die Informationen ohnehin an einem anderen Ort gespeichert werden.

SO Frage zu diesem Thema:

https://stackoverflow.com/q/61411653/3850405

+1 das ist wirklich entscheidend. Irgendein Kommentar von Microsoft dazu?

@ souravmishra-msft Sollte dies vielleicht wieder geöffnet werden?

@Ogglas Dies sollte auf jeden Fall wieder geöffnet werden. Sie sollten IPs auflisten oder den Dienst markieren, um die Azure Keyvault-Firewall zu umgehen. Sie tun es für andere Dienste, warum nicht Azure Devops?

+1, gleiches Problem hier

+1

auch mitmachen auf dem Haufen auf .. großes Problem auch für mich

Wie um alles in der Welt ist das so nah ???? Die Links Links der "Problemumgehung" funktionieren auch nicht :)

Müssen wir hierfür ein neues Problem erstellen oder einen Weg finden, es erneut zu öffnen, @ souravmishra-msft?

@ Captainbrown , ich habe diesen Thread wieder geöffnet. Ich habe den Programm-Manager auch intern erneut aktualisiert, da ab dem Zeitpunkt, an dem dieser Thread geöffnet wurde, der interne Thread mit dem Produktteam erstellt wurde.

Ich weise diesen Thread auch dem Programm-Manager zu. Es kann einige Zeit dauern, bis sie auf diesen Thread antworten, da ich nicht sicher bin, wie komplex diese Änderung auf der Produktseite sein kann.

Ich habe auch den internen Thread, der gegen diesen Github-Thread läuft, gestoßen und werde Sie über den Fortschritt auf dem Laufenden halten.

Ich möchte auch angeben, dass ich die URLs korrigiert habe, die in einem meiner Kommentare weiter oben in diesem Thread erwähnt wurden. Vielleicht möchten Sie sich diese auch einmal in der Zwischenzeit ansehen und uns mitteilen, ob diese für Ihre Lösung funktionieren, und wenn nicht, aktualisieren Sie uns auch darüber.

@ souravmishra-msft Vielen Dank, dass Sie dieses Problem erneut geöffnet haben. Das Zulassen der Bereiche für die Devops-Dienste funktioniert nicht, um den Zugriff auf den Schlüsseltresor zu ermöglichen (möglicherweise sind die Bereiche auf der Website veraltet), und die Liste möglicher Subnetze ist viel zu lang, um sie der Netzwerkzugriffskontrolle im Schlüsseltresor hinzuzufügen.

Mein Team und ich werden gespannt auf die Nachricht Ihres Programmmanagers warten

Vielen Dank für die Wiedereröffnung ... @captainbrown Ich habe das gleiche Problem gesehen, bei dem die Dokumentation oder die JSON-Datei mit den IP-Diensten definitiv veraltet / nicht richtig dokumentiert ist.

Einverstanden, danke für die Wiedereröffnung. Dies ist ein Thema, das wir gerne auch angesprochen sehen würden.

@ acidavmishra-msft Vielen Dank, ich hoffe, dass dies bald priorisiert wird.

+1, das ist auch ein Problem für uns. Nicht nur der Azure DevOps-Zugriff auf Key-Vault, sondern auch die DevOps-Pipeline, um einige Dateien zu generieren und diese auf ein Firewall-geschütztes Speicherkonto hochzuladen. Wir haben jedoch das gleiche Problem, dass Azure DevOps kein vertrauenswürdiger Dienst ist und die Problemumgehung wäre, wöchentlich ~ 250 IP-Adressen auf die Whitelist zu setzen, was sehr hässlich wäre (und auch nicht sicher ist, ob es eine Begrenzung gibt, wie viele IP-Adressen der Firewall des Speicherkontos hinzugefügt werden können). Es wäre toll, wenn dies angegangen werden kann!

Derzeit gibt es eine Problemumgehung für dieses Problem.

Sie können einen selbst gehosteten Agenten verwenden und die folgenden IPv4-Bereiche zur Zulassungsliste der Key Vault-Firewall hinzufügen. Details hier: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops

(Das Azure DevOps-Team ist sich dieses Problems bewusst und arbeitet derzeit an einer dauerhaften Korrektur.)

Diese Funktion befindet sich derzeit in der Vorschau.

Hier ist eine weitere Problemumgehung ... Sie können Ihr eigenes vnet mit einem Skalensatz einrichten.

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/scale-set-agents?view=azure-devops

Ein weiterer Trick ... Ich übernehme diesen Trick nicht, jemand hat es mir gezeigt.
Wenn Sie ein Enterprise-Devops-Konto haben, können Devops die Keyvault-Geheimnisse für Ihre Bibliothek lesen.
Wenn Sie ein persönliches Konto haben, funktioniert dies nicht.

Sie können die Firewall für das Azure / 11-Netzwerk öffnen und die Verbindung von Devops zu Azure mit dem Keyvault herstellen. Richten Sie die Variablenbibliothek ein und fügen Sie das Geheimnis hinzu. Entfernen Sie nach dem Hinzufügen der Geheimnisse die Firewall-Regel und versuchen Sie, ein Geheimnis hinzuzufügen. Die Fehlermeldung übergibt Ihnen eine IP, die Sie in die Firewall einfügen können. Wir haben festgestellt, dass es sich seit einem Monat nicht geändert hat, und wir verstehen, dass es sich ändern kann. An dieser Stelle suchen wir nach Problemumgehungen wie alle anderen. Ich werde weitere Tests mit Builds und Releases durchführen, aber dies ermöglicht es der Native Devops-Benutzeroberfläche, direkt mit Keyvaults zu interagieren.

Auch dies funktioniert nicht mit einem persönlichen Konto.

+1 Wir haben ein ähnliches Problem bei der Verwendung von AzDO zu SQL Server über Private Link / Endpoint.

+1 Ähnliches Problem hier.

Hier finden Sie Problemumgehungen. Es ist kein Problem mit dem Dokument selbst. Dies ist eine Problemumgehung. Https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops # Bitte schließen Sie. Sie können hier auch eine Funktionsanforderung posten. Https: // Developercommunity.visualstudio.com/spaces/21/index.html

+1, traf dieses Problem heute.

Wenn Microsoft Service-Tags für Azure DevOps aktiviert, kann es dann irgendwie in der Keyvault-Firewall verwendet werden? https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

@ JQUINONES82 Ich fürchte nicht für gehostete Agenten. Von Ihrem Link:

Das Service-Tag gilt nicht für Microsoft Hosted Agents.

+1, dies in den letzten 2 Jahren

+1, traf dieses Problem heute.

Dies ist geschlossen. Wie bekomme ich das Update?

Sicherheit ist keine Funktionsanforderung, sondern eine Notwendigkeit für jede Cloud-Komponente. Wenn dies nicht behoben ist, kann es wieder geöffnet werden? Ich habe erwähnt, dass etwas in der Vorschau ist ... Ich werde eine Vorschaufunktion verwenden. Dies wird unsere Bereitstellung verzögern, da ich nicht noch mehr Geld dafür ausgeben möchte, VMs in Azure hochzufahren, um dies zu tun ...

@jsburckhardt - Ich
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Hallo Kumpel, ist eine gute Problemumgehung. Leider aus Sicherheitsgründen. Das Team hat keine Kontrolle über die IP-Adressen auf der Whitelist von KV / vNet

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Favna picture Favna  ·  3Kommentare

JeffLoo-ong picture JeffLoo-ong  ·  3Kommentare

DeepPuddles picture DeepPuddles  ·  3Kommentare

mrdfuse picture mrdfuse  ·  3Kommentare

Agazoth picture Agazoth  ·  3Kommentare