Azure-docs: Azure DevOps Build Pipeline не может получать секреты из Key Vault при защите с помощью vnet и брандмауэра

@ aspnet4you Спасибо за отзыв.
Мы ведем активное расследование и скоро свяжемся с вами.

@ KalyanChanumolu-MSFT - Спасибо, что разобрались с проблемой. Key Vault - это критически важный компонент инфраструктуры, и в силу его характера деятельности мы не хотим предоставлять его в ненадежные сети. Если бы у меня была машина для сборки, все было бы хорошо, но моя цель - использовать Azure DevOps для CI / CD. Мне нужно сохранить ключи и секреты и иметь возможность безопасно их получить.

@ aspnet4you , Спасибо, что поделились запросом. Внесение IP-адресов в белый список не является эффективным способом, но это определенно обходной путь. Мы работаем с командой разработчиков продуктов, чтобы сделать Azure Dev Ops надежной службой для Azure Key Vault, и это было бы полным исправлением во всех отношениях. Позвольте нам когда-нибудь, и я поделюсь с вами своими следующими обновлениями.

Вы можете добавить шаг в определение сборки, чтобы внести IP-адрес агента в белый список, а затем удалить его из белого списка в конце сборки. Это не решение, а обходной путь, пока группа разработчиков продукта Azure не добавит Azure DevOps в качестве доверенной службы. Спасибо @ Daniel Mann за идею.

Решение простое, но я не собирался доверять ipify.org как конечной точке REST API для получения IP-адреса моего агента сборки. Вместо этого я создал свою собственную (и надежную) службу в Azure Function- GetClientIP. DevOps - не моя повседневная работа, и мне было трудно понять, как назначать и использовать определенные пользователем переменные и передавать их следующему шагу / задаче / этапу в конвейере! Документация Microsoft по использованию переменных не помогла мне достаточно, но я понял это после множества неудачных запусков!

См. Полное решение в моем блоге - Azure DevOps Build Pipeline - используйте ключи и секреты из Key Vault .

@ aspnet4you , ведутся разговоры о получении Azure DevOps в качестве доверенной службы. У Azure DevOps есть отдельный сценарий, в котором удостоверение, которое обращается к Key Vault, принадлежит клиенту, а не Microsoft. Это нарушает требования к масштабируемости и безопасности «доверенной службы».

На данный момент единственный обходной путь - это добавление IP-адресов машин DevOps в брандмауэр AKV. Это меньшее подмножество, чем все IP-адреса Datacenter, и оно соответствует ограничению в 127 IP-правил.

В настоящее время я работаю над получением IP-адресов и вскоре обновлю тему.

@ aspnet4you , пожалуйста, найдите подробную информацию об IP-адресах ниже:

Для внесения в белый список служб AzureDevops - https://docs.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops

Для внесения размещенных агентов в белый список - https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#agent -ip-range

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

@ aspnet4you , надеюсь, это поможет. Не стесняйтесь обращаться к нам, если по этому поводу возникнут дополнительные вопросы. На данный момент мы закрываем эту тему.

@ souravmishra-msft, похоже, что белых списков сервисов azure DevOps, IP в ссылке недостаточно.
Например, пытаясь связать группу переменных из DevOps с секретами из keyvault, мне нужно было также добавить ip: 52.236.xx (я намеренно скрыл lat 2 байта). Вы знаете, откуда эти ip? Можете ли вы предоставить полный набор IP-адресов для связывания групп переменных DevOps?

@ aspnet4you , Спасибо, что поделились запросом. Внесение IP-адресов в белый список не является эффективным способом, но это определенно обходной путь. Мы работаем с командой разработчиков продуктов, чтобы сделать Azure Dev Ops надежной службой для Azure Key Vault, и это было бы полным исправлением во всех отношениях. Позвольте нам когда-нибудь, и я поделюсь с вами своими следующими обновлениями.

Есть обновления по этой функции? Есть ли ссылка для отслеживания функции Azure Dev Ops как доверенной службы для Azure Key Vault?

Тот же запрос для других предложений PAAS для конечных точек службы VNET - https://feedback.azure.com/forums/217298-storage/suggestions/35850511-make-azuredevops-a-trusted-microsoft-services-to

@ aspnet4you , как достаточно одного белого IP-

@oviliz - Очень хороший вопрос. Внесение IP в белый список - одна из последних мер защиты от несанкционированного доступа к хранилищу. Субъект-служба должен быть настроен с помощью политики доступа к хранилищу ключей для получения списка и получения ключей и секретов. Это второе требование, изложенное в моем сообщении - Azure DevOps Build Pipeline - используйте ключи и секреты из Key Vault .

Привет @ KalyanChanumolu-MSFT есть обновления? Сегодня я столкнулся с той же проблемой. Я не могу получить секрет из своего KV на этапе Azure Key Vault в моем конвейере выпуска (Azure DevOps). Связи с указанными выше IP не работают ... Итак, как я могу получить секреты в моем конвейере? Разрешить доверенным службам Microsoft обходить этот брандмауэр? (Да) - тоже не помогло.

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

Кстати, в упомянутых выше статьях говорится, что диапазоны IP-адресов могут меняться еженедельно. Предлагать обновлять брандмауэр еженедельно и даже пытаться отслеживать изменения - довольно смешно.

Я столкнулся с той же проблемой, и еженедельное внесение IP-адресов в белый список вообще не вариант.

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

FWIW Это решение меня вдохновило здесь: https://www.visualstudiogeeks.com/DevOps/PrivateAzureAseV2AppServiceVstsDeploymentUsingAzureDtl

Добавьте нас в список. Как может быть, что ADO не является доверенным сервисом для хранилищ ключей?

Если вы ищете в еженедельных файлах DevOps или размещенных агентов, IP-адреса не выделяются. Какие IP-адреса вы используете в https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519 ??? и если вы выполняете поиск по Datacenter, там есть службы приложений, пространства для разработки и т. д., но что соотносится с DevOps и агентами хоста?

@ ShaneBala-keyvault, По просьбе добавляю вас в эту ветку.

Добавьте нас в список. Как может быть, что ADO не является доверенным сервисом для хранилищ ключей?

С вами там, планируете переместить многие проекты в Девопс, но это проблема

+1, это нужно исправить как можно скорее. Даже если секретные переменные конвейера могут использоваться для релизов, я хотел бы иметь единый источник правды. Значение секретной переменной конвейера не может быть просмотрено снова после сохранения, поэтому в любом случае информацию нужно сохранить где-то еще.

ТАК вопрос по этой проблеме:

https://stackoverflow.com/q/61411653/3850405

+1 это действительно критично. Есть какие-нибудь комментарии от Microsoft по этому поводу?

@ souravmishra-msft Может быть, его снова откроют?

@Ogglas Это обязательно нужно открыть заново. Они должны указать IP-адреса или пометить службу для обхода брандмауэра Azure Keyvault. Они делают это для других сервисов, почему не лазурный DevOps?

+1, такая же проблема здесь

+1

также присоединяюсь к кучей ... огромная проблема для меня тоже

Какого черта это близко ???? ссылки ссылки "обходного пути" тоже не работают :)

@jsburckhardt - Не уверен, о каком
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Нужно ли нам создавать для этого новый выпуск или найти способ снова открыть его, @ souravmishra-msft?

@captainbrown , я

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

Я также увеличил внутренний поток, который происходит в этом потоке github, и буду держать вас в курсе прогресса.

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

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

Моя команда и я будем с нетерпением ждать сообщения от вашего менеджера программы.

Спасибо за повторное открытие ... @captainbrown. Я видел ту же проблему, когда документация или файл json со службами ip определенно устарели / не задокументированы должным образом.

Согласен, спасибо за повторное открытие. Это проблема, которую мы действительно хотели бы решить.

@ souravmishra-msft Спасибо, я надеюсь, что скоро это будет приоритетным.

+1, это тоже проблема для нас. Не только доступ Azure DevOps к хранилищу ключей, но нам также необходим конвейер DevOps для создания некоторых файлов и их загрузки в учетную запись хранения, защищенную брандмауэром, но мы сталкиваемся с той же проблемой, что Azure DevOps не является доверенной службой. и обходным путем было бы занести в белый список ~ 250 IP-адресов еженедельно, так что это было бы очень некрасиво (плюс также не уверен, есть ли какое-либо ограничение на количество IP-адресов, которые можно добавить в брандмауэр учетной записи хранения). Было бы здорово, если бы с этим можно было справиться!

В настоящее время существует обходной путь для этой проблемы.

Вы можете использовать собственный агент и добавить следующие диапазоны IPv4 в список разрешений брандмауэра хранилища ключей. Подробности здесь: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops

(Команда Azure DevOps знает об этой проблеме и в настоящее время работает над постоянным исправлением)

Эта функция в настоящее время находится в предварительной версии.

Вот еще одно решение ... вы можете настроить свой собственный vnet с масштабируемым набором.

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/scale-set-agents?view=azure-devops

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

Вы можете открыть брандмауэр для сети Azure / 11, настроить подключение от DevOps к Azure с помощью хранилища ключей. Настройте библиотеку переменных и добавьте секрет. После добавления секретов удалите правило брандмауэра и попробуйте добавить секрет. Сообщение об ошибке передаст вам IP-адрес, который вы можете поместить в брандмауэр. Мы обнаружили, что он не изменился за месяц, и мы понимаем, что он может измениться. На данный момент мы, как и все остальные, ищем обходные пути. Я собираюсь провести дальнейшее тестирование сборок и выпусков, но это позволяет графическому интерфейсу Native Devops напрямую взаимодействовать с Keyvaults.

Опять же, это не работает с личным кабинетом.

+1 у нас похожая проблема с использованием AzDO для SQL-сервера через частную ссылку / конечную точку.

+1 Аналогичная проблема здесь.

Здесь можно найти обходные пути. Это не проблема самого документа. Это обходной путь https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops # пожалуйста-закройте, вы также можете отправить запрос функции здесь https: // developercommunity.visualstudio.com/spaces/21/index.html

Запрос функции здесь:

https://developercommunity.visualstudio.com/idea/1152209/azure-devops-build-pipeline-cant-get-secrets-from-1.html

+1, коснитесь этой проблемы сегодня.

ЕСЛИ Microsoft собирается включить служебные теги для Azure DevOps, можно ли их каким-либо образом использовать в брандмауэре Keyvault? https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

@ JQUINONES82 Боюсь, что не для размещенных агентов. По вашей ссылке:

Метка обслуживания не применяется к размещенным агентам Microsoft.

+1, получая это за последние 2 года

+1, коснитесь этой проблемы сегодня.

Это закрыто, как мне исправить?

Безопасность - это не требование функции, это необходимость любого облачного компонента. Если это не исправлено, можно ли его снова открыть? Я видел упоминание о том, что что-то находится в предварительном просмотре ... Я воспользуюсь функцией предварительного просмотра. Это задержит наше развертывание, так как я не хочу тратить еще больше денег на раскрутку виртуальных машин в лазурном режиме, чтобы сделать это ...

@jsburckhardt - Не уверен, о каком
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Привет, приятель, это хорошее решение. К сожалению, из-за ограничений безопасности. Команда не контролирует IP-адреса KV / vNet из белого списка