При использовании Azure Managed Service Identity, AKS, AAD и хранилища ключей. Все ли эти ресурсы должны быть в одной подписке / группе ресурсов или в VNET?

В основном у меня есть установка, в которой у меня есть

  • Подписка Hub-Spoke и топология vnet в Azure.
  • AAD для внутренних пользователей и доступа разработчиков и b2c для внешних пользователей.
  • AAD и Keyvault находятся в подписке HUB / VNET.
  • API-интерфейсы, развернутые в кластерах Azure AKS, находятся в подписке на лучах.
  • Также есть управление API, выходящее на API, которое находится в той же подписке и VNET, что и AKS / API, а также в подписке Spoke.

Учитывая приведенную выше настройку, у меня есть следующие вопросы

  1. Все API, управление API, Keyvault и Azure AD должны быть привязаны к одной и той же подписке, или я могу иметь Keyvault в моей подписке на хаб, а другие службы - в разных подписках.
  2. Регистрируем ли мы каждый API как приложение в том же AAD, что и KEYVAULT, или мы можем просто зарегистрировать управление API и использовать управление API для получения секретов.
  3. Можем ли мы использовать удостоверение управляемой службы, даже если компоненты находятся в разных подписках, но зарегистрированы в одной и той же Azure AD?

azure azure-aks architecture azure-api-management azure-active-directory
person Preet Singh    schedule 05.07.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

Пока вы предоставляете разрешения для ресурса, AAD очень мало осведомлен о подписках (подписки - это, по сути, один большой ресурс, которому вы можете предоставить права)

Отредактировано для уточнения расширенных политик доступа

Для хранилища ключей существует три расширенных политики доступа.

  • enabledForDeployment
  • enabledForDiskEncryption
  • enabledForTemplateDeployment

Политика enabledForTemplateDeployment применяется только в том случае, если вы читаете секрет из развертывания шаблона ARM. т.е. если вы передаете пароль виртуальной машины непосредственно из хранилища ключей.

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

person Michael B    schedule 05.07.2018
comment
Мы будем использовать доступ ARM (развертывание ARM, если вы это имеете в виду) - person Preet Singh; 05.07.2018
comment
@PreetSingh Я обновил ответ, надеюсь, он проясняет. - person Michael B; 05.07.2018