Azure Key Vault для управления секретами в производстве и разработке

Question

Кажется, что Azure Key Vault не поддерживает политики доступа, назначенные группам; только те, которые назначены пользователям или принципам обслуживания. Он также поддерживает максимум 10 политик доступа для каждого хранилища ключей, что означает, что я не могу назначить всех людей, которых я хочу иметь доступ по отдельности.

Я не хочу передавать клиентские секреты всем разработчикам. В случае развернутого приложения передача одного секретного клиента, чтобы код мог аутентифицироваться в качестве принципала службы, а затем получить секреты в порядке.

Разработчики проходят аутентификацию AAD через NTLM/Kerberos (через ADFS), чтобы получить токен доступа (а не через секрет клиента). Получив этот токен доступа, они должны иметь доступ к безопасно сохраненным формам всех других секретов, необходимых для запуска нашего приложения (так же, как это делает производственный код при аутентификации в качестве принципала службы).

Как это сделать?

Answer 1

Редактировать: теперь группы могут быть связаны с политиками доступа к ключам. Просто укажите идентификатор объекта группы, где вы обычно ставите идентификатор объекта пользователя или идентификатор объекта главной службы.

Это немного болезненным обходным, но ...

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