Compartilhar via


Usar a ID de Carga de Trabalho do Microsoft Entra com o Serviço de Kubernetes do Azure (AKS)

As cargas de trabalho implantadas em um cluster dos Serviços de Kubernetes do Azure (AKS) exigem credenciais de aplicativo ou identidades gerenciadas do Microsoft Entra para acessar recursos protegidos do Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. A ID de Carga de Trabalho do Microsoft Entra integra-se aos recursos nativos do Kubernetes para federar com provedores de identidade externos.

A ID de Carga de Trabalho do Microsoft Entra usa Projeção de Volume de Token de Conta de Serviço (ou seja, uma conta de serviço) para permitir que os pods usem uma identidade do Kubernetes. Um token kubernetes é emitido e federação OIDC permite que aplicativos Kubernetes acessem recursos do Azure com segurança com o Microsoft Entra ID, com base em contas de serviço anotadas.

A ID de carga de trabalho do Microsoft Entra funciona especialmente bem com as Bibliotecas de clientes da Identidade do Azureou a coleção da Biblioteca de Autenticação da Microsoft (MSAL) junto com o registro de aplicativo. A carga de trabalho poderá usar qualquer uma dessas bibliotecas para autenticar e acessar facilmente os recursos de nuvem do Azure.

Este artigo ajuda você a entender a ID da Carga de Trabalho do Microsoft Entra e analisa as opções disponíveis para planejar sua estratégia de projeto e a possível migração da identidade gerenciada por pod do Microsoft Entra.

Observação

Você pode usar Service Connector para ajudá-lo a configurar algumas etapas automaticamente. Veja também: O que é o conector de serviço?

Dependências

  • O AKS dá suporte à ID de Carga de Trabalho do Microsoft Entra na versão 1.22 e superior.
  • A CLI do Azure, versão 2.47.0 ou posterior. Execute az --version para localizar a versão e az upgrade para atualizar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

bibliotecas de clientes do Azure Identity

Nas bibliotecas de clientes do Azure Identity, escolha uma das seguintes abordagens:

  • Use a DefaultAzureCredential, que tenta usar a WorkloadIdentityCredential.
  • Crie uma ChainedTokenCredential instância que inclua WorkloadIdentityCredential.
  • Usar o WorkloadIdentityCredential diretamente.

A tabela a seguir fornece a versão mínima do pacote necessária para a biblioteca de clientes de cada ecossistema de idioma.

Ecossistema Biblioteca Versão mínima
.NET Azure.Identity 1.9.0
C++ azure-identity-cpp 1.6.0
Go azidentity 1.3.0
Java azure-identity 1.9.0
Node.js @azure/identity 3.2.0
Python azure-identity 1.13.0

Nos exemplos de código a seguir, DefaultAzureCredential é usado. O tipo de credencial usa as variáveis de ambiente injetadas pelo webhook de mutação da Identidade de Carga de Trabalho do Azure para autenticar com o Azure Key Vault.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");

var client = new SecretClient(
    new Uri(keyVaultUrl),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync(secretName);

MSAL (Biblioteca de Autenticação da Microsoft)

As bibliotecas de cliente a seguir são a versão mínima necessária.

Ecossistema Biblioteca Image Exemplo Tem o Windows
.NET Biblioteca de Autenticação da Microsoft-para-dotnet ghcr.io/azure/azure-workload-identity/msal-net:latest Link Sim
Go Biblioteca de Autenticação da Microsoft-para-go ghcr.io/azure/azure-workload-identity/msal-go:latest Link Sim
Java Biblioteca de Autenticação da Microsoft-para-java ghcr.io/azure/azure-workload-identity/msal-java:latest Link Não
JavaScript Biblioteca de Autenticação da Microsoft-para-js ghcr.io/azure/azure-workload-identity/msal-node:latest Link Não
Python Biblioteca de Autenticação da Microsoft-para-python ghcr.io/azure/azure-workload-identity/msal-python:latest Link Não

Limitações

  • Você pode ter no máximo 20 credenciais de identidade federadas por identidade gerenciada.
  • Leva alguns segundos para que a credencial de identidade federada seja propagada após ser inicialmente adicionada.
  • Não há suporte para o complemento Nós virtuais, que é baseado no Kubelet Virtual do projeto de software livre.
  • A criação de credenciais de identidade federada não tem suporte em identidades gerenciadas atribuídas pelo usuário nessas regiões.

Como ele funciona

Nesse modelo de segurança, o cluster do AKS atua como o emissor do token. O Microsoft Entra ID usa o OpenID Connect para descobrir as chaves de assinatura públicas e verificar a autenticidade do token da conta de serviço antes de alterná-lo por um token do Microsoft Entra. Sua carga de trabalho pode trocar um token de conta de serviço projetado para seu volume para um token do Microsoft Entra usando a biblioteca de clientes da Identidade do Azure ou a MSAL (Biblioteca de Autenticação da Microsoft).

Diagrama do modelo de segurança de identidade de carga de trabalho do AKS.

A tabela a seguir descreve os pontos de extremidade do emissor OIDC necessários para a ID de carga de trabalho do Microsoft Entra:

Ponto de extremidade Descrição
{IssuerURL}/.well-known/openid-configuration Também conhecido como documento de descoberta de OIDC. Contém os metadados sobre as configurações do emissor.
{IssuerURL}/openid/v1/jwks Isso contém as chaves de assinatura pública que o Microsoft Entra ID usa para verificar a autenticidade do token da conta de serviço.

O diagrama a seguir resume a sequência de autenticação usando o OpenID Connect.

Diagrama da sequência de autenticação de OIDC da identidade de carga de trabalho do AKS.

Rotação automática de certificado webhook

Semelhante a outros complementos de webhook, o certificado é rotacionado pela operação de rotação automática do certificado de cluster.

Rótulos e anotações da conta de serviço

A ID de carga de trabalho do Microsoft Entra dá suporte aos seguintes mapeamentos relacionados a uma conta de serviço:

  • Um para um, em que uma conta de serviço faz referência a um objeto do Microsoft Entra.
  • Muitos para um, em que várias contas de serviço fazem referência ao mesmo objeto do Microsoft Entra.
  • Um para muitos, em que uma conta de serviço faz referência a vários objetos do Microsoft Entra alterando a anotação da ID do cliente. Para obter mais informações, confira Como federar várias identidades com uma conta de serviço do Kubernetes.

Observação

Se as anotações da conta de serviço forem atualizadas, você deverá reiniciar o pod para que as alterações entrem em vigor.

Se você tiver usado identidade gerenciada por pod do Microsoft Entra, pense em uma conta de serviço como uma entidade de segurança do Azure, exceto que uma conta de serviço faz parte da API central do Kubernetes, em vez de uma CRD (Custom Resource Definition ). As seções a seguir descrevem uma lista de rótulos e anotações disponíveis que podem ser usados para configurar o comportamento ao trocar o token de conta de serviço por um token de acesso do Microsoft Entra.

Anotações de conta de serviço

Todas as anotações são opcionais. Se a anotação não for especificada, o valor padrão será utilizado.

Anotação Descrição Padrão
azure.workload.identity/client-id Representa o aplicativo do Microsoft Entra
do Azure AD a ser usada com o pod.
azure.workload.identity/tenant-id Representa a ID do locatário do Azure em que o
O aplicativo do Microsoft Entra está registrado.
Variável de ambiente AZURE_TENANT_ID extraída
do ConfigMap azure-wi-webhook-config.
azure.workload.identity/service-account-token-expiration Representa o campo expirationSeconds para o
token de conta de serviço projetada. É um campo opcional que você configura para evitar qualquer tempo de inatividade
causado por erros durante a atualização do token de conta de serviço. A expiração do token de conta de serviço do Kubernetes não está correlacionada com tokens do Microsoft Entra. Os tokens do Microsoft Entra expiram em 24 horas após serem emitidos.
3600
O intervalo com suporte é de 3600 a 86400.

Rótulos do pod

Observação

Para aplicativos que usam a identidade da carga de trabalho, é necessário adicionar o rótulo azure.workload.identity/use: "true" à especificação do pod para que para que o AKS mova a identidade da carga de trabalho para um cenário de Fail Close para fornecer um comportamento consistente e confiável para pods que precisam usar a identidade da carga de trabalho. Caso contrário, os pods falharão após a reinicialização.

Rótulo Descrição Valor recomendado Obrigatório
azure.workload.identity/use Esse rótulo é necessário na especificação do modelo de pod. Somente os pods com esse rótulo são modificados pelo webhook de admissão de modificação azure-workload-identity para injetar as variáveis de ambiente específicas do Azure e o volume de token de conta de serviço projetado. true Sim

Anotações de pod

Todas as anotações são opcionais. Se a anotação não for especificada, o valor padrão será utilizado.

Anotação Descrição Padrão
azure.workload.identity/service-account-token-expiration Representa o campo expirationSeconds para o token de conta de serviço projetada. É um campo opcional que você configura para evitar tempos de inatividade causados por erros durante a atualização do token de conta de serviço. A expiração do token de conta de serviço do Kubernetes não está correlacionada com tokens do Microsoft Entra. Os tokens do Microsoft Entra expiram em 24 horas após serem emitidos. 1 3600
O intervalo com suporte é de 3600 a 86400.
azure.workload.identity/skip-containers Representa uma lista de contêineres separados por ponto e vírgula para ignorar a adição do volume de token de conta de serviço projetado. Por exemplo, container1;container2. Por padrão, o volume projetado do token de conta de serviço será adicionado a todos os contêineres se a conta de serviço estiver rotulada com azure.workload.identity/use: true.
azure.workload.identity/inject-proxy-sidecar Injeta um contêiner de inicialização de proxy e um sidecar de proxy no pod. O sidecar de proxy é usado para interceptar solicitações de token para IMDS e adquirir um token do Microsoft Entra em nome do usuário com credencial de identidade federada. true
azure.workload.identity/proxy-sidecar-port Representa a porta do sidecar de proxy. 8000

1 Terá precedência se a conta de serviço também for anotada.

Como migrar para a ID de Carga de Trabalho do Microsoft Entra

Em um cluster que já executa uma identidade gerenciada por pod, é possível configurá-lo para usar a identidade de carga de trabalho de duas maneiras. A primeira opção permite que você use a mesma configuração que você implementou para a identidade gerenciada por pod. Você pode anotar a conta de serviço no namespace com a identidade para habilitar a ID de Carga de Trabalho do Microsoft Entra e injetar as anotações nos pods.

A segunda opção é regravar o aplicativo para usar a versão mais recente da biblioteca de clientes do Azure Identity.

Para ajudar a simplificar e facilitar o processo de migração, desenvolvemos um sidecar de migração que converte as transações de IMDS que o aplicativo faz para OIDC (OpenID Connect). O sidecar de migração não é para ser usado como uma solução em longo prazo, mas uma maneira de começar a trabalhar rapidamente na identidade da carga de trabalho. A execução do arquivo secundário de migração no aplicativo faz proxy das transações de IMDS do aplicativo para o OIDC. A abordagem alternativa é atualizar para uma versão com suporte da biblioteca de clientes do Azure Identity, que dá suporte à autenticação de OIDC.

A tabela a seguir resume nossas recomendações de migração ou de implantação para identidade de carga de trabalho.

Cenário Descrição
A implantação de cluster nova ou existente executa uma versão com suporte da biblioteca de clientes do Azure Identity Nenhuma etapa de migração é necessária.
Recursos de implantação de exemplo: Implantar e configurar a identidade da carga de trabalho em um novo cluster
A implantação de cluster nova ou existente executa uma versão sem suporte da biblioteca de clientes do Azure Identity Atualize a imagem de contêiner para usar uma versão do SDK do Azure Identity com suporte ou use o sidecar de migração.

Próximas etapas