フィードバックをお寄せいただきありがとうございます！ 現在調査中であり、まもなく更新されます。

これに投票してください！ AzureパイプラインホストのIP範囲https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

これに投票してください！ AzureパイプラインホストのIP範囲https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

@XiaoningLiuそれは普通ではありません。

@renattomachado

私もこの特定の問題に遭遇しました。 アプリケーションがミッションクリティカルでない場合（つまり、パブリックアクセスが1秒でもビジネスに支障をきたす可能性がある場合）、次のことをお勧めします。

1. ストレージアカウントのAzureでファイアウォール設定を設定します。
2. リリース（またはビルド）で、次のように、プログラムですべてのネットワークにストレージアカウントのアクセス許可を設定します（これはAzure CLIを使用しますが、Powershellを使用して同じことを行うことができます）。

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

1. ストレージアカウントへのアクセスに関して必要なことは何でもしてください。
2. すぐにネットワーク設定を[拒否]にリセットします。 [拒否]に設定すると、手順1で以前に設定した設定が尊重されます。

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

うまくいけば、それはあなたを助けるでしょう。

@XiaoningLiu

IP範囲/パブリックIPを取得する方法はありますか？ https://ipecho.net/でcurlして、そのIPを追加しようとしました（すべてパイプライン内のタスクで）が、実際には機能しないようです。 理想的には、使用しているエージェントからIP範囲を取得し、それをホワイトリストに追加して、すぐに削除することができます。 そうすれば、リージョンのIPの毎週のセットを解析するようなジョブを実行する必要がありません。

ここで同じ問題。 AzureDevOpsを使用してTerraformでAzureリソースをデプロイします。 セキュリティ要件のため、VNETファイアウォールルールをオンにする必要があります。 オンにするとすぐに、TerraformはAzure DevOpsからストレージアカウント情報（403）を取得できなくなり、デプロイパイプラインが中断します。

「信頼できるMicrosoftサービスにこのストレージアカウントへのアクセスを許可する」が有効になっていますが、明らかにAzureDevOpsはそのように認識されていません...

これについて何かニュースはありますか？ ストレージアカウントを保護する必要がありますが、DevOpsパイプラインをデプロイして使用することも必要です。 ここにいる他のみんなと同じ問題を抱えています。

IP範囲を確認する方法は次のとおりです。 https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@artisticcheese

問題は、そのXMLを使用するには、ブラックリストを維持して古いIPを削除する自動化またはプロセスが必要になることだと思います。

理想的には、ホストされたエージェントの実行中に使用しているマシンのIPを取得する方法があります。そうすれば、単一のマシン（DevOpsジョブを実行しているマシン）を除いて、上記と同様のことができます。 。

はい、それに加えて、ファイアウォールはとにかく100エントリに制限されているように見えるので、これは機能しません。

「タグ」または「エイリアス」の定義を有効にして、これらの種類の範囲をサービスで定義できるようにする計画に取り組んでいます。 まだETAではありません。

閉じてください

対処されていないのに、なぜこの問題は解決されるのですか？
「...計画に取り組んでいます...実際には問題に対処していません。

@nickforr私たちはそれに取り組んでいるので。 私はまだこれに関するETAを持っていません、

現在同じ問題が発生していますが、アップデートはありますか？

@ SumanthMarigowda-MSFTまたは@ cbrooksmsft-これに関連する機能要求を追跡する方法はありますか-ETAの共有に不安がある場合でも、
ありがとう！

@tabethが提案するものと同様に、多くの場合、さまざまなリソース（sql、function appなど）のファイアウォールルールを変更して、devopsエージェントのIPから一時的にトラフィックを許可していました。 しかし、これはの、ストレージアカウントのために働いていません。この：

IPネットワークルールは、ストレージアカウントと同じAzureリージョンから発信されたリクエストには影響しません。

@cbrooksmsftこの問題の解決を求めた理由を説明してください。 これはまだ壊れています。 この問題が間違った場所で発生した場合は、この問題を追跡している置換バグが発生した場所へのリンクを提供して、解決できるようにしてください。

この問題は2018年11月24日に発生しました。正しい交換の問題を作成せずに、誤ってクローズするように求められた可能性がありますか？ 私たちは2年経ちましたが、このバグはまだ存在しているように見えるので、私は尋ねます。

ここで提案されている回避策（単にセキュリティを削除する）は、顧客データを危険にさらす可能性があります。

お知らせ下さい、

txs
アラン

彼らは2020年第2四半期にそれを持っていることを計画しているようでした
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

@artisticcheeseあなたは非常に幅広い発表にリンクしました。 その発表のどの部分がこの問題に対処していると思いますか？ あなたが「サービスタグ」を意味するなら、私はこれを問題に対処しませんか？ サービスタグは、「タグ」ごとのルールの便利なグループのように見えますが、ここで説明する問題は引き続き存在します。 （具体的には、ローカルの紺碧のdevopsは、 --bypass "Logging Metrics AzureServices含めることによって自動的にホワイトリストに登録されません。おそらく、何かを見逃したのでしょうか。

このスレッドを初めて使用する人のために要約します。 以下のように、Azuredevopsパイプラインで使用するAzureストレージリソースを作成すると

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" 

AzureFileCopy@3を使用するazuredevopsパイプラインにステップがある場合

    - 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

その後、これは許可エラーで失敗します、

宛先の検証に失敗しました。 リモートサーバーがエラーを返しました：（403）禁止。

実際には（ドキュメントが信じられている場合）、ストレージアカウントの作成時に--bypass AzureServicesを使用すると、azuredevopsにストレージアカウントへのアクセス許可が提供されることになっています。

これが問題の核心だと思いますが、2020年第2四半期の発表では、この特定の問題に対処しているようには見えませんか？

私はこれについて間違っていることを望みます。
A

彼らは2020年第2四半期にそれを持っていることを計画しているようでした
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

計画されているかどうかわからない。 具体的には次のように述べています。パイプライン用のMicrosoftHostedAgentsのサービスタグはサポートされていません。

私も同じ問題を経験します。 誰もがこれがまだ計画されていることを公式に確認できますか？

AzureDevopsパイプラインのMicrosoftがホストするエージェントをストレージアカウントに接続できません。 これは解決される予定ですか

@cbrooksmsft上記の質問に答えていただけますか？ クローズをリクエストしましたが、これは解決されていないようですか？
それが実際に解決された場合、少なくともここで「Xを実行することで修正されます」とコメントすることは、Microsoftの思いやりのある（専門家）でしょう。

同じ問題

参考： https ：

サービスタグの今後の変更への参照。 これでも問題は解決しません。

_サービスタグは、Microsoft HostedAgentには適用されません。 お客様は、Microsoft HostedAgentsの地域全体を許可する必要があります。_

サービスタグの今後の変更への参照。 これでも問題は解決しません。

_サービスタグは、Microsoft HostedAgentには適用されません。 お客様は、Microsoft HostedAgentsの地域全体を許可する必要があります。_

サービスタグの今後の変更への参照。 これでも問題は解決しません。

_サービスタグは、Microsoft HostedAgentには適用されません。 お客様は、Microsoft HostedAgentsの地域全体を許可する必要があります。_

サービスタグの今後の変更への参照。 これでも問題は解決しません。

_サービスタグは、Microsoft HostedAgentには適用されません。 お客様は、Microsoft HostedAgentsの地域全体を許可する必要があります。_

確かに、それを正しく読んでいませんでした😓

私はこれと同じ問題に直面していて、この問題が解決されたことに率直に驚いています。 私が最初に考えたのは、ここで毎週のJSONファイルをすべてのIP範囲で解析するためのスケジュールされたツールを作成する必要があるということでしたが、そのためのAPIを提供していないようです。 だから私の最善の選択肢は、毎週手動でJSONファイルをダウンロードし、それをいくつかの解析プロセスにフィードしてから、IP範囲をプッシュして（数百と話している）ストレージアカウントのファイアウォール設定を許可することです。 確かにもっと良い方法があります。 マイクロソフトよ！

APIがありますが、機能しません（古くなっています）
https://docs.microsoft.com/en-us/rest/api/virtualnetwork/servicetags/list

また、自動化は多かれ少なかれ簡単です（JSONファイルのダウンロード/解析など）
https://artisticcheese.wordpress.com/2020/08/17/automating-azure-sql-firewall-rules-based-on-azure-service-tags/

@artisticcheese 、情報をありがとう。 興味深い考えですが、そのJSONファイルをプルするために彼らのWebページをスクレイピングするのは苦手です。 これは本番アプリであり、リスクが高すぎます。 それとは別に、この方法では、ホストされているAzureパイプラインにいくつかのファイルをコピーさせるために、ストレージアカウントファイアウォールに数百のエントリが含まれます。 それは実行可能ですが、私の目的にはやり過ぎです。

ご列席の皆様、今日はあなたの投票をお願いするためにここに集まりました！ -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

これはできるだけ早く修正する必要があります。これは過去2年間継続している問題です...共有、ツイート、修正の支援、Microsoftのレーダーへの掲載👍

ADAMS-MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda-MSFT @solaomoDevOps @shahiddev @マルチン-VT @goblinfactory @artisticcheese @lymedo @ felipecruz91 @pratimvengurlekar @justinimel @マルチン-VT @ @mimckitt @renattomachado @gradyal

@BobbyCGD投票

回避策として、これが私が使用するタスクです...

- 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

私はWindowsエージェントを使用していて、エージェントのIPアドレスがサービスタグのIPアドレスのリストに含まれているかどうかを確認しないことを選択したと思います。 これが私のパイプラインに追加したステップです

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)'

次に使用します

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)'

ストレージアカウントに公開しようとする前、および公開が完了した後、

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 ipinfoによって検出されたIPをチェックしない場合は、ハッキングされていないと見なされます...実稼働環境に注意してください！

@arkiaconsulting間違いなくリスクですが、私の特定のユースケースでは問題ありません。 展開は常に「監視」されます。発生する可能性のある最悪の事態は、展開手順が失敗することです。 この場合：

1. 電子メールアラートが送信されます
2. IPはすぐに削除され、展開ステップの成功に依存しません

悲しいことに、このhttps://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html。 もう閉店した。 うまくいけば、彼らは問題を再開して調査することを検討するでしょう。

私はこのスレッドを監視していません...それはとても古いです、それでもそれはまだ問題です。 これを「クローズ」とマークするのは正しいとは思いません...コメントは控えます...しかし、人生は続く必要があります...だから...以下は私が使用している回避策です、それ私にとってはうまく機能しているようです、すなわち

• ストレージキーを使用する
• * az storage blob upload-batch *を使用します
• すべてをPowerShellで実行する

このアプローチはうまくいかないかもしれませんが、これまでのdevopsパイプラインで機能するサンプルのPowerShellスクリプトがここにある場合に備えて、それを試して、パイプラインでも機能するかどうかを確認できますか？

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

このPowerShellの利点は、devopsビルドエージェントで実行するのとまったく同じようにローカルで実行できることです。 ローカルで実行する場合は、微調整が簡単です。

うまくいけば便利です。

幸運を祈ります

よろしく

アラン

これはまだ問題です。 これを再度開いてください。