Opções de acesso e identidade para o Azure Kubernetes Service (AKS)

O AKS utiliza a identidade em cinco cenários distintos. Cada cenário responde a uma questão diferente e tem o seu próprio modelo de configuração. Este artigo oferece uma breve introdução a cada um e aponta para a documentação aprofundada.

Os cinco cenários de identidade em AKS

O resto deste artigo dá uma breve orientação para cada cenário.

Um. Autenticação por plano de controlo Kubernetes

A autenticação por plano de controlo Kubernetes estabelece a identidade de um utilizador ou principal de serviço que chama o servidor API Kubernetes. AKS suporta:

• Microsoft Entra ID (recomendado). Use identidades e grupos do Entra ID para iniciar sessão no cluster. A integração com o Microsoft Entra prevê e roda a integração em seu nome. Para ativar, consulte Utilizar a integração do Microsoft Entra.
• Contas locais. Um certificado de administrador integrado no cluster que contorna o Entra ID. Recomendamos desativar as contas locais durante a produção. Veja Gerir contas locais.
• Fornecedores externos de identidade. Utilize um fornecedor de identidade compatível com OIDC que não seja o Microsoft Entra ID. Ver Autenticação de fornecedor de identidade externo.

Para uma análise aprofundada de como o AKS autentica pedidos da API Kubernetes, veja conceitos de autenticação de cluster.

B. Autorização do plano de controlo do Kubernetes

Depois de um chamador ser autenticado na API Kubernetes, o AKS autoriza o pedido usando um (ou ambos) de dois modelos:

• Kubernetes RBAC. O modelo nativo Kubernetes Role / ClusterRole / RoleBinding avaliado pelo servidor API. As permissões permanecem no cluster como objetos Kubernetes.
• Autorização do Microsoft Entra ID. Um webhook de autorização AKS delega decisões de autorização ao Microsoft Entra ID usando atribuições de funções Azure. As atribuições de papéis Azure RBAC com dataActions são suportadas para todos os recursos padrão da API Kubernetes, e atribuições de funções com condições Azure ABAC são suportadas para recursos personalizados. As permissões são geridas centralmente no Microsoft Entra ID e podem governar muitos clusters a partir de uma única atribuição de função no âmbito de subscrição, grupo de gestão ou grupo de recursos.

Para uma comparação lado a lado e orientações sobre quando usar cada modelo, consulte conceitos de autorização de clusters.

C. Autorização de recursos AKS (Azure Resource Manager)

Para além de autorizar chamadas para a API Kubernetes, também precisa de autorizar operações ao nível do Azure no recurso AKS em si. O exemplo mais comum é controlar quem pode extrair um cluster kubeconfig, que é uma operação autónoma do Azure Resource Manager que pode ser governada de forma detalhada com o Azure RBAC. Isto é o padrão Azure RBAC contra o Microsoft.ContainerService fornecedor de recursos, separado da autorização da API Kubernetes. Veja Limitar o acesso ao ficheiro de configuração do cluster e os papéis incorporados em Funções internas do Azure.

D. Identidade de cluster (cluster → Azure)

Os clusters AKS utilizam identidades geridas pelo Azure para atuar sobre os recursos do Azure em seu nome — por exemplo, para criar balanceadores de carga, anexar discos ou extrair imagens do Azure Container Registry. As principais identidades são:

• Identidade do plano de controlo. Usado pelo plano de controlo do cluster para gerir os recursos Azure para o cluster.
• Identidade Kubelet. Usado pelo kubelet em cada nó para autenticar serviços como o Azure Container Registry.
• Identidade de add-ons/extensões. Alguns add-ons e extensões do AKS usam as suas próprias identidades geridas.

Para detalhes sobre cada tipo de identidade e como usar identidades atribuídas pelo sistema versus atribuídas pelo utilizador, veja Identidades geridas no AKS.

E. Identidade de carga de trabalho (pod → Azure)

A identidade da carga de trabalho permite que pods a correr no seu cluster AKS autentiquem em serviços Azure protegidos pela Microsoft Entra (como Key Vault, Storage ou Cosmos DB) sem armazenar segredos no cluster. O AKS utiliza o Microsoft Entra Workload ID, que projeta um token de conta de serviço Kubernetes federado para uma aplicação Microsoft Entra ou uma identidade gerida atribuída pelo utilizador.

Não use a identidade obsoleta gerida por pod do Microsoft Entra para novas cargas de trabalho.

Guia de decisão

Referência de permissões do serviço AKS

Para as permissões Azure usadas pelo AKS — a identidade que cria o cluster, a identidade do cluster em tempo de execução, permissões adicionais de identidade de cluster e acesso ao nó AKS — veja a referência de permissões de serviço AKS.

Próximos passos

• Conceitos de autenticação em cluster
• Conceitos de autorização de clusters
• Use a autorização Microsoft Entra ID para a API Kubernetes
• Identidades geridas no AKS
• Visão geral do Microsoft Entra Workload ID

Para obter mais informações sobre os principais conceitos de Kubernetes e AKS, consulte os seguintes artigos:

• Clusters e cargas de trabalho Kubernetes / AKS
• Segurança de Kubernetes / AKS
• Redes virtuais Kubernetes / AKS
• Soluções de Armazenamento Kubernetes / AKS
• Escala de Kubernetes / AKS