Compartilhar via

Autenticação do Spring Cloud Azure

  • Artigo

Este artigo se aplica a:✅ versão 4.19.0 ✅ versão 5.20.1

Este artigo descreve todos os métodos de autenticação do Spring Cloud Azure.

Autenticação e autorização com a ID do Microsoft Entra

Com a ID do Microsoft Entra, você pode usar o RBAC (controle de acesso baseado em função) do Azure para conceder permissões a uma entidade de segurança, que pode ser um usuário ou uma entidade de serviço de aplicativo. Quando uma entidade de segurança (um usuário ou um aplicativo) tenta acessar um recurso do Azure, por exemplo, um recurso dos Hubs de Eventos, a solicitação deve ser autorizada. Com a ID do Microsoft Entra, o acesso a um recurso é um processo de duas etapas:

  1. Primeiro, a identidade da entidade de segurança é autenticada e um token OAuth 2.0 é retornado.
  2. Em seguida, o token é passado como parte de uma solicitação para o serviço do Azure para autorizar o acesso ao recurso especificado.

Tipos de credencial

O Spring Cloud Azure permite que você configure diferentes tipos de credenciais para autenticação, incluindo DefaultAzureCredential, WorkloadIdentityCredential, ManagedIdentityCredential, ClientSecretCredential, AzureCliCredentiale assim por diante.

DefaultAzureCredential

DefaultAzureCredential é apropriado para a maioria dos cenários em que o aplicativo se destina a ser executado na Nuvem do Azure, pois combina as seguintes credenciais:

  • Credenciais comumente usadas para autenticar quando implantadas.
  • Credenciais usadas para autenticar em um ambiente de desenvolvimento.

Nota

DefaultAzureCredential destina-se a simplificar a introdução ao SDK do Azure manipulando cenários comuns com comportamentos padrão razoáveis. Se você quiser mais controle ou as configurações padrão não oferecerem suporte ao seu cenário, você deverá usar outros tipos de credencial.

DefaultAzureCredential tenta autenticar por meio dos seguintes mecanismos na ordem:

Diagrama mostrando o mecanismo de autenticação para 'DefaultAzureCredential'.

  • Ambiente – DefaultAzureCredential tenta ler as informações da conta especificadas por meio de variáveis de ambiente e usá-la para autenticar.
  • Identidade Gerenciada – se o aplicativo for implantado em um host do Azure com a Identidade Gerenciada habilitada, DefaultAzureCredential tentará se autenticar com essa conta.
  • Identidade da carga de trabalho – se o aplicativo for implantado em uma VM (máquinas virtuais), DefaultAzureCredential tentará se autenticar com essa conta.
  • Cache de Token Compartilhado – Se você autenticou por meio do Visual Studio, DefaultAzureCredential tenta se autenticar com essa conta.
  • IntelliJ – Se você autenticou por meio do Kit de Ferramentas do Azure para IntelliJ, DefaultAzureCredential tentará se autenticar com essa conta.
  • CLI do Azure – Se você autenticou uma conta por meio do comando az login da CLI do Azure, DefaultAzureCredential tentará se autenticar com essa conta.
  • Azure PowerShell – Se você autenticou por meio do Azure PowerShell, DefaultAzureCredential tenta autenticar com essa conta.
  • CLI do Desenvolvedor do Azure – Se você se autenticou por meio da CLI do Desenvolvedor do Azure, DefaultAzureCredential tenta se autenticar com essa conta.

Ponta

Verifique se a entidade de segurança tem permissão suficiente para acessar o recurso do Azure. Para obter mais informações, consulte Autorizar o acesso com o Microsoft Entra ID.

Nota

Desde o Spring Cloud Azure AutoConfigure 4.1.0, você deve registrar um ThreadPoolTaskExecutor bean chamado springCloudAzureCredentialTaskExecutor para gerenciar todos os threads criados pelo Azure Identity. O nome de cada thread gerenciado por esse pool de threads é prefixado com az-identity-. Este feijão ThreadPoolTaskExecutor é independente do feijão Executor fornecido pelo Spring Boot.

Identidades gerenciadas

Um desafio comum é o gerenciamento de segredos e credenciais usados para proteger a comunicação entre diferentes componentes que compõem uma solução. As identidades gerenciadas eliminam a necessidade de gerenciar credenciais. As identidades gerenciadas fornecem uma identidade para os aplicativos usarem ao se conectar a recursos que dão suporte à autenticação do Microsoft Entra. Os aplicativos podem usar a identidade gerenciada para obter tokens do Microsoft Entra. Por exemplo, um aplicativo pode usar uma identidade gerenciada para acessar recursos como o Azure Key Vault, onde você pode armazenar credenciais de maneira segura ou acessar contas de armazenamento.

Incentivamos o uso da identidade gerenciada em vez de usar a cadeia de conexão ou a chave em seu aplicativo porque ela é mais segura e salva o problema de gerenciar segredos e credenciais. Nesse caso, DefaultAzureCredential poderia atender melhor ao cenário de desenvolvimento local usando informações de conta armazenadas localmente e, em seguida, implantando o aplicativo na Nuvem do Azure e usando a identidade gerenciada.

Tipos de identidade gerenciada

Há dois tipos de identidades gerenciadas:

  • atribuídas pelo sistema – alguns serviços do Azure permitem habilitar uma identidade gerenciada diretamente em uma instância de serviço. Quando você habilita uma identidade gerenciada atribuída pelo sistema, uma identidade é criada no Microsoft Entra associada ao ciclo de vida dessa instância de serviço. Portanto, quando o recurso é excluído, o Azure exclui automaticamente a identidade para você. Por design, somente o recurso do Azure pode usar essa identidade para solicitar tokens da ID do Microsoft Entra.
  • atribuídas pelo usuário – você também pode criar uma identidade gerenciada como um recurso autônomo do Azure. Você pode criar uma identidade gerenciada atribuída pelo usuário e atribuí-la a uma ou mais instâncias de um serviço do Azure. Com identidades gerenciadas atribuídas pelo usuário, a identidade é gerenciada separadamente dos recursos que a usam.

Nota

Ao usar uma identidade gerenciada atribuída pelo usuário, você pode especificar a ID do cliente por meio de spring.cloud.azure.credential.client-id ou spring.cloud.azure.<azure-service>.credential.client-id. Você não precisará de configuração de credencial se usar uma identidade gerenciada atribuída pelo sistema.

Ponta

Para acessar o recurso do Azure, verifique se a entidade de segurança tem permissão suficiente. Para obter mais informações, consulte Autorizar o acesso com o Microsoft Entra ID.

Para obter mais informações sobre identidade gerenciada, consulte O que são identidades gerenciadas para recursos do Azure?.

Outros tipos de credencial

Se você quiser mais controle do que o fornecido pelo DefaultAzureCredentialou as configurações padrão não oferecerem suporte ao seu cenário, você deverá usar outros tipos de credencial.

Autenticar com a ID do Microsoft Entra

Para conectar aplicativos a recursos que dão suporte à autenticação do Microsoft Entra, você pode definir as configurações a seguir com o prefixo spring.cloud.azure.credential ou spring.cloud.azure.<azure-service>.credential

A tabela a seguir lista as propriedades de autenticação:

Propriedade Descrição
client-id A ID do cliente a ser usada ao executar a autenticação da entidade de serviço com o Azure.
segredo do cliente O segredo do cliente a ser usado ao executar a autenticação da entidade de serviço com o Azure.
client-certificate-path Caminho de um arquivo de certificado PEM a ser usado ao executar a autenticação da entidade de serviço com o Azure.
client-certificate-password A senha do arquivo de certificado.
nome de usuário O nome de usuário a ser usado ao executar a autenticação de nome de usuário/senha com o Azure.
senha A senha a ser usada ao executar a autenticação de nome de usuário/senha com o Azure.
habilitado para identidade gerenciada Se deseja habilitar a identidade gerenciada.
token-credential-bean-name O nome do bean do tipo TokenCredential a ser usado ao executar a autenticação com o Azure.

Ponta

Para obter a lista de todas as propriedades de configuração do Spring Cloud Azure, consulte propriedades de configuração do Spring Cloud Azure.

O aplicativo procura em vários locais para encontrar uma credencial disponível. Cada fábrica do construtor de clientes do SDK do Azure adota um bean personalizado do tipo TokenCredential primeiro se a propriedade token-credential-bean-name for especificada e voltar a usar DefaultAzureCredential se nenhuma propriedade de credencial estiver configurada.

Autenticar usando um bean TokenCredential personalizado

O exemplo a seguir mostra como definir um bean TokenCredential personalizado para fazer a autenticação:

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

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

Autenticar usando uma identidade gerenciada atribuída pelo sistema

O exemplo a seguir mostra como autenticar usando uma identidade gerenciada atribuída pelo sistema:

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

Autenticar usando uma identidade gerenciada atribuída pelo usuário

O exemplo a seguir mostra como autenticar usando uma identidade gerenciada atribuída pelo usuário:

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

Autenticar usando uma entidade de serviço com o segredo do cliente

O exemplo a seguir mostra como autenticar usando uma entidade de serviço com um segredo do cliente:

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

Nota

Os valores permitidos para tenant-id são: common, organizations, consumersou a ID do locatário. Para obter mais informações sobre esses valores, consulte a seção Usado o ponto de extremidade incorreto (contas pessoais e de organização) seção AADSTS50020 de Erro – A conta de usuário do provedor de identidade não existe node locatário. Para obter informações sobre como converter seu aplicativo de locatário único, consulte Converter aplicativo de locatário único em multilocatário no Microsoft Entra ID.

Autenticar usando uma entidade de serviço com certificado do cliente

O exemplo a seguir mostra como autenticar usando uma entidade de serviço com um certificado PFX do cliente:

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>

Nota

Os valores permitidos para tenant-id são: common, organizations, consumersou a ID do locatário. Para obter mais informações sobre esses valores, consulte a seção Usado o ponto de extremidade incorreto (contas pessoais e de organização) seção AADSTS50020 de Erro – A conta de usuário do provedor de identidade não existe node locatário. Para obter informações sobre como converter seu aplicativo de locatário único, consulte Converter aplicativo de locatário único em multilocatário no Microsoft Entra ID.

O exemplo a seguir mostra como autenticar usando uma entidade de serviço com o certificado PEM do cliente:

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

Nota

Os valores permitidos para tenant-id são: common, organizations, consumersou a ID do locatário. Para obter mais informações sobre esses valores, consulte a seção Usado o ponto de extremidade incorreto (contas pessoais e de organização) seção AADSTS50020 de Erro – A conta de usuário do provedor de identidade não existe node locatário. Para obter informações sobre como converter seu aplicativo de locatário único, consulte Converter aplicativo de locatário único em multilocatário no Microsoft Entra ID.

Autenticar usando uma credencial de usuário

O exemplo a seguir mostra como autenticar usando uma credencial de usuário:

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

Autenticar um serviço usando uma credencial diferente de outras pessoas

O exemplo a seguir mostra como autenticar com o Key Vault usando uma entidade de serviço diferente. Este exemplo configura o aplicativo com duas credenciais: uma identidade gerenciada atribuída pelo sistema e uma entidade de serviço. O cliente segredo do Key Vault usa a entidade de serviço, mas qualquer outro componente usa a identidade gerenciada.

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>

Nota

Os valores permitidos para tenant-id são: common, organizations, consumersou a ID do locatário. Para obter mais informações sobre esses valores, consulte a seção Usado o ponto de extremidade incorreto (contas pessoais e de organização) seção AADSTS50020 de Erro – A conta de usuário do provedor de identidade não existe node locatário. Para obter informações sobre como converter seu aplicativo de locatário único, consulte Converter aplicativo de locatário único em multilocatário no Microsoft Entra ID.

Autorizar o acesso com a ID do Microsoft Entra

A etapa de autorização exige que uma ou mais funções do Azure sejam atribuídas à entidade de segurança. As funções atribuídas a uma entidade de segurança determinam as permissões que a entidade de segurança tem.

Ponta

Para obter a lista de todas as funções internas do Azure, consulte funções internas do Azure.

A tabela a seguir lista as funções internas do Azure para autorizar o acesso aos serviços do Azure com suporte no Spring Cloud Azure:

Papel Descrição
proprietário de dados da configuração do aplicativo Permite o acesso completo aos dados da Configuração de Aplicativos.
leitor de dados de configuração de aplicativo Permite o acesso de leitura aos dados da Configuração de Aplicativos.
proprietário de dados dos Hubs de Eventos do Azure Permite acesso total aos recursos dos Hubs de Eventos do Azure.
do Receptor de Dados dos Hubs de Eventos do Azure Permite receber acesso aos recursos dos Hubs de Eventos do Azure.
remetente de dados dos Hubs de Eventos do Azure Permite o envio de acesso aos recursos dos Hubs de Eventos do Azure.
proprietário de dados do Barramento de Serviço do Azure Permite o acesso total aos recursos do Barramento de Serviço do Azure.
do Receptor de Dados do Barramento de Serviço do Azure Permite receber acesso aos recursos do Barramento de Serviço do Azure.
remetente de dados do Barramento de Serviço do Azure Permite enviar acesso aos recursos do Barramento de Serviço do Azure.
proprietário de dados de blob de armazenamento Fornece acesso total a contêineres e dados de blob do Armazenamento do Azure, incluindo a atribuição de controle de acesso POSIX.
de Leitor de Dados de Blobs de Armazenamento Ler e listar contêineres e blobs do Armazenamento do Azure.
leitor de dados da fila de armazenamento Ler e listar filas do Armazenamento do Azure e mensagens de fila.
do Colaborador do Cache Redis do Gerenciar caches Redis.

Nota

Ao usar o Spring Cloud Azure Resource Manager para obter as cadeias de conexão para Hubs de Eventos, Barramento de Serviço e Fila de Armazenamento ou as propriedades do Cache para Redis, atribua a função interna do Azure Contributor. O Cache do Azure para Redis é especial e você também pode atribuir a função Redis Cache Contributor para obter as propriedades redis.

Nota

Uma política de acesso do Key Vault determina se uma determinada entidade de segurança, ou seja, um usuário, aplicativo ou grupo de usuários, pode executar operações diferentes em segredos, chaves e certificados do Key Vault. Você pode atribuir políticas de acesso usando o portal do Azure, a CLI do Azure ou o Azure PowerShell. Para obter mais informações, consulte Atribuir uma política de acesso do Key Vault.

Importante

O Azure Cosmos DB expõe duas definições de função internas: Cosmos DB Built-in Data Reader e Cosmos DB Built-in Data Contributor. No entanto, o suporte do portal do Azure para gerenciamento de funções ainda não está disponível. Para obter mais informações sobre o modelo de permissão, definições de função e atribuição de função, consulte Configurar o controle de acesso baseado em função com a ID do Microsoft Entra para sua conta do Azure Cosmos DB.

Autenticar usando tokens SAS

Você também pode configurar serviços para autenticação com SAS (Assinatura de Acesso Compartilhado). spring.cloud.azure.<azure-service>.sas-token é a propriedade a ser configurada. Por exemplo, use spring.cloud.azure.storage.blob.sas-token para autenticar no serviço blob de armazenamento.

Autenticar usando cadeias de conexão

Alguns serviços do Azure dão suporte à cadeia de conexão para fornecer informações e credenciais de conexão. Para se conectar a esses serviços do Azure usando a cadeia de conexão, basta configurar spring.cloud.azure.<azure-service>.connection-string. Por exemplo, configure spring.cloud.azure.eventhubs.connection-string para se conectar ao serviço hubs de eventos.