Associações de identidade para o AKS (Serviço de Kubernetes do Azure) (versão prévia)

A associação de identidade é um recurso de pré-visualização do Serviço de Kubernetes do Azure (AKS) que estende o recurso de identidade de carga de trabalho existente para resolver as limitações de escala relacionadas às credenciais de identidade federadas (FICs) em identidades gerenciadas atribuídas pelo usuário (UAMIs). Com a identidade da carga de trabalho do AKS, uma única interface do usuário não deve ter mais de 20 FICs. Implantações de plataforma Kubernetes grandes podem abranger mais de 20 clusters (cada cluster tem um emissor exclusivo) ou ter muitas <namespace, service-account> combinações que precisam ser mapeadas para a mesma UAMI, esgotando a cota de FIC.

As associações de identidade resolvem essa limitação permitindo que vários clusters do AKS compartilhem o mesmo UAMI usando um único FIC por UAMI. Essa abordagem aumenta significativamente a escalabilidade e simplifica as operações para ambientes AKS em larga escala que exigem a autenticação do Microsoft Entra.

O que é uma associação de identidade?

Uma associação de identidade é um mapeamento de recursos entre um UAMI e um cluster do AKS com cargas de trabalho que precisam da autenticação do Microsoft Entra com essa identidade.

Digamos que você tenha uma UAMI, MI-1, necessária para cargas de trabalho em execução nos clusters AKS-cluster-1, AKS-cluster-2 e AKS-cluster-3. Você pode criar três associações de identidade para mapear MI-1 para cada um desses clusters:

• Vinculação de identidade IB-A mapeando MI-1 para AKS-cluster-1.
• Vinculação de identidade IB-B mapeando MI-1 para AKS-cluster-2.
• Vinculação de identidade IB-C mapeando MI-1 para AKS-cluster-3.

Mesmo que a mesma UAMI seja necessária em vários clusters, apenas uma credencial de identidade federada é criada por UAMI, resolvendo a limitação anterior de 20 FICs. Quando uma associação de identidade é criada, o AKS cria automaticamente (ou reutiliza) o único FIC para esse UAMI. Os diagramas a seguir ilustram as diferenças entre o modelo de identidade da carga de trabalho anterior e o novo modelo de associações de identidade:

Depois de criar a associação de identidade e o UAMI estiver autorizado para o cluster, você deverá definir os objetos ClusterRole e ClusterRoleBinding que especifiquem os namespaces e contas de serviço (granularmente ou coletivamente) permitidos para usar essa identidade gerenciada para aquisição de token do Microsoft Entra.

Usar associações de identidade com bibliotecas de cliente do Azure Identity

Para usar associações de identidade com suas cargas de trabalho de aplicativo, siga estas etapas:

1. Verifique se você está usando o pacote mínimo necessário do Azure Identity.
2. Use WorkloadIdentityCredential e opte pelo recurso. Esse recurso não tem suporte em ManagedIdentityCredential ou DefaultAzureCredential.

A tabela a seguir descreve as versões mínimas do pacote e como habilitar associações de identidade para cada idioma com suporte:

Perguntas frequentes (FAQs)

É necessária a igualdade de identidade (igualdade de namespace e conta de serviço) entre clusters usando a mesma UAMI (Identidade Gerenciada Atribuída pelo Usuário)?

Não. As associações de identidade não requerem a igualdade de contas de namespace e de serviço. Cabe ao operador de cluster autorizar explicitamente os namespaces e contas de serviço dentro de cada cluster que têm permissão para usar a identidade gerenciada por meio do RBAC (controle de acesso baseado em função).

Posso criar vários vínculos de identidade para a mesma UAMI?

Sim. A URL do emissor OIDC mantida pelo AKS para essa UAMI é a mesma em todas as associações de identidade que fazem referência à mesma identidade gerenciada.

Quais permissões são necessárias para criar associações de identidade?

Permissões necessárias do ARM (Azure Resource Manager):

• Microsoft.ContainerService/managedClusters/identityBindings/*
• Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/*

Permissões necessárias do Kubernetes:

• Capacidade de criar ClusterRole e ClusterRoleBinding objetos (administrador de cluster ou equivalente).

O que acontece com o FIC criado automaticamente após a exclusão de todas as associações de identidades para um UAMI?

Hoje, não há coleta automática de lixo da FIC quando a última associação de identidade que faz referência a uma UAMI é excluída. Os operadores devem limpar manualmente a FIC somente após verificar se todas as associações de identidade para essa UAMI foram removidas para evitar a interrupção das dependências restantes.

Quais pré-requisitos de rede existem para associações de identidade?

Anteriormente, a identidade de carga de trabalho exigia saída para login.microsoftonline.com para que as cargas de trabalho pudessem trocar tokens de conta de serviço por tokens de acesso do Microsoft Entra. Com associações de identidade, as solicitações de troca de token roteiam por meio de um proxy de associação de identidade específico do cluster operado pelo AKS. A saída direta para a login.microsoftonline.com troca de tokens não é necessária.

Quais são as limitações para associações de identidade?

Ainda não há suporte para associações de identidade em clusters configurados com a integração de rede virtual do servidor de API.

Conteúdo relacionado

• Configurar associações de identidade para o AKS (Serviço de Kubernetes do Azure)