Используйте Azure Управляемые удостоверения для обслуживания звонков

Question

Прямо сейчас я использую приложение AAD для выполнения вызовов Service A => Service B. Это включает:

1. приложение AAD
2. KeyVault, которое хранит секрет / сертификат для приложения AAD
3. Управляемое удостоверение с доступом к KeyVault

Процесс выглядит следующим образом:

1. Служба A: получить токен из Managed Identity
2. Служба A: Go в KeyVault, представить токен и получить секрет для приложения AAD
3. Служба A: Go для AAD, предоставление секрета и запрос токена для определенного ресурса
4. Служба A: вызов службы B
5. Служба B: проверка токен и ресурс

Интересно, можно ли зарегистрировать управляемый идентификатор в моей службе, поэтому, если представлен токен управляемого идентификатора, то служба B может доверять службе A. Что-то вроде этого:

1. Служба A: получение токена из управляемого идентификатора
2. Служба A: вызов в службу B
3. Служба B: проверка того, что токен получен из зарегистрированного управляемого удостоверения

Возможно ли это? Нарушает ли это какие-либо рекомендации по обеспечению безопасности?

Обновление: рядом с ответом ниже, в следующем посте о переполнении стека описано, как сделать управляемую идентификацию в одном арендаторе, чтобы получить заявку на роль для приложения в другом арендатор

Предоставить основной сервисной службе доступ к приложению у другого арендатора

Answer 1

Извините, я не могу комментировать ответ juunas, так как у меня недостаточно репутации, чтобы комментировать. Просто хотел сказать, что решение, рекомендованное juunas, сработало для меня только после того, как я перезагрузил виртуальную машину, с которой я пытался получить токен, используя назначенный пользователем управляемый идентификатор . Идея перезагрузить ВМ пришла из статьи ниже. В этой статье также рекомендуется использовать то же решение, что и в juunas, но также упоминается перезагрузка виртуальной машины для очистки кэша, если токен не показывает роли после выполнения рекомендуемых действий. https://www.jasonfritts.me/2019/07/15/assigning-azure-ad-graph-api-permissions-to-a-managed-service-identity-msi/

Answer 2

Я написал статью в блоге на эту тему c: https://joonasw.net/view/calling-your-apis-with-aad-msi-using-app-permissions.

Вы определенно можете это сделать, это будет означать, что вам не нужно использовать любые секреты вызова Сервиса B из Сервиса A:)

Вам необходимо будет назначить разрешения приложения для субъекта управляемой службы идентификации с помощью PowerShell / Graph API. Там нет интерфейса для этого. Пример команды PowerShell:

New-AzureADServiceAppRoleAssignment -ObjectId 1606ffaf-7293-4c5b-b971-41ae9122bcfb -Id 32028ccd-3212-4f39-3212-beabd6787d81 -PrincipalId 1606ffaf-7293-4c5b-b971-41ae9122bcfb -ResourceId c3ccaf5a-47d6-4f11-9925-45ec0d833dec

ObjectId и PrincipalId - это сгенерированный MSI идентификатор участника службы. Идентификатор - это идентификатор роли. ResourceId - это идентификатор субъекта службы API.

При этом используется модуль AzureAD PowerShell.

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

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