Блог

Главная - Вопросы по программированию - Как защитить секреты PROD в функциональном коде Azure?

Как защитить секреты PROD в функциональном коде Azure?

#azure-functions #azure-keyvault #azure-managed-identity

#azure-функции #azure-keyvault #azure-managed-identity

Вопрос:

Мне было бы очень полезно, если бы кто-нибудь мог пролить свет на то, как получить секреты в коде PROD без Contributor роли разработчика в функции Azure.

Сокращения:

  • «SAMI» = назначенное системой управляемое удостоверение
  • «Ent Sec» = Команда корпоративной безопасности

Поток (адаптирован из этого документа Azure Key Vault):

  • Команда Ent Sec загружает секреты в DEV KeyVault и предоставляет разработчику ссылку на секрет разработки
  • Команда Ent Sec добавляет SAMI в политику доступа KeyVault (разработчик не входит в политику доступа)
  • Разработчик добавляет ссылку на секрет разработки в настройку приложения функции Azure (через local.settings.json или App Settings на портале Azure)
  • Разработчик получает код разработки, работающий от начала до конца

Визуальный:

введите описание изображения здесь

Вопросы:

  • Как это будет работать для PROD code?
    • ЕСЛИ разработчик имеет Contributor роль в функциональном коде PROD Azure, им видны все секреты; это отменяет Политику доступа к хранилищу ключей Azure (которая разрешает доступ только к приложению SAMI) и использование ссылок на секретные данные хранилища ключей Azure.
  • Есть ли другая роль, которая может быть предоставлена разработчику?
  • Будет ли Ent Sec отвечать за добавление секретов PROD в код PROD?
  • Существует ли конвейер DevOps, который «вводит» правильный секрет в зависимости от ENV?

Ответ №1:

Хотя я не понимаю всей вашей настройки … это должно быть довольно просто с помощью настроек приложения, на которые ссылается KeyVault: https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references

Разработчик может иметь доступ к настройкам приложения, но увидит только что-то вроде этого: @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931)

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

Комментарии:

1. Это тоже было моим первоначальным пониманием, но я нашел в этом пробел. Любой пользователь с Contributor ролью в функции Azure, даже если он НЕ указан в Политике доступа KeyVault, МОЖЕТ ВИДЕТЬ секреты в открытом виде, ДАЖЕ ЕСЛИ ССЫЛКИ ИСПОЛЬЗУЮТСЯ В ИСХОДНОМ КОДЕ. Им просто нужно посетить https://<functionAppName>.scm.azurewebsites.net/Env . В ответ на мой отчет об ошибке по проблеме мне сказали, что это «Предполагаемое поведение», а не ошибка.

2. Кроме того, MS говорит , что разработчик с Contribute ролью может ...run any software they want using identity and have access to everything that identity has. , следовательно, мой пост здесь…

3. возможно, вы хотели опубликовать ссылку на свое обсуждение в репозитории github в своем исходном сообщении … поэтому не уверены, что именно вы ищете? там было дано общее руководство: ни один разработчик не должен иметь доступа на запись (например, роли участника) к PROD. развертывайте только в prod, используя принципы обслуживания и т.д.

4. Мне сказали опубликовать здесь рекомендации. Я ищу «Как». Как мне безопасно получить секреты в коде PROD? Для чего используется шаблон "...deploy to prod using service principals etc." ?

5. Это именно то, по чему я ищу рекомендации … no dev should have write access (such as Contributor role) to PROD. only deploy to prod using service principles etc. . Как развертывается функциональный код PROD с использованием участников службы?