Ключи хранилища ключей только для доступа к приложению Azure
У меня многопользовательское приложение. Мне нужно это приложение, чтобы:
- Иметь возможность считывать ключи во всех хранилищах всех арендаторов (предоставивших согласие).
- Не быть в состоянии прочитать любой из секретов.
Мне удается получить полный доступ к Хранилищам, используя делегированное разрешение (олицетворение пользователя). Однако это не то, чего я хочу, потому что это разрешение также дает мне доступ к секретам.
Я видел (здесь), что есть роль только для доступа к ключам.
Имя роли: Key Vault Crypto Officer (id: 14b46e9e-c2b7-41b4-b07b-48a6ebf60603)
Вопрос: Можно ли заставить мое приложение требовать (только?) эту роль. Что позволит ему читать ключи, но не секреты? Не уверен, что правильно думаю о ролях, у меня мало опыта в этом.
Обратите внимание, что я не против попросить делегированные разрешения / разрешения приложения, если это имеет значение.
Спасибо
Ответы 1
Обратите внимание, что невозможно прочитать ключи в хранилищах всех арендаторов с помощью мультитенантного приложения.
Назначение роли Key Vault Crypto Officer мультитенантному приложению по подписке дает доступ только для чтения ключей всех хранилищ ключей только в одном арендаторе, связанном с этой подпиской, а не в других арендаторах.
Я попытался воспроизвести то же самое в своей среде и получил следующие результаты:
Я создал одно хранилище ключей с именем srikv07, выбрав управление доступом на основе ролей Azure в конфигурации доступа, как показано ниже:
В приведенном выше хранилище ключей я создал несколько таких ключей и секретов:
Ключи:
Секреты:
Теперь я зарегистрировал одно мультитенантное приложение Azure AD с именем KVmultiapp, как показано ниже:
В рамках моей подписки я назначил роль Key Vault Crypto Officer этому мультитенантному приложению:
Перейдите на портал Azure -> Подписки -> Выберите подписку -> Управление доступом (IAM) -> Добавить назначение ролей.
Теперь я сгенерировал токен доступа, используя поток учетных данных клиента через Postman, как показано ниже:
POST https://login.microsoftonline.com/common/oauth2/v2.0/token
client_id: <appID>
grant_type:client_credentials
scope: https://vault.azure.net/.default
client_secret: <secret>
Ответ:
Когда я использовал этот токен для чтения ключей хранилища ключей RBAC enabled, я получил ошибку, как показано ниже:
GET https://<yourkvname>.vault.azure.net//keys?api-version=7.3
Ответ:
Чтобы устранить ошибку, вам нужно включить tenantID при создании токена доступа, как показано ниже:
POST https://login.microsoftonline.com/<tenantID>/oauth2/v2.0/token
client_id: <appID>
grant_type:client_credentials
scope: https://vault.azure.net/.default
client_secret: <secret>
Ответ:
Теперь я использовал этот токен для получения ключей и успешно получил ответ, как показано ниже:
GET https://<yourkvname>.vault.azure.net//keys?api-version=7.3
Ответ:
Когда я использовал тот же токен для получения секретов хранилища ключей, я получил ошибку 403 Forbidden, поскольку роль дает доступ только к ключам.
GET https://<yourkvname>.vault.azure.net//secrets?api-version=7.3
Ответ:
Не совсем. Предпочтительным решением было бы без какой-либо работы на стороне клиента, а не вручную через лазурный пользовательский интерфейс и не через скрипты. Всего один клик на странице согласия, чтобы предоставить приложению необходимые разрешения. Могу ли я использовать манифест приложения, чтобы приложению требовалась роль «Офицер шифрования хранилища ключей»?
Назначение ролей Azure RBAC путем изменения файла манифеста приложения невозможно. Вы можете сделать это только через Portal, CLI, PowerShell или REST API. Проверьте это. Эта страница согласия работает только для областей Azure AD, таких как MS Graph и т. д., но не для ресурсов Azure, для которых требуются роли RBAC.
Большое спасибо @Sridevi за подробный ответ. Единственная проблема, с которой я столкнулся, связана с шагом «назначить роль Key Vault Crypto Officer». Я не хочу, чтобы мои клиенты выполняли какую-либо ручную работу (например, назначали роль моему приложению). Итак, можно ли что-то добавить в файл манифеста моего приложения? так что для этого требуется назначение роли Crypto Officer или что-то в этом роде? Цель состоит в том, чтобы избежать ручной работы/настройки клиентов, использующих мультитенантное приложение.