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

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

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

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

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

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

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

DefaultAzureCredential

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка подлинности с помощью настраиваемого bean 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>

Проверка подлинности с помощью субъекта-службы с помощью сертификата клиента

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

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

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

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

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

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

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

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

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>

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

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

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

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