Danke für die Rückmeldung! Wir untersuchen derzeit und werden Sie in Kürze aktualisieren.

Stimmen Sie dafür ab! IP-Bereiche des Azure Pipeline-Hosts https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-Bereiche

Stimmen Sie dafür ab! IP-Bereiche des Azure Pipeline-Hosts https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-Bereiche

@ XiaoningLiu das ist nicht üblich.

@renattomachado

Ich bin auch auf dieses spezielle Problem gestoßen. Wenn Ihre Anwendung nicht geschäftskritisch ist (dh sogar eine Sekunde des öffentlichen Zugriffs kann Ihr Unternehmen lahm legen), empfehle ich Folgendes:

1. Legen Sie Ihre Firewall-Einstellungen in Azure für Ihr Speicherkonto fest.
2. Legen Sie in Ihrer Version (oder Ihrem Build) Ihre Berechtigung für Ihr Speicherkonto programmgesteuert für alle Netzwerke fest, wie im Folgenden beschrieben (dies verwendet Azure CLI, Sie können dies jedoch auch mit Powershell tun).

az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --default-action Allow

1. Tun Sie alles, was Sie für den Zugriff auf Ihr Speicherkonto tun müssen.
2. Setzen Sie die Netzwerkeinstellungen sofort wieder auf Verweigern zurück. Bei Einstellung auf Verweigern werden Ihre Einstellungen berücksichtigt, die zuvor in Schritt 1 eingerichtet wurden.

az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --default-action Deny

Hoffentlich hilft dir das.

@ XiaoningLiu

Gibt es eine Möglichkeit, den IP-Bereich / die öffentliche IP zu ermitteln? Ich habe versucht, nur curl unter https://ipecho.net/ zu verwenden und diese IP hinzuzufügen (alles in einer Aufgabe, während ich mich in einer Pipeline befinde), aber es scheint nicht wirklich zu funktionieren. Im Idealfall können wir den IP-Bereich einfach von dem von uns verwendeten Agenten abrufen, zur Whitelist hinzufügen und ihn sofort entfernen. Auf diese Weise müssen wir keinen Job ausführen, der die wöchentlichen IP-Adressen für unsere Region (en) analysiert.

Gleiches Problem hier. Verwenden von Azure DevOps zum Bereitstellen von Azure-Ressourcen mit Terraform. Aus Sicherheitsgründen müssen wir die VNET-Firewallregeln aktivieren. Sobald wir es aktivieren, kann Terraform keine Speicherkontoinformationen (403) von Azure DevOps abrufen, und die Bereitstellungspipeline wird unterbrochen.

"Vertrauenswürdigen Microsoft-Diensten den Zugriff auf dieses Speicherkonto zulassen" ist aktiviert, aber Azure DevOps wird offensichtlich nicht als solches erkannt ...

Gibt es Neuigkeiten zu diesem Thema? Wir möchten, dass unsere Speicherkonten gesichert sind, möchten aber auch DevOps-Pipelines bereitstellen und verwenden. und die gleichen Probleme wie alle anderen hier zu haben.

Hier erfahren Sie, welche IP-Bereiche vorhanden sind. https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@artisticcheese

Ich denke, das Problem ist, dass die Verwendung dieses XML eine Automatisierung oder einen Prozess erfordern würde, der die Blacklist verwaltet und alte IPs entfernt.

Im Idealfall gibt es eine Möglichkeit, die IP-Adresse des Computers abzurufen, den Sie beim Ausführen eines gehosteten Agenten verwenden. Auf diese Weise können Sie etwas Ähnliches wie oben beschrieben tun, mit Ausnahme eines einzelnen Computers (der den DevOps-Job ausführt). .

Ja, außerdem scheint die Firewall ohnehin nur auf 100 Einträge beschränkt zu sein, sodass dies nicht funktioniert.

Wir arbeiten an einem Plan, um "Tag" - oder "Alias" -Definitionen zu aktivieren, damit diese Arten von Bereichen vom Dienst definiert werden können. noch keine ETA.

Bitte schließe

Warum wird dieses Problem geschlossen, wenn es nicht behoben wurde?
'... an einem Plan zu arbeiten ... befasst sich nicht wirklich mit dem Problem.

@nickforr Da arbeiten wir daran. Ich habe noch keine ETA dazu,

Gibt es derzeit ein Update? Gibt es jetzt ein Update?

@ SumanthMarigowda-MSFT oder @cbrooksmsft - Gibt es eine Möglichkeit, die diesbezügliche Funktionsanforderung zu verfolgen
Vielen Dank!

Ähnlich wie bei @tabeth sugest, habe ich in vielen Fällen die Firewall-Regeln verschiedener Ressourcen (SQL, Funktions-App usw.) geändert, um einen zeitweiligen Verkehr von der IP des Devops-Agenten zu ermöglichen. Dies ist jedoch nicht funktioniert für die Lagerung Konten, weil dies :

IP-Netzwerkregeln haben keine Auswirkungen auf Anforderungen, die aus derselben Azure-Region wie das Speicherkonto stammen.

@cbrooksmsft Können Sie bitte erklären, warum Sie darum gebeten haben, dass dieses Problem geschlossen wird? Das ist immer noch kaputt. Wenn dieses Problem an der falschen Stelle aufgetreten ist, können Sie dann bitte einen Link angeben, wo der Ersatzfehler aufgetreten ist, der dieses Problem verfolgt, damit es behoben wird?

Dieses Problem wurde am 24. November 2018 angesprochen. Ist es möglich, dass dies fälschlicherweise zum Schließen aufgefordert wurde, ohne das richtige Ersatzproblem zu erstellen? Ich frage, weil wir jetzt 2 Jahre später sind und es so aussieht, als ob dieser Fehler immer noch besteht.

Die hier vorgeschlagenen Problemumgehungen (zum einfachen Entfernen der Sicherheit) können Kundendaten gefährden.

Bitte beraten,

txs
Alan

Sie schienen zu planen, es im zweiten Quartal 2020 zu haben
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1710676

@artisticcheese Sie haben auf eine sehr breite Ankündigung verlinkt. Welcher Teil dieser Ankündigung befasst sich Ihrer Meinung nach mit diesem Problem? Wenn Sie "Service-Tags" meinen, dann behebe ich das nicht, um das Problem zu beheben? Service-Tags sehen aus wie eine hilfreiche Gruppierung von Regeln pro "Tag", und das hier beschriebene Problem würde weiterhin bestehen. (Insbesondere, dass die lokalen Azure-Entwickler nicht automatisch durch die Aufnahme von --bypass "Logging Metrics AzureServices Whitelist aufgenommen werden. Vielleicht habe ich etwas verpasst?

Um es für jeden zusammenzufassen, der neu in diesem Thread ist; Wenn ich eine Azure-Speicherressource für die Verwendung in der Azure Devops-Pipeline wie folgt erstelle

az storage account create -g "{resource-group-redacted}" `
-n "{storage-account-name-redacted}" `
-l "westeurope" `
--kind "StorageV2" `
--sku "Standard_RAGRS" `
--access-tier "Hot" `
--bypass Logging Metrics AzureServices `
--default-action "Deny" `
--https-only "true" 

Wenn ich einen Schritt in meiner Azure Devops-Pipeline habe, der AzureFileCopy@3 z

    - task: AzureFileCopy<strong i="13">@3</strong>
                  displayName: "Publish files to '$(my_storage)' storage"
                  inputs:
                      SourcePath: $(Build.ArtifactStagingDirectory)
                      azureSubscription: $(subscription)
                      Destination: AzureBlob
                      storage: $(my_storage)
                      ContainerName: $web

dann schlägt dies mit Berechtigungsfehler fehl,

Ziel konnte nicht überprüft werden. Der Remote-Server hat einen Fehler zurückgegeben: (403) Verboten.

Wenn in der Tat (wenn die Dokumentation soll zu glauben) mit --bypass AzureServices beim Erstellen des Speicherkonto sollte azuredevops mit Erlaubnis zum Speicher Account bieten.

Ich glaube, dies ist der Kern des Problems, und nichts in der Ankündigung für das zweite Quartal 2020 scheint dieses spezielle Problem anzusprechen.

Ich würde gerne falsch liegen.
EIN

Sie schienen zu planen, es im zweiten Quartal 2020 zu haben
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1710676

Ich bin mir nicht sicher, ob es geplant ist. Es heißt ausdrücklich: Service-Tag für Microsoft Hosted Agents für Pipelines werden nicht unterstützt.

Ich habe auch das gleiche Problem. Kann jemand offiziell bestätigen, dass dies noch geplant ist?

Ich kann die von Microsoft gehostete Azure Devops-Pipeline nicht mit dem Speicherkonto verbinden. Wird das gelöst?

@cbrooksmsft können Sie bitte auf die obigen Fragen antworten? Sie haben um eine Schließung gebeten, aber dies scheint nicht gelöst zu sein?
Wenn es tatsächlich gelöst wurde, wäre es rücksichtsvoll (professionell) von Microsoft, hier zumindest einen Kommentar abzugeben und zu sagen: "Hey Leute, das wird durch X behoben."

Gleicher Fehler

Zu Ihrer Information: https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

Verweis auf die bevorstehenden Änderungen für Service-Tags. Dies löst unser Problem immer noch nicht:

_Das Service-Tag gilt nicht für Microsoft Hosted Agents. Kunden müssen weiterhin die gesamte Geografie für die Microsoft Hosted Agents zulassen.

Verweis auf die bevorstehenden Änderungen für Service-Tags. Dies löst unser Problem immer noch nicht:

_Das Service-Tag gilt nicht für Microsoft Hosted Agents. Kunden müssen weiterhin die gesamte Geografie für die Microsoft Hosted Agents zulassen.

Verweis auf die bevorstehenden Änderungen für Service-Tags. Dies löst unser Problem immer noch nicht:

_Das Service-Tag gilt nicht für Microsoft Hosted Agents. Kunden müssen weiterhin die gesamte Geografie für die Microsoft Hosted Agents zulassen.

Verweis auf die bevorstehenden Änderungen für Service-Tags. Dies löst unser Problem immer noch nicht:

_Das Service-Tag gilt nicht für Microsoft Hosted Agents. Kunden müssen weiterhin die gesamte Geografie für die Microsoft Hosted Agents zulassen.

Stimmt, habe es nicht richtig gelesen 😓

Ich stoße auf dasselbe Problem und bin ehrlich gesagt überrascht, dass dieses Problem geschlossen wurde. Mein erster Gedanke war, dass ich ein geplantes Tool erstellen muss, um ihre wöchentliche JSON-Datei hier mit allen IP-Bereichen zu analysieren, aber sie scheinen keine API dafür bereitzustellen. Meine beste Option ist es also, die JSON-Datei jede Woche manuell herunterzuladen, sie einem Analyseprozess zuzuführen und dann die IP-Bereiche zu verschieben, um die Firewall-Einstellungen des Speicherkontos zuzulassen (wir sprechen von Hunderten). Sicher gibt es einen besseren Weg. Komm schon Microsoft!

Es gibt API, es funktioniert einfach nicht (veraltet)
https://docs.microsoft.com/en-us/rest/api/virtualnetwork/servicetags/list

Außerdem ist es mehr oder weniger einfach zu automatisieren (Herunterladen / Parsen von JSON-Dateien usw.)
https://artisticcheese.wordpress.com/2020/08/17/automating-azure-sql-firewall-rules-based-on-azure-service-tags/

@artisticcheese , danke für die Info. Interessante Gedanken, aber ich bin nicht zufrieden damit, ihre Webseite zu durchsuchen, um diese JSON-Datei abzurufen. Dies ist eine Produktions-App und das ist zu riskant. Abgesehen davon würde diese Methode Hunderte von Einträgen in der Firewall des Speicherkontos umfassen, damit meine gehostete Azure-Pipeline einfach einige Dateien kopieren kann. Es ist machbar, aber für meine Zwecke übertrieben.

Meine Herren, ich habe Sie heute hier versammelt, um für Ihre Stimme zu plädieren! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

Dies muss so schnell wie möglich behoben werden. Es ist ein fortlaufendes Problem der letzten zwei Jahre. Teilen, twittern, helfen, es zu beheben und auf Microsofts Radar zu bringen

@renattomachado @mimckitt @ AdamS-MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda-MSFT @solaomoDevOps @shahiddev @ marcin-vt @goblinfactory @artisticcheese @lymedo @ felipecruz91 @pratimvengurlekar @justinimel @ marcin-vt @gradyal

@ BobbyCGD gewählt

Als Workaround ist hier eine Aufgabe, die ich benutze ...

- bash: |
    sudo apt-get -y install grepcidr
    for d in {0..30}; do
      date_string=`date -d "-${d} days" +%Y%m%d`
      url="https://download.microsoft.com/download/7/1/D/71D86715-5596-4529-9B13-DA13A5DE5B63/ServiceTags_Public_${date_string}.json"
      echo "Trying '${url}'"
      curl -X GET -sfLO ${url}
      if [ -f "ServiceTags_Public_${date_string}.json" ]; then
          break
      fi
    done
    cat ServiceTags*.json | jq -r '.values[].properties.addressPrefixes[]' > networks.txt
    IP=`curl -s http://ipinfo.io/json | jq -r '.ip'`
    echo "Current IP is '${IP}'"
    grepcidr -f networks.txt <(echo "$IP") >/dev/null && echo "${IP} belongs to the trusted Azure Service tags addresses" || exit 1
    echo "##vso[task.setvariable variable=AGENT_IP;issecret=true]${IP}"
  displayName: Get agent IP

@lymedo @arkiaconsulting

Ich denke schon, ich verwende einen Windows-Agenten und habe mich dafür entschieden, nicht zu überprüfen, ob die IP-Adresse des Agenten in der Liste der IP-Adressen im Service-Tag enthalten ist. Hier ist der Schritt, den ich meiner Pipeline hinzugefügt habe

steps:
- bash: |
   IP=`curl -s http://ipinfo.io/json | jq -r '.ip'`
   echo "Current IP is '${IP}'"
   echo "##vso[task.setvariable variable=agentIp;issecret=true]${IP}"
  displayName: 'env: set $(agentIp)'

Ich benutze dann

steps:
- task: AzureCLI<strong i="12">@2</strong>
  displayName: 'env: add agent_ip to firewall'
  inputs:
    azureSubscription: '***'
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: 'az storage account network-rule add --account-name $(apimStorageAccountName) --ip-address $(agentIp)'

vor dem Versuch, auf dem Speicherkonto zu veröffentlichen, und nachdem ich mit der Veröffentlichung fertig bin, verwende ich

steps:
- task: AzureCLI<strong i="16">@2</strong>
  displayName: 'env: add agent_ip to firewall'
  inputs:
    azureSubscription: '***'
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: 'az storage account network-rule add --account-name $(apimStorageAccountName) --ip-address $(agentIp)'

@BobbyCGD Wenn Sie die von ipinfo gefundene IP nicht überprüfen, gehen Sie davon aus, dass sie nicht gehackt wurde ... Seien Sie vorsichtig in der Produktionsumgebung!

@arkiaconsulting Auf

1. Eine E-Mail-Benachrichtigung wird gesendet
2. Die IP wird sofort entfernt, keine Abhängigkeit vom Erfolg des Bereitstellungsschritts

Leider ist dies https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html. wurde geschlossen. Hoffentlich werden sie erwägen, das Problem erneut zu eröffnen und zu untersuchen.

Ich habe diesen Thread nicht im Auge behalten ... er ist so alt und dennoch ein Problem. Ich denke nicht, dass es richtig ist, dass dies als "geschlossen" markiert werden sollte ... Ich werde keine Kommentare abgeben ... aber das Leben muss weitergehen ... also ... unten ist eine Problemumgehung, die ich verwende scheint gut für mich zu funktionieren, dh

• Verwenden Sie einen Speicherschlüssel
• und benutze * az storage blob upload-batch *
• Mach alles in Powershell

Dieser Ansatz funktioniert möglicherweise nicht für Sie, aber für den Fall, dass hier ein Beispiel für ein Powershell-Skript vorhanden ist, das bisher in einer Devops-Pipeline für mich funktioniert, können Sie damit experimentieren und prüfen, ob es auch in Ihrer Pipeline funktioniert.

https://gist.github.com/goblinfactory/1f75678c45b2917b29fcb5158550024c

Der Vorteil dieser Powershell ist, dass Sie sie lokal genauso ausführen können wie auf dem Devops Build Agent. einfacher zu optimieren, wenn lokal ausgeführt wird.

hoffentlich nützlich.

viel Glück

Grüße

Alan

Dies ist immer noch ein Problem. Bitte öffnen Sie dies erneut.