Поделиться через

Проверка подлинности Spring Cloud Azure

  • Статья

Эта статья относится к:✅ версии 4.19.0 ✅ версии 5.19.0

В этой статье описаны все методы проверки подлинности Azure Spring Cloud.

DefaultAzureCredential

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

Заметка

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

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

схема, показывающая механизм проверки подлинности для DefaultAzureCredential.

  • Среда — DefaultAzureCredential будет считывать сведения об учетной записи, указанные с помощью переменных среды, и использовать ее для проверки подлинности.
  • Управляемое удостоверение. Если приложение развернуто на узле Azure с включенным управляемым удостоверением, DefaultAzureCredential будет проходить проверку подлинности с помощью этой учетной записи.
  • IntelliJ — если вы прошли проверку подлинности с помощью Набора средств Azure для IntelliJ, DefaultAzureCredential будет проходить проверку подлинности с помощью этой учетной записи.
  • Visual Studio Code. Если вы выполнили проверку подлинности с помощью подключаемого модуля учетной записи Azure Visual Studio Code, DefaultAzureCredential будет проходить проверку подлинности с помощью этой учетной записи.
  • Azure CLI. Если вы выполнили проверку подлинности учетной записи с помощью команды Azure CLI az login, DefaultAzureCredential будет проходить проверку подлинности с помощью этой учетной записи.

Кончик

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

Заметка

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

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

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

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

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

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

  • назначаемые системой. Некоторые службы Azure позволяют включить управляемое удостоверение непосредственно в экземпляре службы. При включении управляемого удостоверения, назначаемого системой, удостоверение создается в Microsoft Entra, привязанном к жизненному циклу этого экземпляра службы. Поэтому при удалении ресурса Azure автоматически удаляет удостоверение. С помощью этого удостоверения можно запросить маркеры из идентификатора Microsoft Entra.
  • назначаемые пользователем. Вы также можете создать управляемое удостоверение в качестве автономного ресурса 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 можно использовать управление доступом на основе ролей Azure (Azure RBAC) для предоставления разрешений субъекту безопасности, который может быть пользователем или субъектом-службой приложений. Если субъект безопасности (пользователь или приложение) пытается получить доступ к ресурсу Azure, например ресурсу Центров событий, запрос должен быть авторизован. С идентификатором Microsoft Entra доступ к ресурсу является двухэтапным процессом:

  1. Во-первых, удостоверение субъекта безопасности проходит проверку подлинности, а маркер OAuth 2.0 возвращается.
  2. Затем маркер передается в рамках запроса в службу Azure для авторизации доступа к указанному ресурсу.

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

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

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

Свойство Описание
идентификатор клиента Идентификатор клиента, используемый при выполнении проверки подлинности субъекта-службы с помощью Azure.
секрет клиента Секрет клиента, используемый при проверке подлинности субъекта-службы с помощью Azure.
путь к сертификату клиента Путь к файлу сертификата PEM для использования при выполнении проверки подлинности субъекта-службы с помощью Azure.
client-certificate-password Пароль файла сертификата.
имя пользователя Имя пользователя, используемое при выполнении проверки подлинности имени пользователя и пароля в Azure.
пароль Пароль, используемый при выполнении проверки подлинности имени пользователя или пароля в Azure.
с поддержкой управляемого удостоверения Следует ли включить управляемое удостоверение.

Кончик

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

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

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

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.

В следующем примере показано, как выполнить проверку подлинности с помощью субъекта-службы с помощью сертификата 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.

В следующем примере показано, как выполнить проверку подлинности с помощью субъекта-службы с сертификатом 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.

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

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.

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

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

Кончик

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

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

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

Заметка

При использовании Spring Cloud Azure Resource Manager для получения строк подключения для центров событий, служебной шины и очереди хранилища или свойств кэша для 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

Можно также настроить службы для проверки подлинности с помощью подписанного URL-адреса (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 для подключения к службе Центров событий.