Доступ к Azure Key Vault из JAVA Azure Службы приложений с использованием управляемых удостоверений - PullRequest
0 голосов
/ 18 февраля 2020

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

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

  1. Создан пользовательский идентификатор
  2. Развернуто приложение весенней загрузки в Azure Служба приложений
  3. Добавлен вновь созданный идентификатор пользователя в службу приложения через опцию идентификации
  4. Добавлена ​​роль управляемого пользователя как владелец в разделе Назначение ролей IAM в службе приложений
  5. Создать Azure Хранилище ключей и добавил в него секрет
  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: соединение отклонено (соединение отклонено)] с root c ause 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 ( Сокет. java: 607) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800720890Z при java. net .Socket.connect (Сокет. java: 556) ~ [нет : 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 на солнце. net. www.http.HttpClient.openServer (HttpClient. java: 463) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800735490Z на солнце. net. www.http.HttpClient.openServer (HttpClient. java: 558) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800740290Z на солнце. net. www.http.HttpClient. (HttpClient. java: 242) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800745390Z на солнце. 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 на солнце. net. www.protocol.http.HttpURLConnection.plainConnect0 (HttpURLConnection. java: 1162) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800765091Z на солнце. net. www.protocol.http.HttpURLConnection.plainConnect (HttpURLConnection. java: 1056) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800769991Z на солнце. net. www.protocol.http.HttpURLConnection.connect (HttpURLConnection. java: 990 ) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800784292Z на солнце. net. www.protocol.http.HttpURLConnection.getInputStream0 (HttpURLConnection. * 1 099 *: 1570) ~ [na: 1.8.0_232] 2020-02-18T10: 21: 14.800790492Z на солнце. 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. java: 269) ~ [azure -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/ получает отказ.

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

1 Ответ

1 голос
/ 22 февраля 2020

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

Создано хранилище в GitHub, содержащее Пример кода для подключения к Azure ресурсам из AppService с использованием System Managed Identity. Ссылка репо выглядит следующим образом - Azure_AppService_ManagedIdentity

...