Спасибо за ответ! В настоящее время мы изучаем ситуацию и скоро сообщим вам.

Проголосуйте за это! Диапазоны IP-адресов хоста Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-range

Проголосуйте за это! Диапазоны IP-адресов хоста Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-range

@XiaoningLiu , это

@renattomachado

Я тоже столкнулся с этой конкретной проблемой. Если ваше приложение не является критически важным (то есть даже секунда публичного доступа может нанести ущерб вашему бизнесу), я рекомендую следующее:

1. Настройте параметры брандмауэра в Azure для своей учетной записи хранения.
2. В своем выпуске (или сборке) установите разрешение для своей учетной записи хранения для всех сетей программно, как показано ниже (здесь используется Azure CLI, но вы можете сделать то же самое с помощью Powershell).

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

1. Сделайте все, что вам нужно, чтобы получить доступ к своей учетной записи хранения.
2. Немедленно сбросьте настройки сети обратно на Deny. Если установлено значение «Запретить», будут учитываться ваши настройки, которые были ранее установлены на шаге 1.

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

Надеюсь, это вам поможет.

@XiaoningLiu

Есть ли способ получить диапазон IP-адресов / общедоступный IP-адрес? Я попытался просто использовать curl на https://ipecho.net/ и добавить этот IP (все в задаче, находясь в конвейере), но, похоже, это не совсем работает. В идеале мы могли бы просто получить диапазон IP-адресов от используемого агента, добавить его в белый список и сразу же удалить. Таким образом, нам не нужно запускать какое-то задание, которое анализирует еженедельный набор IP-адресов для нашего региона (ов).

Здесь та же проблема. Использование Azure DevOps для развертывания ресурсов Azure с помощью Terraform. Из-за требований безопасности нам нужно включить правила брандмауэра VNET. Как только мы включаем его, Terraform не может получить информацию об учетной записи хранения (403) из Azure DevOps, и конвейер развертывания прерывается.

«Разрешить доверенным службам Microsoft доступ к этой учетной записи хранения» включен, но очевидно, что Azure DevOps не распознается как таковая ...

Есть какие-нибудь новости по этому поводу? мы хотим, чтобы наши учетные записи хранения были защищены, но мы также хотим развернуть и использовать DevOps Pipelines. и с такими же проблемами, как и у всех здесь.

Вот как узнать, какие есть диапазоны IP-адресов. https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@artisticcheese

Я думаю, проблема в том, что для использования этого XML потребуется некоторая автоматизация или процесс, который поддерживает черный список и удаляет старые IP-адреса.

В идеале должен быть способ получить IP-адрес машины, которую вы используете при запуске размещенного агента, таким образом вы можете сделать что-то похожее на то, что я описал выше, за исключением одной машины (той, на которой выполняется задание DevOps) .

Да, в дополнение к этому брандмауэр, похоже, в любом случае ограничен только 100 записями, так что это не сработает.

Мы работаем над планом, чтобы включить определения «тегов» или «псевдонимов», чтобы служба могла определять такие диапазоны. еще не расчетное время прибытия.

пожалуйста, закрой

Почему эта проблема закрывается, хотя она не решена?
«... работа над планом ... на самом деле не решает проблему.

@nickforr Так как мы над этим работаем. У меня еще нет расчетного времени прибытия,

В настоящее время возникает та же проблема, есть ли какие-нибудь обновления?

@ SumanthMarigowda-MSFT или @cbrooksmsft - есть ли способ отслеживать связанный с этим запрос функции - даже если вам неудобно делиться ETA, было бы полезно получить уведомление, когда это будет сделано.
Благодаря!

Подобно тому, что предлагает @tabeth, во многих случаях я менял правила брандмауэра для разных ресурсов (sql, function app и т.д.), чтобы разрешить временный трафик с IP-адреса агента DevOps. Однако это не работает для учетных записей хранения, из - за этого :

Правила IP-сети не влияют на запросы, исходящие из того же региона Azure, что и учетная запись хранения.

@cbrooksmsft Не могли бы вы объяснить, почему вы просили закрыть этот вопрос? Это все еще не работает. Если эта проблема возникла не в том месте, не могли бы вы предоставить ссылку на то, где возникла ошибка замены, которая отслеживает эту проблему, чтобы она была решена?

Этот вопрос был поднят 24 ноября 2018 г. Возможно, его по ошибке попросили закрыть без создания правильной проблемы замены? Я спрашиваю, потому что прошло 2 года, и похоже, что эта ошибка все еще существует?

Предлагаемые здесь обходные пути (простое удаление защиты) могут поставить под угрозу данные клиентов.

пожалуйста, порекомендуйте,

TXS
Алан

Казалось, что они планируют получить его во втором квартале 2020 года.
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

@artisticcheese вы связали с очень широким объявлением. Как вы думаете, в какой части этого объявления рассматривается эта проблема? Если вы имеете в виду «служебные теги», то разве это не решает проблему? Сервисные теги выглядят как полезная группировка правил для каждого «тега», и описанная здесь проблема все еще существует. (в частности, локальный azure DevOps не попадает в белый список автоматически путем включения --bypass "Logging Metrics AzureServices Возможно, я что-то пропустил?

Напомним всем, кто не знаком с этой веткой; когда я создаю ресурс хранилища azure для использования в конвейере azure DevOps, как показано ниже

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" 

если в моем конвейере azure DevOps есть шаг, который использует AzureFileCopy@3 например

    - 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 для конвейеров не поддерживается.

Я тоже столкнулся с той же проблемой. Кто-нибудь может официально подтвердить, что это все еще планируется?

Я не могу подключить размещенный агент Microsoft конвейер Azure Devops к учетной записи хранения. Будет ли это решено

@cbrooksmsft , пожалуйста, ответьте на вопросы выше? вы просили закрыть проблему, но, похоже, она не решена?
Если это действительно было решено, со стороны Microsoft было бы (профессионалом) со стороны Microsoft хотя бы прокомментировать здесь, чтобы сказать: «Эй, ребята, это исправлено с помощью X».

Та же проблема

К вашему сведению: https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

Ссылка на грядущие изменения сервисных тегов. Это все еще не решает нашу проблему:

_Эта метка обслуживания не применяется к размещенным агентам Microsoft. Клиенты по-прежнему должны разрешить размещение агентов Microsoft на всей территории.

Ссылка на грядущие изменения сервисных тегов. Это все еще не решает нашу проблему:

_Эта метка обслуживания не применяется к размещенным агентам Microsoft. Клиенты по-прежнему должны разрешить размещение агентов Microsoft на всей территории.

Ссылка на грядущие изменения сервисных тегов. Это все еще не решает нашу проблему:

_Эта метка обслуживания не применяется к размещенным агентам Microsoft. Клиенты по-прежнему должны разрешить размещение агентов Microsoft на всей территории.

Ссылка на грядущие изменения сервисных тегов. Это все еще не решает нашу проблему:

_Эта метка обслуживания не применяется к размещенным агентам Microsoft. Клиенты по-прежнему должны разрешить размещение агентов Microsoft на всей территории.

Правда, не читал толком 😓

Я столкнулся с той же проблемой, и я искренне удивлен, что эта проблема была закрыта. Моя первая мысль была , что я буду иметь , чтобы построить запланированный инструмент для разбора их еженедельного файла в формате JSON здесь со всеми диапазонами IP, но они не появляются , чтобы обеспечить API для этого. Итак, мой лучший вариант - вручную загружать файл JSON каждую неделю, передавать его в какой-то процесс синтаксического анализа, а затем подталкивать диапазоны IP-адресов (мы говорим о сотнях) в настройки брандмауэра учетной записи хранения? Конечно, есть способ получше. Да ладно, Microsoft!

Есть 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. Это производственное приложение, и это слишком рискованно. Кроме того, этот метод потребует сотен записей в брандмауэре учетной записи хранения, чтобы просто позволить моему размещенному конвейеру Azure скопировать несколько файлов. Это выполнимо, но для моих целей это перебор.

Господа, я собрал вас сегодня здесь, чтобы просить вас проголосовать! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

Это нужно исправить как можно скорее, это постоянная проблема в течение последних двух лет ... поделитесь, напишите в Твиттере, помогите исправить и сделайте это на радаре Microsoft 👍

@renattomachado @mimckitt @ Адамса-MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda-MSFT @solaomoDevOps @shahiddev @ Marcin-В.Т. @goblinfactory @artisticcheese @lymedo @ felipecruz91 @pratimvengurlekar @justinimel @ Marcin-VT @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 Если вы не проверяете IP, найденный ipinfo, вы предполагаете, что он не был взломан ... Будьте осторожны с производственной средой!

@arkiaconsulting Определенно риск, но в моем конкретном случае использования не проблема. Развертывания всегда «контролируются». Худшее, что может случиться, - это сбой на этапе развертывания. В этом случае:

1. Уведомление по электронной почте отправлено
2. IP удаляется сразу без зависимости от успешности шага развертывания

К сожалению, это https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html. был закрыт. Надеюсь, они рассмотрят возможность повторного открытия и изучения проблемы.

Я не слежу за этой веткой ... она слишком старая, но все еще проблема. Я не думаю, что это правильно, это должно быть помечено как "закрыто" ... Я воздержусь от комментариев ... но жизнь должна продолжаться ... так ... ниже я использую обходной путь, который похоже, у меня хорошо работает, т.е.

• использовать ключ хранения
• и используйте * az storage blob upload-batch *
• сделай все это в PowerShell

этот подход может не сработать для вас, но на всякий случай вот пример сценария PowerShell, который пока работает для меня в любом конвейере DevOps, вы можете поэкспериментировать с ним и посмотреть, работает ли он и в вашем конвейере?

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

Преимущество этой оболочки PowerShell заключается в том, что вы можете запускать ее локально точно так же, как и в агенте сборки DevOps. легче настроить при локальном запуске.

надеюсь, полезно.

удачи

С уважением

Алан

Это все еще проблема. Пожалуйста, откройте это заново.