#azure #azure-storage #azure-blob-storage
#azure #azure-blob-хранилище #azure-хранилище #azure-private-link #azure-private-dns
Вопрос:
Мы используем учетную запись хранилища Azure для наших облачных сервисов. Эта учетная запись хранилища является частью виртуальной сети, поэтому доступ к учетной записи хранилища ограничен selected networks и добавляется виртуальная сеть. Это прекрасно работает в наших сервисах.
Проблема возникает, когда мы пытаемся скопировать данные в эту учетную запись хранилища в конвейере Azure. В рамках конвейера мы временно добавляем правило брандмауэра к учетной записи хранилища, чтобы разрешить трафик с IP-адреса агента конвейера на учетную запись хранилища. Затем мы копируем данные (через azcopy) и, наконец, удаляем правило брандмауэра. Это отлично работает на частном агенте. Однако мы также используем частные агенты, размещенные в azure. Проблема в том, что если агент запускается в Azure, для подключения к учетной записи хранилища используются частные IP-адреса Azure, и правило брандмауэра не работает. Это указано в этом документе:
Службы, развернутые в том же регионе, что и учетная запись хранилища, используют частные IP-адреса Azure для связи. Таким образом, вы не можете ограничить доступ к определенным службам Azure на основе их общедоступного диапазона исходящих IP-адресов.
Есть ли какой-либо способ принудительно выполнить внешнюю маршрутизацию? Мне кажется действительно глупым, что при текущей конфигурации мы не можем подключиться к учетной записи хранилища из Azure, и мы можем подключиться с частного агента (или любого другого компьютера) за пределами azure.
Я уже пытался поиграть с routing preference настройками в firewalls and virtual networks разделе учетной записи хранилища и использовать -internetrouting конечную точку, но это не имеет никакого значения.
Комментарии:
1. Согласно вашему описанию.
The whole point is that I need to find some way to avoid using private ip addresses when contacting the storage account. This issue is not specific to a scale set. By default, any azure resource in the same region uses private IP addresses to access the storage accountМы ничего не можем сделать на стороне Azure DevOps. Проблема должна быть больше связана с конфигурацией или настройками Azure. Предлагаю удалить несвязанный тег azure-pipeline.2. Я согласен, я удалил тег azure-pipelines
Ответ №1:
Решение заключается в использовании частных конечных точек. Я имею дело с той же проблемой, и после значительных исследований я обнаружил, что частные конечные точки облегчат доступ по внутренним IP-адресам между удаленной виртуальной сетью, в которой расположены ваши агенты, и виртуальной сетью, в которой расположено ваше хранилище. Я протестировал это и предоставил подробную информацию ниже.
После тестирования я обнаружил, что это работает путем создания частного DNS в виртуальной сети хранилища и настройки ссылки DNS виртуальной сети, которая позволяет виртуальным машинам в удаленной виртуальной сети, где находятся агенты, разрешать подключение учетной записи хранилища к частному IP вместо общедоступного IP. Кроме того, создается сетевой адаптер в удаленной виртуальной сети, который обеспечивает маршрут к частным IP-адресам хранилища.
Таким образом, сетевой адаптер находится в той же виртуальной сети, что и агенты, предоставляющие маршрут для частных IP-подключений, и существует DNS-ссылка для преобразования хранилища в частные IP-адреса, и все это просто работает. Агенты будут полагаться на частный DNS, а не на общедоступный DNS для разрешения имени хоста хранилища, и поэтому агенты будут правильно взаимодействовать с Azure через частные IP-адреса.
Редактировать: я настроил частную конечную точку и подтвердил, что она работает должным образом. Для этого с terraform есть несколько предостережений, которые я изложил в соответствующей проблеме azurerm provider GitHub:
https://github.com/hashicorp/terraform-provider-azurerm/issues/2977#issuecomment-1011183736
Комментарии:
1. Теперь, когда у меня появилась возможность проверить свою теорию, я отредактировал сообщение с выводами. Это работает, как и ожидалось, с некоторыми оговорками. Пожалуйста, прочитайте весь пост еще раз, если вы читали его раньше, потому что я отредактировал второй и третий абзацы.
2. В качестве продолжения я обнаружил, что в некоторых случаях требуется дополнительная настройка. Например, если вы управляете своей инфраструктурой из подсети, отличной от той, в которой расположена ваша конечная точка, вам может потребоваться настроить пиринг или дополнительную конечную точку для подсети, из которой вы запускаете Terraform. Если вы управляете инфраструктурой через Интернет, у вас должна быть настроена VPN и маршруты, позволяющие обмениваться данными с частными IP-адресами Azure. Возможно, вам также потребуется отредактировать файл hosts, чтобы указать частный IP-адрес учетной записи хранения на случай, если DNS недоступен там, где работает terraform.
Ответ №2:
Согласно here, вам необходимо разрешить доступ ко всему центру обработки данных Azure, соответствующему вашему региону. Итак, я думаю о чем-то автоматизированном, что будет запрашивать API, извлекать диапазон IP-адресов и использовать его.
Комментарии:
1. Да, есть 2 пункта, которые вы не учитываете. 1. Azure использует внутренние IP-адреса для доступа к учетной записи хранилища, когда агент развернут в том же регионе, а не внешние IP-адреса. Таким образом, белый список внешних IP-адресов не работает. Во-вторых, мы не используем размещенные в Microsoft конвейерные агенты, но мы развернули набор виртуальных машин (поэтому они являются частными агентами, работающими в облаке). Я обновлю свой вопрос, чтобы прояснить ситуацию
2. Ну, как я теперь понимаю, ваш масштабный набор, содержащий агенты, назначен другой виртуальной сети, отличной от той, в которой есть учетная запись хранилища, и когда вы добавляете исключение, оно все равно не может быть достигнуто. Рассматривали ли вы возможность пиринга двух виртуальных сетей?
3. Прочитайте здесь , может быть, вы чего-то не хватает?
4. Я не думаю, что вы понимаете суть. Я не могу это исправить, поместив агентов в одну и ту же виртуальную сеть (они даже не в одной подписке). И даже если бы я мог, я не хочу этого делать. Все дело в том, что мне нужно найти какой-то способ избежать использования частных IP-адресов при обращении к учетной записи хранилища. Эта проблема не относится к набору масштабов. По умолчанию любой ресурс Azure в том же регионе использует частные IP-адреса для доступа к учетной записи хранилища