Не удалось получить секрет из хранилища ключей Azure, используя назначенную пользователем идентификационную информацию

Question

Я добавил MSI в VMSS, проверив ComputerResourceGroupInfo.json в ElasticAPV2.xts, у меня есть:

"ManagedServiceIdentityConfig": {
          "Type": "SystemAssigned, UserAssigned",
          "**UserAssignedIdentities**": [
            "/subscriptions/1234567890qwer/resourceGroups/my-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-msi"
          ],
          "ServicePrincipalForSystemAssignedIdentity": "...",
          "ScaleSetIdentity": {
            "principalId": "...",
            "tenantId": "...",
            "type": "SystemAssigned, UserAssigned",
            "**userAssignedIdentities**": {
              "/subscriptions/1234567890qwer/resourceGroups/my-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-msi": {
                "principalId": "...",
                "clientId": "..."
              }

my-msi также добавляется в политику доступа к хранилищу ключей Azure с помощью List и Get.

В ВМ пытались получить секрет используя

PS D:\ManagementServiceCommonSetup> $accessToken = (Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -Method GET -Headers @{Metadata="true"} -UseBasicParsing | ConvertFrom-Json).access_token
PS D:\ManagementServiceCommonSetup> echo $accessToken
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IkN0ZlFDOExlLThOc0M3b0MyelFrWnBjcmZP...MCQi-bPCJQ
PS D:\ManagementServiceCommonSetup> (Invoke-WebRequest -Uri https://my-kv.vault.azure.net/certificates/my-cert/587898f2?api-version=2016-10-01 -Method GET -Headers @{Authorization="Bearer $accessToken"}).content
Invoke-WebRequest : {"error":{"code":"Forbidden","message":"Access denied","innererror":{"code":"AccessDenied"}}}
At line:1 char:2
+ (Invoke-WebRequest -Uri https://my-kv.vault.azure.net/secrets/my-cert/ ...
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Мои вопросы:

1. Является ли это правильным способом получения сертификата с использованием токена доступа через назначенную пользователем идентификационную информацию?
2. Почему в доступе отказано? Насколько я понимаю, контроль доступа (IAM) здесь не нужен, так как я добавил MSI для политик доступа.

Обновление:

Для идентификатора, назначенного пользователем, необходимо указать идентификатор объекта или идентификатор клиента.

Invoke-WebRequest -Uri "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net&object_id=$($ObjectId)" -Method GET -Headers @{Metadata="true"}

Answer 1

1. Это правильный способ получения сертификата с использованием токена доступа через назначенную пользователем идентификационную информацию?

Нет, Uri, который вы использовали, является секретным, если вы хотите получить сертификат, он должен быть

Invoke-WebRequest -Uri https://my-kv.vault.azure.net/certificates/my-cert/587898f2?api-version=2016-10-01 -Method GET -Headers @{Authorization="Bearer $accessToken"}

Справка: Получить сертификат - Получить сертификат

2. Почему в доступе отказано? Насколько я понимаю, контроль доступа (IAM) здесь не нужен, так как я добавил MSI для политик доступа.

Ваше понимание верно. Проверьте это в Access policies еще раз, убедитесь, что вы дали Certificate permissions (Вы также можете попробовать Select all, это удобно).

Обновить:

Я проверяю это в Windows VM, в VMSS, логика должна быть одинаковой, документация VM и VMSS для доступа к keyvault вместе.

И если я проверю с system-assigned identity работает нормально. Если я проверю это с user-assigned managed identity Я также получаю ошибку 403.

user-assigned managed identity функция предварительного просмотра, я не уверен, поддерживает ли она доступ к keyvault, документ предназначен только для system-assigned identity, Поэтому я рекомендую вам использовать system-assigned identity чтобы получить доступ к keyvault, вы можете попробовать.

$response = Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -Method GET -Headers @{Metadata="true"} -UseBasicParsing
$content = $response.Content | ConvertFrom-Json 
$KeyVaultToken = $content.access_token 
(Invoke-WebRequest -Uri https://<keyvault-name>.vault.azure.net/certificates/<{certificate-name}>/<certificate-version>?api-version=2016-10-01 -Method GET -Headers @{Authorization="Bearer $KeyVaultToken"} -UseBasicParsing).content 

назначенный системой идентификатор:

назначенный пользователем управляемый идентификатор:

Answer 2

Для идентификатора, назначенного пользователем, необходимо указать идентификатор объекта или идентификатор клиента.

 Invoke-WebRequest -Uri "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net&object_id=$($ObjectId)" -Method GET -Headers @{Metadata="true"}

Answer 3

@Daolin, я тестировал тот же сценарий запроса токена доступа из AAD с использованием UserManagedIdentity.

У меня работал следующий cmd:

$response1 = Invoke-WebRequest -Uri "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/&object_id=xxxxxx-xxxx-xxxx-xxxxx-xxxxx" -UseBasicParsing -Method GET -Headers @{Metadata="true"}   

Теперь объект - это PrincipalID/ObjectID. ClientID у меня не работал. В моем случае я использую виртуальную машину Azure с включенными как SystemManagedIdentity, так и UserManagedIdentity. Следовательно, когда я запрашиваю токен доступа, используя clientID в качестве параметра запроса, он выдает мне токен доступа с идентификатором объекта System Managed Identity в нем.