Spring Boot - Azure Key Vault Управление секретами доступа к хранилищу - PullRequest
Новая
       11

Spring Boot - Azure Key Vault Управление секретами доступа к хранилищу

0 голосов
/ 31 марта 2020

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

  • Логическая группировка секретов в одном пространстве / хранилище
  • Возможность HSM
  • Ведение журнала / аудит
  • Одно место для извлечения / изменения секретов, от которых могут зависеть многие приложения, не касаясь приложений.

Что я не получаю, так это как обрабатывать доступ к хранилищу в моих весенних загрузочных приложениях Когда я использую пружинные загрузчики azure -key-vault, мне нужно настроить доступ в application.properties, как в этом руководстве: Как использовать Spring Boot Starter для Azure Key Vault

Но, по моему мнению, я просто защитил свои секреты другим слоем идентификатора / пароля, которые снова в виде простого текста в моем файле .propertes и оказались в системе контроля версий.

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

Я хочу развернуть свои бэкэнды с пружинной загрузкой в ​​виде jar-файлов в ресурсах веб-приложения azure, если это важно для вопроса.

Спасибо заранее

1 Ответ

1 голос
/ 02 апреля 2020

Я разработчик Azure SDK для Key Vault. Azure Key Vault предоставляет централизованное и безопасное хранилище, которое может проверять подлинность нескольких пользователей, участников службы (приложений) или управляемых удостоверений (подробнее об этом в секунду) с различными наборами разрешений. Подобно тому, как сопровождающие могут иметь возможность перечислять, получать и устанавливать секреты, ключи и сертификаты, в то время как приложения и управляемые удостоверения могут иметь возможность только получать и, возможно, перечислять (если вам по какой-то причине необходимо перечислить все секреты, например запуск конфигурации некоторых приложений) процедуры, чтобы заполнить все секреты, соответствующие некоторому образцу). Это дает возможность контролировать, кто и к чему может получить доступ.

В идеале - и в соответствии с рекомендациями - вы по возможности используете управляемые удостоверения. Управляемые удостоверения позволяют запускать ваше приложение с определенным идентификатором, которым управляет Azure. Пароль не указан. Приложение работает под этим именем, , к которому вы можете предоставить доступ в хранилище ключей с любыми разрешениями, имеющими смысл для ваших нужд.

Примеры , такие как тот, на который вы ссылались склоняются к упрощению c примеров для объяснения концепции, но мы поняли и пытаемся обновить документы, подобные этой, чтобы рекомендовать управляемые удостоверения.

Однако секреты приложения все еще могут использоваться довольно безопасно. Типичный подход состоит в том, что только несколько человек знают эти секреты (они сами могут храниться в хранилище ключей, и только несколько человек могут иметь доступ к этому хранилищу ключей для получения списка и получения значений), поскольку вам в любом случае потребуется доступ для их добавления. ), но затем добавьте их как переменные среды в ваше приложение. Azure и другие службы (GitHub, AppVeyor и др. c.) Часто имеют способы защиты секретов.

Например, ваше приложение может использовать переменные среды, которые вы установили перед защитой рук, например: 

AZURE_TENANT_ID="some GUID - doesn't really have to be secret, but doesn't hurt"
AZURE_CLIENT_ID="secret GUID for service principal ID"
AZURE_CLIENT_SECRET="secret value for service principal ID"

Затем, используя наши пакеты Azure. *, Вы можете сделать так, чтобы ваш код делал что-то вроде этого: 

SecretAsyncClient secretAsyncClient = new SecretClientBuilder()
  .vaultUrl("https://myvault.vault.azure.net/")
  .credential(new DefaultAzureCredentialBuilder().build())
  .buildAsyncClient();

String secret;
secretAsyncClient.getSecret("secretName")
  .subscribe(secretWithVersion ->
    secret = secretWithVersion.getValue());

Вы можете использовать это или - лучше - другой принципал службы для развитие. При разработке Azure Key Vault SDK я настроил свой собственный SP, который я использую только для целей разработки, в то время как наши тестировщики используют другой, использующий переменные в Azure DevOps, извлеченные из аутентифицированного соединения Key Vault .

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

Надеюсь, это поможет. Дайте мне знать, если у вас есть дополнительные вопросы.

...