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

Рекомендуемый подход к проверке подлинности Azure приложения для доступа к другим ресурсам Azure — использовать управляемое удостоверение. Большинство служб Azure поддерживают этот подход, включая приложения, размещенные на Azure App Service, Azure Container Apps и Azure Virtual Machines. Дополнительные сведения см. в разделе службы Azure и типы ресурсов, поддерживающие управляемые удостоверения. Дополнительные сведения о различных методах и подходах к проверке подлинности см. в разделе Аутентификация приложений Java в службах Azure с помощью библиотеки Azure Identity.

В следующих разделах вы узнаете:

• Основные понятия управляемой идентичности.
• Как создать управляемое удостоверение, назначенное системой, для вашего приложения.
• Назначение ролей управляемому удостоверению, назначенному системой.
• Как аутентифицироваться с помощью системного управляемого удостоверения из вашего кода приложения.

Основные понятия управляемой идентификации

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

Существуют два типа управляемых удостоверений, которые следует учитывать при настройке хостингового приложения:

• System-assigned удостоверения, управляемые системой, активируются непосредственно на ресурсе Azure и связаны с его жизненным циклом. Когда ресурс удаляется, Azure автоматически удаляет удостоверение для вас. Системные идентификаторы обеспечивают простой подход к использованию управляемых удостоверений.
• назначаемые пользователем управляемые удостоверения создаются как автономные ресурсы Azure и обеспечивают большую гибкость и возможности. Они идеально подходят для решений с несколькими Azure ресурсами, которые должны совместно использовать одинаковые удостоверения и разрешения. Например, если нескольким виртуальным машинам требуется доступ к одному набору ресурсов Azure, управляемое удостоверение, назначаемое пользователем, обеспечивает повторное использование и оптимизированное управление.

** В следующих разделах приводятся шаги по включению и использованию управляемого удостоверения, назначенного системой, для размещённого в Azure приложения. Если вам нужно использовать управляемое удостоверение, назначаемое пользователем, см. статью Аутентификация Java-приложений, размещенных в Azure, к ресурсам Azure с помощью управляемого удостоверения, назначаемого пользователем.

Включите системно назначаемое управляемое удостоверение на ресурсе размещения Azure

Чтобы начать использовать системно назначенное управляемое удостоверение с вашим приложением, включите удостоверение на Azure-ресурсе, который размещает ваше приложение, например, Azure App Service, Azure Container Apps или экземпляр Azure Virtual Machines.

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

az webapp identity assign \
    --resource-group <resource-group-name> \
    --name <web-app-name>

az containerapp identity assign \
    --resource-group <resource-group-name> \
    --name <container-app-name> \
    --system-assigned

az vm identity assign \
    --resource-group <resource-group-name> \
    --name <virtual-machine-name>

{
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

Назначьте роли управляемому удостоверению

Затем определите, какие роли нужны вашему приложению, и назначьте эти роли для управляемого удостоверения. Роли можно назначить управляемым идентичностям на следующих уровнях:

• Ресурс: назначенные роли применяются только к этому конкретному ресурсу.
• Группа ресурсов: назначенные роли применяются ко всем ресурсам, содержащимся в данной группе.
• Подписка: Назначенные роли применяются ко всем ресурсам, входящим в состав подписки.

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

az role assignment create \
    --assignee "{managedIdentityId}" \
    --role "{roleName}" \
    --scope "{scope}"

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

az role assignment create \
    --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/msdocs-sdk-auth-example"

Аутентификация для подключения к службам Azure из вашего приложения

Библиотека Azure Identity предоставляет различные учетные данные — реализации , адаптированные для поддержки различных сценариев и потоков аутентификации Microsoft Entra. Так как управляемое удостоверение недоступно при локальном выполнении, следующие шаги демонстрируют, какие учетные данные следует использовать в конкретном сценарии:

• Локальная среда разработки: Используйте класс DefaultAzureCredential только во время локальной разработки для предварительно настроенной цепочки учетных данных. DefaultAzureCredential обнаруживает учетные данные пользователя из локального инструмента или интегрированной среды разработки, например Azure CLI или Visual Studio Code. Она также обеспечивает гибкость и удобство повторных попыток, время ожидания ответов и поддержку нескольких вариантов проверки подлинности. Дополнительные сведения см. в статье Аутентификация в службах Azure во время локальной разработки.
• Приложения, размещенные в Azure: Когда ваше приложение работает в Azure, используйте ManagedIdentityCredential для безопасного обнаружения управляемой идентичности, настроенной для вашего приложения. Указание этого точного типа учетных данных предотвращает неожиданное получение других доступных учетных данных.

Реализация кода

Добавьте зависимость azure-identity в ваш pom.xml файл:

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-identity</artifactId>
</dependency>

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

1. Импортируйте DefaultAzureCredentialBuilder, ManagedIdentityCredentialBuilder и TokenCredential классы.
2. Передайте клиенту соответствующий TokenCredential объект:
   • Использование DefaultAzureCredential при локальном запуске
   • Используйте ManagedIdentityCredential, когда ваше приложение работает в Azure

В следующем примере демонстрируется проверка подлинности SecretClient с помощью управляемого удостоверения, назначаемого системой:

import com.azure.core.credential.TokenCredential;
import com.azure.identity.DefaultAzureCredentialBuilder;
import com.azure.identity.ManagedIdentityCredentialBuilder;
import com.azure.security.keyvault.secrets.SecretClient;
import com.azure.security.keyvault.secrets.SecretClientBuilder;

TokenCredential credential = null;

// Set up credential based on environment (Azure or local development)
String environment = System.getenv("ENV");

if (environment != null && environment.equals("production")) {
    credential = new ManagedIdentityCredentialBuilder()
        .build();
} else {
    credential = new DefaultAzureCredentialBuilder()
        .build();
}

// Azure SDK client builders accept the credential as a parameter
SecretClient client = new SecretClientBuilder()
    .vaultUrl("https://<your-key-vault-name>.vault.azure.net")
    .credential(credential)
    .buildClient();

Дальнейшие действия

В этой статье рассматривается проверка подлинности с помощью управляемого удостоверения, назначаемого системой. Эта форма проверки подлинности является одним из нескольких способов проверки подлинности в Azure SDK для Java. В следующих статьях описаны другие способы.

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

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