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 permitindo que os pods usem uma identidade Kubernetes (ou seja, uma conta de serviço). Um token Kubernetes é emitido e a federação OIDC permite que os aplicativos Kubernetes acessem 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 e a coleção da Biblioteca de Autenticação da Microsoft (MSAL) se você estiver usando o registro de 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 esse novo recurso de autenticação 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
Em vez de configurar todas as etapas manualmente, há outra implementação chamada Service Connector que irá 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ê só pode ter 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.
- A adição de nós virtuais, com base no projeto de código aberto Virtual Kubelet, não é suportada.
- 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 emissor de 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 em seu volume por um token do Microsoft Entra usando a biblioteca de cliente do Azure Identity ou a Biblioteca de Autenticação da Microsoft.
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 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 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 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, será necessário reiniciar o pod para que as alterações entrem em vigor.
Se você usou a identidade gerenciada por pod do Microsoft Entra, pense em uma conta de serviço como uma Identidade 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). A seguir descrevemos 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á 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 a identidade da carga de trabalho
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 implementou para a identidade gerenciada por pod hoje. Você só precisa anotar a conta de serviço dentro do namespace com a identidade, e isso permite que a identidade da carga de trabalho injete 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. Exemplos de recursos de implantação: - Implantar e configurar a identidade da carga de trabalho em um novo cluster - Tutorial: Usar uma identidade de carga de trabalho com um aplicativo no AKS |
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 o tutorial Usar uma identidade de carga de trabalho com um aplicativo no Serviço Kubernetes do Azure (AKS), 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.