Аутентификация Spring Cloud Azure

В этой статье описаны методы проверки подлинности Spring Cloud Azure и вы можете выбрать правильный тип учетных данных для защиты доступа к ресурсам Azure.

Проверка подлинности и авторизация с помощью идентификатора Microsoft Entra

Используя Microsoft Entra ID, вы можете использовать управление доступом на основе ролей Azure (Azure RBAC) для назначения разрешений субъекту безопасности, который может быть пользователем или субъектом-службой приложения. Если субъект безопасности (пользователь или приложение) пытается получить доступ к ресурсу Azure, например ресурсу Центров событий, запрос должен быть авторизован. С помощью Microsoft Entra ID доступ к ресурсу — это двухэтапный процесс:

1. Сначала выполните проверку подлинности удостоверения субъекта безопасности и верните маркер OAuth 2.0.
2. Затем передайте маркер в рамках запроса в службу Azure, чтобы авторизовать доступ к указанному ресурсу.

Типы учетных данных

Spring Cloud Azure позволяет настроить различные типы учетных данных для проверки подлинности, включая DefaultAzureCredential, , WorkloadIdentityCredential, ManagedIdentityCredentialClientSecretCredentialAzureCliCredentialи многое другое.

DefaultAzureCredential (учетные данные Azure по умолчанию)

DefaultAzureCredential подходит для большинства сценариев, в которых приложение предназначено для запуска в облаке Azure, так как оно объединяет следующие учетные данные:

• Учетные данные, часто используемые для проверки подлинности при развертывании.
• Учетные данные, используемые для проверки подлинности в среде разработки.

Заметка

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

DefaultAzureCredential пытается пройти проверку подлинности с помощью следующих механизмов:

• Среда — DefaultAzureCredential пытается считывать сведения об учетной записи, указанные с помощью переменных среды, и использовать ее для проверки подлинности.
• Управляемое удостоверение. Если приложение развернуто на узле Azure с включенным управляемым удостоверением, DefaultAzureCredential пытается выполнить проверку подлинности с помощью этой учетной записи.
• Идентификация рабочей нагрузки — если приложение развернуто на виртуальной машине (VM), DefaultAzureCredential пытается пройти аутентификацию с помощью этой учетной записи.
• Общий кэш токенов — если вы выполнили вход через Visual Studio, DefaultAzureCredential пытается выполнить аутентификацию с использованием этой учетной записи.
• IntelliJ — если вы прошли проверку подлинности с помощью набора средств Azure для IntelliJ, DefaultAzureCredential пытается выполнить проверку подлинности с помощью этой учетной записи.
• Azure CLI. Если вы прошли проверку подлинности учетной записи с помощью команды Azure CLIaz login, DefaultAzureCredential пытается выполнить проверку подлинности с помощью этой учетной записи.
• Azure PowerShell . Если вы прошли проверку подлинности через Azure PowerShell, DefaultAzureCredential пытается пройти проверку подлинности с помощью этой учетной записи.
• Azure Developer CLI — если вы авторизовались через Azure Developer CLI, DefaultAzureCredential пытается пройти аутентификацию с помощью этой учетной записи.

Совет

Убедитесь, что субъект безопасности имеет достаточно разрешений для доступа к ресурсу Azure. Дополнительные сведения см. в разделе Авторизация доступа с помощьюидентификатора Microsoft Entra.

Заметка

Начиная с Spring Cloud Azure AutoConfigure 4.1.0, необходимо зарегистрировать бин ThreadPoolTaskExecutor с именем springCloudAzureCredentialTaskExecutor для управления всеми потоками, созданными Azure Identity. Имя каждого потока, управляемого этим пулом потоков, префиксируется az-identity-. Этот ThreadPoolTaskExecutor бин не зависит от Executor бина, который предоставляет Spring Boot.

Управляемые удостоверения

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

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

Типы управляемых удостоверений

Существует два типа управляемых удостоверений личности:

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

Заметка

При использовании управляемого удостоверения, назначаемого пользователем, укажите идентификатор клиента с помощью spring.cloud.azure.credential.client-id или spring.cloud.azure.<azure-service>.credential.client-id. Вам не нужна конфигурация учетных данных, если вы используете управляемое удостоверение, назначаемое системой.

Совет

Чтобы получить доступ к ресурсу Azure, убедитесь, что субъект безопасности имеет достаточно разрешений. Дополнительные сведения см. в разделе Авторизация доступа с помощьюидентификатора Microsoft Entra.

Дополнительные сведения об управляемом удостоверении см. в статье Что такое управляемые удостоверения для ресурсов Azure?.

Другие типы учетных данных

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

Проверка подлинности с помощью идентификатора Microsoft Entra

Чтобы подключить приложения к ресурсам, поддерживающим проверку подлинности Microsoft Entra, задайте следующие конфигурации с префиксом spring.cloud.azure.credential илиspring.cloud.azure.<azure-service>.credential.

В следующей таблице перечислены свойства проверки подлинности:

Свойство	Описание
client-id	Идентификатор клиента, используемый при выполнении проверки подлинности субъекта-службы с помощью Azure.
client-secret	Секрет клиента, используемый при проверке подлинности субъекта-службы с помощью Azure.
client-certificate-path	Путь к файлу сертификата PEM для использования при выполнении проверки подлинности субъекта-службы с помощью Azure.
client-certificate-password	Пароль файла сертификата.
username	Имя пользователя, используемое при выполнении проверки подлинности имени пользователя и пароля в Azure.
password	Пароль, используемый при выполнении проверки подлинности имени пользователя или пароля в Azure.
managed-identity-enabled	Следует ли включать управляемую идентификацию.
token-credential-bean-name	Имя бина типа TokenCredential, которое используется при аутентификации через Azure.

Совет

Список всех свойств конфигурации Azure Spring Cloud см. в разделе свойства конфигурации Spring Cloud Azure.

Приложение ищет доступные учетные данные в нескольких местах. Каждая фабрика построителей клиентов Azure SDK в первую очередь использует пользовательский бин типа TokenCredential, если указано свойство token-credential-bean-name, а если свойства учетных данных не настроены, использует DefaultAzureCredential.

Аутентификация с использованием настраиваемого компонента TokenCredential

В следующем примере показано, как определить настраиваемую TokenCredential bean для проверки подлинности:

@Bean
TokenCredential myTokenCredential() {
    // Your concrete TokenCredential instance
}

spring.cloud.azure:
  credential:
    token-credential-bean-name: myTokenCredential

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

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

spring.cloud.azure:
  credential:
    managed-identity-enabled: true

Аутентификация с использованием управляемой идентификации, назначенной пользователем

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

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
    client-id: ${AZURE_CLIENT_ID}

Аутентификация с использованием субъекта-службы и секрета клиента

В следующем примере показано, как пройти проверку подлинности с помощью субъекта-службы с секретом клиента:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-secret: ${AZURE_CLIENT_SECRET}
  profile:
    tenant-id: <tenant>

Заметка

Значения, допустимые для tenant-id: common, organizations, consumersили идентификатор клиента. Дополнительные сведения об этих значениях см. в разделе Использовалась неправильная конечная точка (личные и организационные учетные записи) в статье Ошибка AADSTS50020 — учетная запись пользователя от поставщика удостоверений не существует в клиенте. Сведения о преобразовании однотенантного приложения см. в статье Преобразование однотенантного приложения в мультитенантное в Microsoft Entra ID.

Аутентификация с использованием субъекта-службы и сертификата клиента

В следующем примере показано, как пройти проверку подлинности с помощью субъекта-службы с сертификатом PFX клиента:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
    client-certificate-password: ${AZURE_CLIENT_CERTIFICATE_PASSWORD}
  profile:
    tenant-id: <tenant>

Заметка

Значения, допустимые для tenant-id: common, organizations, consumersили идентификатор клиента. Дополнительные сведения об этих значениях см. в разделе Использована неправильная конечная точка (личные и рабочие учетные записи) статьи Ошибка AADSTS50020. Учетная запись пользователя от поставщика удостоверений не существует в арендаторе. Сведения о преобразовании однотенантного приложения см. в статье Преобразование однотенантного приложения в мультитенантное в Microsoft Entra ID.

В следующем примере показано, как выполнить аутентификацию с помощью субъекта-службы, используя клиентский сертификат PEM:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
  profile:
    tenant-id: <tenant>

Заметка

Значения, допустимые для tenant-id: common, organizations, consumersили идентификатор клиента. Дополнительные сведения об этих значениях см. в разделе Использована неправильная конечная точка (личные и организационные учетные записи) статьи Ошибка AADSTS50020 — учетная запись пользователя от поставщика удостоверений не существует в клиенте. Сведения о преобразовании однотенантного приложения см. в статье Преобразование однотенантного приложения в мультитенантное в Microsoft Entra ID.

Проверка подлинности с помощью учетных данных пользователя

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

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    username: ${AZURE_USER_USERNAME}
    password: ${AZURE_USER_PASSWORD}

Проверить подлинность службы, используя учетные данные, отличные от используемых другими

В следующем примере показано, как пройти аутентификацию в Key Vault с помощью другого сервисного субъекта. В этом примере приложение настраивается с использованием двух учетных данных: одной управляемой идентичности, назначаемой системой, и одного сервисного субъекта. Клиент для работы с секретами Key Vault использует субъект-службу, а все остальные компоненты — управляемую идентификацию.

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
  keyvault.secret:
    credential:
      client-id: ${AZURE_CLIENT_ID}
      client-secret: ${AZURE_CLIENT_SECRET}
    profile:
      tenant-id: <tenant>

Заметка

Значения, допустимые для tenant-id: common, organizations, consumersили идентификатор клиента. Дополнительные сведения об этих значениях см. в разделе Использована неправильная конечная точка (личные и организационные учетные записи) статьи Ошибка AADSTS50020 — учетная запись пользователя от поставщика удостоверений не существует в клиенте. Сведения о преобразовании однотенантного приложения см. в статье Преобразование однотенантного приложения в мультитенантное в Microsoft Entra ID.

Авторизация доступа с помощью идентификатора Microsoft Entra

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

Совет

Список всех встроенных ролей Azure см. в Azure built-in roles.

В следующей таблице перечислены встроенные роли Azure для авторизации доступа к службам Azure, поддерживаемым в Spring Cloud Azure:

Роль	Описание
Владелец данных конфигурации приложения	Обеспечивает полный доступ к данным конфигурации приложений.
Средство чтения данных конфигурации приложения	Разрешает доступ на чтение к данным конфигурации приложений.
Владелец данных Центров событий Azure	Предоставляет полный доступ к ресурсам Центров событий Azure.
приемника данных Центров событий Azure	Позволяет получать доступ к ресурсам Центров событий Azure.
отправитель данных Центров событий Azure	Позволяет отправлять доступ к ресурсам Центров событий Azure.
Владелец данных Служебная шина Azure	Обеспечивает полный доступ к ресурсам служебной шины Azure.
приемник данных служебной шины Azure	Разрешает доступ к ресурсам служебной шины Azure.
отправитель данных служебной шины Azure	Разрешает отправлять доступ к ресурсам служебной шины Azure.
Владелец данных больших двоичных объектов хранилища	Предоставляет полный доступ к контейнерам BLOB-объектов и данным в Хранилище Azure, включая назначение элементов управления доступом POSIX.
Читатель данных больших двоичных объектов хранилища	Читайте и выводите список контейнеров и BLOB-объектов служба хранилища Azure.
Средство чтения данных очереди хранилища	Читать и перечислять очереди хранилища Azure и сообщения в очередях.
Контрибьютор Redis Cache	Управление кэшами Redis.

Заметка

Если вы используете Spring Cloud Azure Resource Manager для получения строк подключения к Центрам событий, служебная шина и очередям хранилища либо свойств Cache for Redis, назначьте встроенную роль Azure Contributor. Кэш Azure для Redis является специальным, и вы также можете назначить роль Redis Cache Contributor, чтобы получить свойства Redis.

Заметка

Политика доступа Key Vault определяет, может ли данный субъект безопасности, а именно пользователь, приложение или группа пользователей выполнять различные операции с Key Vault секретами, ключами и сертификатами. Политики доступа можно назначить с помощью портала Azure, Azure CLI или Azure PowerShell. Дополнительные сведения см. в статье Назначение политики доступа Key Vault.

Важно

Azure Cosmos DB предоставляет два встроенных определения ролей: Cosmos DB Built-in Data Reader и Cosmos DB Built-in Data Contributor. Однако поддержка портала Azure для управления ролями пока недоступна. Дополнительные сведения о модели разрешений, определениях ролей и назначении ролей см. в статье Настройка управления доступом на основе ролей с помощью идентификатора Microsoft Entra для учетной записи Azure Cosmos DB.

Проверка подлинности с помощью маркеров SAS

Службы также можно настраивать для аутентификации с помощью подписи общего доступа (SAS). Используйте свойство spring.cloud.azure.<azure-service>.sas-token для настройки этой аутентификации. Например, используйте spring.cloud.azure.storage.blob.sas-token для аутентификации в службе хранилища BLOB-объектов.

Выполните аутентификацию с помощью строк подключения

Некоторые службы Azure поддерживают строки подключения для предоставления сведений о подключении и учетных данных. Чтобы подключиться к этим службам Azure с помощью строк подключения, настройте spring.cloud.azure.<azure-service>.connection-string. Например, настройте spring.cloud.azure.eventhubs.connection-string для подключения к службе Центров событий.