Federação de identidades de carga de trabalho

  • Artigo

Este artigo fornece uma visão geral da federação de identidade de carga de trabalho para cargas de trabalho de software. O uso da federação de identidades de carga de trabalho permite que você acesse recursos protegidos do Microsoft Entra sem a necessidade de gerenciar segredos (para cenários suportados).

Você pode usar a federação de identidades de carga de trabalho em cenários como Ações do GitHub, cargas de trabalho em execução no Kubernetes ou cargas de trabalho em execução em plataformas de computação fora do Azure.

Por que usar a federação de identidades de carga de trabalho?

Assista a este vídeo para saber por que você usaria a federação de identidades de carga de trabalho.

Normalmente, uma carga de trabalho de software (como um aplicativo, serviço, script ou aplicativo baseado em contêiner) precisa de uma identidade para autenticar e acessar recursos ou se comunicar com outros serviços. Quando essas cargas de trabalho são executadas no Azure, você pode usar identidades gerenciadas e a plataforma Azure gerencia as credenciais para você. No entanto, você só pode usar identidades gerenciadas para cargas de trabalho de software em execução no Azure. Para uma carga de trabalho de software executada fora do Azure, você precisa usar credenciais de aplicativo (um segredo ou certificado) para acessar recursos protegidos do Microsoft Entra (como Azure, Microsoft Graph, Microsoft 365 ou recursos de terceiros). Estas credenciais representam um risco de segurança e têm de ser armazenadas de forma segura e alternadas regularmente. Você também corre o risco de tempo de inatividade do serviço se as credenciais expirarem.

Você usa a federação de identidades de carga de trabalho para configurar uma identidade gerenciada atribuída pelo usuário ou um registro de aplicativo no Microsoft Entra ID para confiar em tokens de um provedor de identidade externo (IdP), como o GitHub ou o Google. A identidade gerenciada atribuída pelo usuário ou o registro do aplicativo no Microsoft Entra ID se torna uma identidade para cargas de trabalho de software em execução, por exemplo, em fluxos de trabalho locais do Kubernetes ou do GitHub Actions. Depois que essa relação de confiança é criada, sua carga de trabalho de software externo troca tokens confiáveis do IdP externo por tokens de acesso da plataforma de identidade da Microsoft. Sua carga de trabalho de software usa esse token de acesso para acessar os recursos protegidos do Microsoft Entra aos quais a carga de trabalho recebeu acesso. Você elimina a carga de manutenção do gerenciamento manual de credenciais e elimina o risco de vazar segredos ou ter certificados expirando.

Cenários suportados

Os seguintes cenários são suportados para acessar recursos protegidos do Microsoft Entra usando a federação de identidade de carga de trabalho:

  • Cargas de trabalho em execução em qualquer cluster Kubernetes (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE) ou local). Estabeleça uma relação de confiança entre sua identidade gerenciada atribuída pelo usuário ou aplicativo no Microsoft Entra ID e uma carga de trabalho do Kubernetes (descrita na visão geral da identidade da carga de trabalho).
  • Ações do GitHub. Primeiro, configure uma relação de confiança entre sua identidade gerenciada atribuída pelo usuário ou aplicativo no Microsoft Entra ID e um repositório GitHub no centro de administração do Microsoft Entra ou usando o Microsoft Graph. Em seguida, configure um fluxo de trabalho de Ações do GitHub para obter um token de acesso do provedor de identidade da Microsoft e acessar os recursos do Azure.
  • Google Cloud. Primeiro, configure uma relação de confiança entre sua identidade gerenciada atribuída pelo usuário ou aplicativo no Microsoft Entra ID e uma identidade no Google Cloud. Em seguida, configure sua carga de trabalho de software em execução no Google Cloud para obter um token de acesso do provedor de identidade da Microsoft e acessar os recursos protegidos do Microsoft Entra. Consulte Aceder a recursos protegidos do Microsoft Entra a partir de uma aplicação no Google Cloud.
  • Cargas de trabalho em execução na Amazon Web Services (AWS). Primeiro, configure uma relação de confiança entre sua identidade gerenciada atribuída pelo usuário ou aplicativo no Microsoft Entra ID e uma identidade no Amazon Cognito. Em seguida, configure sua carga de trabalho de software em execução na AWS para obter um token de acesso do provedor de identidade da Microsoft e acessar os recursos protegidos do Microsoft Entra. Consulte Federação de identidades de carga de trabalho com a AWS.
  • Outras cargas de trabalho em execução em plataformas de computação fora do Azure. Configure uma relação de confiança entre sua identidade gerenciada atribuída pelo usuário ou aplicativo no Microsoft Entra ID e o IdP externo para sua plataforma de computação. Você pode usar tokens emitidos por essa plataforma para autenticar com a plataforma de identidade da Microsoft e chamar APIs no ecossistema da Microsoft. Use o fluxo de credenciais do cliente para obter um token de acesso da plataforma de identidade da Microsoft, passando o JWT do provedor de identidade em vez de criar um usando um certificado armazenado.
  • SPIFFE e SPIRE são um conjunto de padrões de código aberto agnósticos de plataforma para fornecer identidades para suas cargas de trabalho de software implantadas em plataformas e fornecedores de nuvem. Primeiro, configure uma relação de confiança entre sua identidade gerenciada atribuída pelo usuário ou aplicativo no Microsoft Entra ID e uma ID SPIFFE para uma carga de trabalho externa. Em seguida, configure sua carga de trabalho de software externo para obter um token de acesso do provedor de identidade da Microsoft e acessar os recursos protegidos do Microsoft Entra. Consulte Federação de identidade de carga de trabalho com SPIFFE e SPIRE.
  • Crie uma nova conexão de serviço no Azure Pipelines (visualização). Crie uma conexão de serviço do Azure Resource Manager usando a federação de identidades de carga de trabalho.

Nota

Os tokens emitidos pelo Microsoft Entra ID não podem ser usados para fluxos de identidade federada. O fluxo de credenciais de identidade federada não oferece suporte a tokens emitidos pelo Microsoft Entra ID.

Como funciona

Crie uma relação de confiança entre o IdP externo e uma identidadeou aplicativo gerenciado atribuído pelo usuário no Microsoft Entra ID. A credencial de identidade federada é usada para indicar qual token do IdP externo deve ser confiável pelo seu aplicativo ou identidade gerenciada. Você configura uma identidade federada:

  • Em uma identidade gerenciada atribuída pelo usuário por meio do centro de administração do Microsoft Entra, modelos Azure CLI, Azure PowerShell, SDK do Azure e Azure Resource Manager (ARM). A carga de trabalho externa usa o token de acesso para acessar recursos protegidos do Microsoft Entra sem a necessidade de gerenciar segredos (em cenários com suporte). As etapas para configurar a relação de confiança são diferentes, dependendo do cenário e do IdP externo.
  • Em um registro de aplicativo no centro de administração do Microsoft Entra ou por meio do Microsoft Graph. Essa configuração permite que você obtenha um token de acesso para seu aplicativo sem precisar gerenciar segredos fora do Azure. Para obter mais informações, saiba como configurar um aplicativo para confiar em um provedor de identidade externo.

No entanto, o fluxo de trabalho para trocar um token externo por um token de acesso é o mesmo para todos os cenários. O diagrama a seguir mostra o fluxo de trabalho geral de uma carga de trabalho, trocando um token externo por um token de acesso e, em seguida, acessando recursos protegidos do Microsoft Entra.

Diagrama mostrando um token externo trocado por um token de acesso e acessando o Azure

  1. A carga de trabalho externa (como um fluxo de trabalho de Ações do GitHub) solicita um token do IdP externo (como o GitHub).
  2. O IdP externo emite um token para a carga de trabalho externa.
  3. A carga de trabalho externa (a ação de entrada em um fluxo de trabalho do GitHub, por exemplo) envia o token para a plataforma de identidade da Microsoft e solicita um token de acesso.
  4. A plataforma de identidade da Microsoft verifica a relação de confiança na identidade gerenciada atribuída pelo usuário ou no registro do aplicativo e valida o token externo em relação à URL do emissor do OpenID Connect (OIDC) no IdP externo.
  5. Quando as verificações são satisfeitas, a plataforma de identidade da Microsoft emite um token de acesso para a carga de trabalho externa.
  6. A carga de trabalho externa acessa recursos protegidos do Microsoft Entra usando o token de acesso da plataforma de identidade da Microsoft. Um fluxo de trabalho de Ações do GitHub, por exemplo, usa o token de acesso para publicar um aplicativo Web no Serviço de Aplicativo do Azure.

A plataforma de identidade da Microsoft armazena apenas as primeiras 100 chaves de assinatura quando elas são baixadas do ponto de extremidade OIDC do IdP externo. Se o IdP externo expor mais de 100 chaves de assinatura, você poderá enfrentar erros ao usar a federação de identidades de carga de trabalho.

Próximos passos

Saiba mais sobre como funciona a federação de identidades de carga de trabalho:

  • Como criar, excluir, obter ou atualizar credenciais de identidade federada em uma identidade gerenciada atribuída pelo usuário.
  • Como criar, excluir, obter ou atualizar credenciais de identidade federada em um registro de aplicativo.
  • Leia a visão geral da identidade da carga de trabalho para saber como configurar uma carga de trabalho do Kubernetes para obter um token de acesso do provedor de identidade da Microsoft e acessar os recursos protegidos do Microsoft Entra.
  • Leia a documentação de Ações do GitHub para saber mais sobre como configurar seu fluxo de trabalho de Ações do GitHub para obter um token de acesso do provedor de identidade da Microsoft e acessar os recursos protegidos do Microsoft Entra.
  • Como o Microsoft Entra ID usa a concessão de credenciais de cliente OAuth 2.0 e uma asserção de cliente emitida por outro IdP para obter um token.
  • Para obter informações sobre o formato necessário de JWTs criados por provedores de identidade externos, leia sobre o formato de asserção.