Доступ к хранилищу ключей Azure из службы приложений Azure JAVA с помощью управляемых удостоверений

Question

У меня есть приложение для весенней загрузки, развернутое в службе приложений Azure, которое получает доступ к хранилищу ключей Azure с использованием удостоверений, управляемых пользователем.

Я выполнил шаги, указанные ниже:

1. Создано удостоверение, управляемое пользователем
2. Развернуто приложение весенней загрузки в службе приложений Azure.
3. Добавлена ​​недавно созданная учетная запись, управляемая пользователем, в службу приложений через параметр идентификации.
4. Добавлена ​​роль, управляемая пользователем, в качестве владельца в разделе "Назначение ролей IAM в службе приложений".
5. Создайте Azure Key Vault и добавьте в него секрет
6. Добавлена ​​учетная запись, управляемая пользователем, в разделе "Политики доступа" только что созданного хранилища ключей с возможностью получения, списка и установки разрешений в разделе "Секретные разрешения"
7. Добавлена ​​роль, управляемая пользователем, в качестве владельца в разделе "Назначение ролей IAM" в Key Vault.

Мой код Java для доступа к Key Vault из приложения выглядит следующим образом:

MSICredentials msiCredentials = new MSICredentials(AzureEnvironment.AZURE);
msiCredentials = msiCredentials.withClientId("client_id");
KeyVaultClient keyVaultClient = new KeyVaultClient(msiCredentials);
SecretBundle secretBundle = keyVaultClient.getSecret("key_vault_base_url","secret_name");

При выполнении этого кода в развертывании службы приложений Azure я получаю следующую ошибку:

java.net.ConnectException: соединение отклонено (соединение отклонено)] с основной причиной 2020-02-18T10:21:14.800677788Z 2020-02-18T10:21:14.800684689Z java.net.ConnectException: соединение отклонено (соединение отклонено) 2020-02-18T10:21:14.800689989Z в java.net.PlainSocketImpl.socketConnect(собственный метод) ~[na:1.8.0_232] 2020-02-18T10:21:14.800695689Z в java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_232] 2020-02-18T10:21:14.800700989Z в java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[na:1.8.0_232] 2020-02-18T10:21:14.800706089Z в java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[na:1.8.0_232] 2020-02-18T10:21:14.800711089Z в java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[na:1.8.0_232] 2020-02-18T10:21:14.800716189Z в java.net.Socket.connect(Socket.java:607) ~[na:1.8.0_232] 2020-02-18T10:21:14.800720890Z в java.net.Socket.connect(Socket.java:556) ~[na:1.8.0_232] 2020-02-18T10:21:14.800725790Z на sun.net.NetworkClient.doConnect(NetworkClient.java:180) ~[na:1.8.0_232] 2020-02-18T10:21:14.800730590Z на sun.net.www.http.HttpClient.openServer(HttpClient.java:463) ~[na:1.8.0_232] 2020-02-18T10:21:14.800735490Z на sun.net.www.http.HttpClient.openServer(HttpClient.java:558) ~[na:1.8.0_232] 2020-02-18T10:21:14.800740290Z на sun.net.www.http.HttpClient.(HttpClient.java:242) ~[na:1.8.0_232] 2020-02-18T10:21:14.800745390Z на sun.net.www.http.HttpClient.New(HttpClient.java:339) ~[na:1.8.0_232] 2020-02-18T10:21:14.800750191Z в вс.NET.www.http.HttpClient.New(HttpClient.java:357) ~[na:1.8.0_232] 2020-02-18T10:21:14.800755291Z в вс.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1226) ~[na:1.8.0_232] 2020-02-18T10:21:14.800760191Z на sun.net.www.protocol.http.HttpURLConnection0.plain (HttpURLConnection.java:1162) ~[na:1.8.0_232] 2020-02-18T10:21:14.800765091Z на sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1056) ~[na:1.8.0_232] 2020-02-18T10:21:14.800769991Z на sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:990) ~[na:1.8.0_232] 2020-02-18T10:21:14.800784292Z на sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1570) ~[na:1.8.0_232] 2020-02-18T10:21:14.800790492Z на sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498) ~[na:1.8.0_232] 2020-02-18T10:21:14.800795392Z на java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) ~[na:1.8.0_232] 2020-02-18T10:21:14.800800192Z по адресу com.microsoft.azure.credentials.MSICredentials.retrieveTokenFromIDMSWithRetry(MSICredentials) ~ MSICredentials (MSICredentials). -client-authentication-1.6.12.jar!/:na] 2020-02-18T10:21:14.800804992Z в com.microsoft.azure.credentials.MSICredentials.getTokenFromIMDSEndpoint(MSICredentials.java:205) ~[azure-client-authentication-1.6.12.jar!/:na] 2020-02-18T10:21:14.800809692Z в com.microsoft.azure.credentials.MSICredentials.getToken(MSICredentials.java:146) ~[azure-client-authentication-1.6.12.jar!/: Na] 2020-02-18T10:21:14.800814392Z в com.microsoft.azure.credentials.AzureTokenCredentials.getToken(AzureTokenCredentials.java:74) ~[azure-client-runtime-1.6.12.jar!/:na] 2020-02-18T10:21:14.800819093Z на com.microsoft.azure.credentials.AzureTokenCredentialsInterceptor.intercept(AzureTokenCredentialsInterceptor.java:36) ~[azure-client-runtime-1.6.12.jar!/: Na]

Глядя на код MSICredentials.java в Azure SDK, я мог видеть, что запрос на следующий URL - http://169.254.169.254/metadata/identity/oauth2/ получает отказ.

Может ли кто-нибудь помочь мне в настройках, чтобы решить эту проблему? Мне не хватает какой-нибудь конфигурации? Любые указатели будут действительно полезны.

Answer 1

Удалось решить проблему с использованием удостоверения, управляемого системой, а не удостоверения, управляемого пользователем, поскольку удостоверение, управляемое пользователем, в настоящее время не работает с Azure KeyVault.

Создал репозиторий в GitHub, содержащий образец кода для подключения к ресурсам Azure из AppService с использованием системной управляемой идентификации. Ссылка на репо выглядит следующим образом - https://github.com/gandhirajan/Azure_AppService_ManagedIdentity