Usar a ID de Carga de Trabalho do Microsoft Entra com o Serviço Kubernetes do Azure (AKS)
As cargas de trabalho implantadas em um cluster dos Serviços 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. O Microsoft Entra Workload ID integra-se com os recursos nativos do Kubernetes para federar com provedores de identidade externos.
O ID de Carga de Trabalho do Microsoft Entra usa a 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 a federação OIDC permite que os aplicativos Kubernetes acessem os recursos do Azure com segurança com a ID do Microsoft Entra, com base em contas de serviço anotadas.
A ID de Carga de Trabalho do Microsoft Entra funciona especialmente bem com as bibliotecas de cliente do Azure Identity ou a coleção Microsoft Authentication Library (MSAL), juntamente com o registro do aplicativo. Sua carga de trabalho pode usar qualquer uma dessas bibliotecas para autenticar e acessar perfeitamente os recursos de nuvem do Azure.
Este artigo ajuda você a entender a ID de carga de trabalho do Microsoft Entra e analisa as opções disponíveis para planejar sua estratégia de projeto e possível migração da identidade gerenciada por pod do Microsoft Entra.
Nota
Você pode usar o Service Connector para ajudá-lo a configurar algumas etapas automaticamente. Consulte também: O que é o Service Connector?
Dependências
- O AKS suporta o Microsoft Entra Workload ID 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 executeaz upgrade
para atualizar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).
Bibliotecas de cliente do Azure Identity
Nas bibliotecas de cliente do Azure Identity, escolha uma das seguintes abordagens:
- Use
DefaultAzureCredential
, que tenta usar oWorkloadIdentityCredential
. - Crie uma
ChainedTokenCredential
instância que incluaWorkloadIdentityCredential
o . - Use
WorkloadIdentityCredential
diretamente.
A tabela a seguir fornece a versão mínima do pacote necessária para a biblioteca de cliente de cada ecossistema de idiomas.
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/identidade | 3.2.0 |
Python | azure-identity | 1.13.0 |
Nos exemplos de código a seguir, DefaultAzureCredential
é usado. Esse tipo de credencial usa as variáveis de ambiente injetadas pelo webhook mutante do Azure Workload Identity 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);
Biblioteca de Autenticação da Microsoft (MSAL)
As seguintes bibliotecas de cliente são a versão mínima necessária.
Ecossistema | Biblioteca | Image | Exemplo | Tem Windows |
---|---|---|---|---|
.NET | Biblioteca de autenticação da Microsoft para dotnet | ghcr.io/azure/azure-workload-identity/msal-net:latest |
Ligação | Sim |
Go | Biblioteca de Autenticação da Microsoft para uso | ghcr.io/azure/azure-workload-identity/msal-go:latest |
Ligação | Sim |
Java | Biblioteca de autenticação da Microsoft para java | ghcr.io/azure/azure-workload-identity/msal-java:latest |
Ligação | Não |
JavaScript | Biblioteca de autenticação da Microsoft para js | ghcr.io/azure/azure-workload-identity/msal-node:latest |
Ligação | Não |
Python | Biblioteca de autenticação da Microsoft para python | ghcr.io/azure/azure-workload-identity/msal-python:latest |
Ligação | Não |
Limitações
- Você pode ter um máximo de 20 credenciais de identidade federada por identidade gerenciada.
- A propagação da credencial de identidade federada demora alguns segundos depois de ter sido inicialmente adicionada.
- Os nós virtuais adicionados, com base no projeto de código aberto Virtual Kubelet, não são suportados.
- A criação de credenciais de identidade federada não é suportada em identidades gerenciadas atribuídas pelo usuário nessas regiões.
Como funciona
Neste modelo de segurança, o cluster AKS atua como o emissor do token. O Microsoft Entra ID usa o OpenID Connect para descobrir chaves de assinatura públicas e verificar a autenticidade do token da conta de serviço antes de trocá-lo por um token do Microsoft Entra. Sua carga de trabalho pode trocar um token de conta de serviço projetado para seu volume por um token do Microsoft Entra usando a biblioteca de cliente do Azure Identity ou a Biblioteca de Autenticação da Microsoft (MSAL).
A tabela a seguir descreve os pontos de extremidade do emissor OIDC necessários para o ID de carga de trabalho do Microsoft Entra:
Ponto final | Description |
---|---|
{IssuerURL}/.well-known/openid-configuration |
Também conhecido como documento de descoberta OIDC. Ele contém os metadados sobre as configurações do emissor. |
{IssuerURL}/openid/v1/jwks |
Isso contém a(s) chave(s) de assinatura pública que o Microsoft Entra ID usa para verificar a autenticidade do token de conta de serviço. |
O diagrama a seguir resume a sequência de autenticação usando o OpenID Connect.
Rotação automática do certificado Webhook
Semelhante a outros addons webhook, o certificado é girado pela operação de rotação automática do certificado de cluster.
Etiquetas e anotações da conta de serviço
O Microsoft Entra Workload ID suporta os seguintes mapeamentos relacionados a uma conta de serviço:
- Um-para-um, onde uma conta de serviço faz referência a um objeto Microsoft Entra.
- Muitos-para-um, onde várias contas de serviço fazem referência ao mesmo objeto do Microsoft Entra.
- Um para muitos, onde uma conta de serviço faz referência a vários objetos do Microsoft Entra alterando a anotação de ID do cliente. Para obter mais informações, consulte Como federar várias identidades com uma conta de serviço do Kubernetes.
Nota
Se as anotações da conta de serviço forem atualizadas, reinicie o pod para que as alterações entrem em vigor.
Se você usou a identidade gerenciada pelo 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 principal do Kubernetes, em vez de uma CRD (Definição de Recursos Personalizados). 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 da 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á usado.
Anotação | Description | Predefinido |
---|---|---|
azure.workload.identity/client-id |
Representa o aplicativo Microsoft Entra ID do cliente a ser usado com o pod. |
|
azure.workload.identity/tenant-id |
Representa a ID do locatário do Azure onde o O aplicativo Microsoft Entra está registrado. |
AZURE_TENANT_ID variável de ambiente extraída do azure-wi-webhook-config ConfigMap. |
azure.workload.identity/service-account-token-expiration |
Representa o expirationSeconds campo para otoken de conta de serviço projetado. É um campo opcional que você configura para evitar tempo de inatividade Causados por erros durante a atualização do token da conta de serviço. A expiração do token da conta de serviço do Kubernetes não está correlacionada com os tokens do Microsoft Entra. Os tokens Microsoft Entra expiram em 24 horas após serem emitidos. |
3600 O intervalo suportado é 3600-86400. |
Rótulos de pod
Nota
Para aplicativos que usam identidade de carga de trabalho, é necessário adicionar o rótulo azure.workload.identity/use: "true"
à especificação do pod 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 falham depois de serem reiniciados.
Label | Description | Valor recomendado | Necessário |
---|---|---|---|
azure.workload.identity/use |
Este rótulo é necessário na especificação do modelo pod. Somente pods com esse rótulo são mutados pelo webhook azure-workload-identity mutating admission para injetar as variáveis de ambiente específicas do Azure e o volume de token de conta de serviço projetado. | verdadeiro | Sim |
Anotações do pod
Todas as anotações são opcionais. Se a anotação não for especificada, o valor padrão será usado.
Anotação | Description | Predefinido |
---|---|---|
azure.workload.identity/service-account-token-expiration |
Representa o expirationSeconds campo para o token de conta de serviço projetado. É um campo opcional que você configura para evitar qualquer tempo de inatividade causado por erros durante a atualização do token da conta de serviço. A expiração do token da conta de serviço do Kubernetes não está correlacionada com os tokens do Microsoft Entra. Os tokens Microsoft Entra expiram em 24 horas após serem emitidos. 1 |
3600 O intervalo suportado é 3600-86400. |
azure.workload.identity/skip-containers |
Representa uma lista separada por ponto-e-vírgula de contêineres para ignorar a adição do volume de token de conta de serviço projetado. Por exemplo, container1;container2 . |
Por padrão, o volume de token de conta de serviço projetado é 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 proxy é usado para intercetar solicitações de token para o IMDS e adquirir um token Microsoft Entra em nome do usuário com credencial de identidade federada. | verdadeiro |
azure.workload.identity/proxy-sidecar-port |
Representa a porta do sidecar proxy. | 8000 |
1 Tem precedência se a conta de serviço também estiver anotada.
Como migrar para o ID de carga de trabalho do Microsoft Entra
Em um cluster que já esteja executando uma identidade gerenciada por pod, você pode 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 dentro do namespace com a identidade para habilitar o ID de carga de trabalho do Microsoft Entra e injetar as anotações nos pods.
A segunda opção é reescrever seu aplicativo para usar a versão mais recente da biblioteca de cliente 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 IMDS que seu aplicativo faz para o OpenID Connect (OIDC). O sidecar de migração não pretende ser uma solução de longo prazo, mas uma maneira de começar a trabalhar rapidamente na identidade da carga de trabalho. A execução do sidecar de migração em seu aplicativo faz o proxy das transações IMDS do aplicativo para o OIDC. A abordagem alternativa é atualizar para uma versão com suporte da biblioteca de cliente do Azure Identity , que dá suporte à autenticação OIDC.
A tabela a seguir resume nossas recomendações de migração ou implantação para identidade de carga de trabalho.
Cenário | Description |
---|---|
A implantação de cluster nova ou existente executa uma versão com suporte da biblioteca de cliente 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 cliente do Azure Identity | Atualize a imagem do contêiner para usar uma versão com suporte do SDK do Azure Identity ou use o sidecar de migração. |
Próximos passos
- Para saber como configurar seu pod para autenticar usando uma identidade de carga de trabalho como uma opção de migração, consulte Modernizar a autenticação de aplicativos com identidade de carga de trabalho.
- Consulte Implantar e configurar um cluster AKS com identidade de carga de trabalho, que ajuda você a implantar um cluster do Serviço Kubernetes do Azure e configurar um aplicativo de exemplo para usar uma identidade de carga de trabalho.
Azure Kubernetes Service