感谢您的反馈！ 我们目前正在调查中，并会尽快为您更新。

为此投票！ Azure Pipeline主机IP范围https://docs.microsoft.com/zh-cn/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

为此投票！ Azure Pipeline主机IP范围https://docs.microsoft.com/zh-cn/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

@XiaoningLiu不常见。

@renattomachado

我也遇到了这个特殊问题。 如果您的应用程序不是关键任务应用程序（也就是说，即使是一秒钟的公共访问也可能使您的业务瘫痪），我建议您执行以下操作：

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

希望可以帮到您。

刘小宁

有没有办法获取IP范围/公共IP？ 我尝试仅在https://ipecho.net/上使用curl并添加该IP（全部在管道中的任务中），但这似乎并没有真正起作用。 理想情况下，我们可以从正在使用的代理中获取IP范围，将其添加到白名单中，然后立即将其删除。 这样，我们就不必执行某种工作来解析我们地区的每周IP。

同样的问题在这里。 使用Azure DevOps通过Terraform部署Azure资源。 由于安全性要求，我们需要打开VNET防火墙规则。 启用后，Terraform无法从Azure DevOps检索存储帐户信息（403），并且部署管道中断。

启用了“允许受信任的Microsoft服务访问该存储帐户”，但显然Azure DevOps无法识别为此类...

这有什么消息吗？ 我们希望保护我们的存储帐户安全，但同时也希望部署和使用DevOps Pipelines。 并遇到与这里其他所有人一样的问题。

这是找出哪些IP范围的方法。 https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@artisticcheese

我认为问题在于使用XML会要求人们进行某种自动化或维护黑名单并删除旧IP的过程。

理想情况下，将有一种方法来获取您在运行托管代理时正在使用的计算机的IP，这样您就可以执行与上述操作类似的操作，除了一台计算机（运行DevOps作业的计算机）之外。

是的，此外，防火墙似乎只能被限制为100个条目，因此这行不通。

我们正在制定一项计划，以启用“标签”或“别名”定义，以允许服务定义这些范围。 还不是ETA。

请关闭

如果未解决此问题，为什么会关闭该问题？
“……制定计划……并没有真正解决问题。

@nickforr因为我们正在努力。 我还没有预计的时间，

当前遇到相同的问题，现在是否有任何更新？

@ SumanthMarigowda-MSFT或@cbrooksmsft -有没有跟踪与这个特性请求的任何方式-即使你不舒服的共享，将是有益的ETA当它已经完成通知。
谢谢！

与@tabeth汇总类似，在许多情况下，我是在更改不同资源（sql，函数app等）的防火墙规则，以允许临时从devops代理ip进行流量。 然而，这是行不通的存储帐户，因为此：

IP网络规则对源自与存储帐户相同的Azure区域的请求没有影响。

@cbrooksmsft您能否解释为什么要求关闭此问题？ 这还是坏了。 如果在错误的位置提出了此问题，那么您能否提供一个链接，指向出现此问题的替换错误的链接，以便可以解决该问题？

这个问题是在2018年11月24日提出的。是否有可能在没有创建正确的替换问题的情况下错误地要求将其关闭？ 我问是因为我们现在已经落后两年了，看来这个错误仍然存​​在？

此处建议的解决方法（简单地删除安全性）可能会使客户数据面临风险。

请指教，

特克斯
艾伦

他们似乎计划在2020年第二季度拥有它
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而自动列入白名单，也许我错过了什么吗？

回顾这个线程的新手； 当我创建用于Azure Devops管道的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 azure devops管道中有步骤，例如

    - 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年第二季度公告中似乎没有任何内容可以解决这个特定问题？

我很乐意在这方面犯错。
一种

他们似乎计划在2020年第二季度拥有它
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

不确定是否已计划。 它特别指出：不支持Microsoft管道托管代理的服务标签。

我也碰巧遇到同样的问题。 有人可以正式确认这仍在计划中吗？

我无法将Azure Devops管道Microsoft托管代理连接到存储帐户。 这会解决吗

@cbrooksmsft您能回答上述问题吗？ 您请求关闭问题，但是似乎无法解决？
如果实际上已解决，则Microsoft至少要在这里发表评论说“嘿，这是X来解决的”，这是Microsoft的体贴（专业）的观点。

同一期

仅供参考： https :

参考服务标签即将发生的变化。 这仍然不能解决我们的问题：

_该服务标签不适用于Microsoft托管代理。 仍然需要客户允许Microsoft托管代理的整个地理位置。_

参考服务标签即将发生的变化。 这仍然不能解决我们的问题：

_该服务标签不适用于Microsoft托管代理。 仍然需要客户允许Microsoft托管代理的整个地理位置。_

参考服务标签即将发生的变化。 这仍然不能解决我们的问题：

_该服务标签不适用于Microsoft托管代理。 仍然需要客户允许Microsoft托管代理的整个地理位置。_

参考服务标签即将发生的变化。 这仍然不能解决我们的问题：

_该服务标签不适用于Microsoft托管代理。 仍然需要客户允许Microsoft托管代理的整个地理位置。_

是的，没有正确阅读😓

我遇到了同样的问题，我很惊讶这个问题已经关闭。 我首先想到的是，我将不得不构建一个计划内的工具来在这里解析其每周JSON文件以及所有IP范围，但是它们似乎并未为此提供API。 因此，我最好的选择是每周手动下载JSON文件，将其输入一些解析过程，然后推送IP范围以允许（我们正在讨论数百个）存储帐户防火墙设置？ 当然有更好的方法。 来吧微软！

有API，只是无法使用（已过期）
https://docs.microsoft.com/zh-cn/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文件。 这是一个生产应用程序，风险太大。 除此之外，此方法将在存储帐户防火墙中涉及数百个条目，以使托管的Azure管道简单地复制一些文件。 这是可行的，但出于我的目的，这太过分了。

先生们，我今天聚集你在这里为您投票！ -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

这需要尽快解决，这是过去两年中一直存在的问题...分享，发布推文，帮助修复并使其受到微软的关注it

@renattomachado @mimckitt @亚当斯MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda-MSFT @solaomoDevOps @shahiddev @马尔钦-VT @goblinfactory @artisticcheese @lymedo @ felipecruz91 @pratimvengurlekar @justinimel @马尔钦-VT @渐变

@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存储blob上传批处理*
• 在Powershell中完成所有操作

这种方法可能对您不起作用，但是以防万一，如果有一个示例powershell脚本可以在到目前为止的任何devops管道中为我工作，您可以尝试一下，看看它是否也可以在您的管道中工作？

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

该powershell的优点是您可以在本地运行它，与在devops build agent上运行的方式完全相同。 在本地运行时更容易进行调整。

希望有用。

祝你好运

问候

艾伦

这仍然是一个问题。 请重新打开它。