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

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

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.

Para a maioria das cargas de trabalho de produção no AKS, o AKS Automatic é a opção predefinida recomendada, porque parte de uma configuração base de plataforma pronta para produção, incluindo predefinições relacionadas com a identidade, ao mesmo tempo que preserva o mesmo modelo de identidade do AKS descrito neste artigo.

Este artigo apresenta uma breve introdução a cada cenário, explica como a orientação se relaciona com o AKS Automatic e o AKS Standard, e aponta para a documentação aprofundada.

Os cinco cenários de identidade em AKS

Scenario Pergunta que responde Documentação aprofundada
Um. Autenticação de plano de controlo do Kubernetes Quem é o chamador que está a usar a API do Kubernetes? Conceitos de autenticação em cluster, fornecedores externos de identidade
B. Autorização do plano de controle do Kubernetes O que é que o chamador pode fazer depois de autenticado na API Kubernetes? Conceitos de autorização de clusters
C. Autorização de recursos AKS (Azure Resource Manager) Quem pode realizar operações ao nível do Azure no recurso AKS, como puxar kubeconfig? Limitar o acesso ao ficheiro de configuração do cluster, funções incorporadas no Azure
D. Identidade de cluster (cluster → Azure) Como é que o cluster AKS age no Azure para gerir recursos em seu nome? Identidades geridas no AKS
E. Identidade de carga de trabalho (pod → Azure) Como é que os pods se autenticam em serviços Azure como Key Vault ou Storage? Visão geral do ID de carga de trabalho Microsoft Entra

Postura de identidade no AKS Automatic e no AKS Standard

Os cinco cenários de identidade neste artigo aplicam-se tanto ao AKS Automatic como ao AKS Standard. A principal diferença é a postura operacional:

  • O AKS Automatic fornece mais padrões pré-configurados de identidade e segurança.
  • O AKS Standard oferece mais controlo manual e exige mais opções de configuração.

Use o AKS Automático como ponto de partida padrão para a maioria das cargas de trabalho de produção, e use o AKS Standard quando precisar de uma configuração personalizada mais profunda da plataforma.

Para uma visão geral do AKS Automatic, veja Introdução ao Azure Kubernetes Service (AKS) Automatic.

Comparação de postura de identidade entre AKS Automatic e AKS Standard

Área de identidade Postura automática do AKS Postura padrão do AKS Mais informações
Autenticação da API do Kubernetes Predefinições orientadas para produção com integração no Microsoft Entra como modelo recomendado Configurável, incluindo contas locais e opções de integração com o Entra Conceitos de autenticação em cluster
Autorização da API do Kubernetes A autorização do Azure RBAC for Kubernetes está pré-configurada Modelo de prioridade às contas locais e de autorização selecionado pela configuração do cluster Conceitos de autorização de clusters
Autorização de recursos AKS Utiliza o modelo padrão Azure RBAC nas operações de recursos do AKS Utiliza o modelo padrão Azure RBAC nas operações de recursos do AKS Controlar o acesso ao kubeconfig
Identidade do cluster Utiliza o modelo de identidade gerida com os valores predefinidos da linha de base de produção Utiliza modelo de identidade gerida com configuração selecionada pelo operador Identidades geridas no AKS
Identidade do fluxo de trabalho A identidade da carga de trabalho e o emissor OIDC estão pré-configurados Opcional e configurado por operador Visão geral da identidade da carga de trabalho

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

Um. Autenticação de plano de controlo do 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 de cluster incorporado que contorna o Entra ID. Recomendamos desativar as contas locais durante a produção. Veja Gerir contas locais.
  • Fornecedores de identidade externos: Utilize um fornecedor de identidade compatível com OIDC diferente do Microsoft Entra ID. Ver Autenticação de fornecedor de identidade externo.

Para a maioria das cargas de trabalho de produção, comece com integração com AKS Automatic e Microsoft Entra.

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 controle 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 de Kubernetes Role, ClusterRole e RoleBinding, avaliado pelo servidor da 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 no 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. Gerir permissões de forma centralizada no Microsoft Entra ID para 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.

No AKS Automatic, a autorização Azure RBAC para Kubernetes é pré-configurada como parte da postura padrão de preparação para produção.

Para uma comparação e orientação sobre quando usar cada modelo, consulte conceitos de autorização de cluster.

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. Esta operação utiliza o Azure RBAC padrão contra o Microsoft.ContainerService fornecedor de recursos, é separada da autorização da API Kubernetes e aplica-se da mesma forma ao AKS Automatic e ao AKS Standard. Para mais informações, consulte Limitar o acesso ao ficheiro de configuração do cluster e as funções incorporadas em Funções incorporadas 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: Usada pelo plano de controlo do cluster para gerir os recursos do Azure para o cluster.
  • Identidade do kubelet: Utilizada pelo kubelet em cada nó para se autenticar junto de 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.

O AKS Automatic mantém este mesmo modelo de identidade, reduzindo o atrito na configuração através de padrões de produção pré-configurados.

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 ID de carga de trabalho Microsoft Entra, 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.

O AKS Automatic inclui a identidade da carga de trabalho e o emissor OIDC pré-configurados por predefinição. No AKS Standard, estas capacidades são opcionais e configuradas pelo operador.

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

Guia de decisão

Objetivo Usa esta documentação
Comece com uma base de identidade pronta para produção para a maioria das cargas de trabalho Introdução ao AKS Automático
Inscreva utilizadores no cluster com o Microsoft Entra ID Ativar a integração com o Microsoft Entra
Governar quem pode fazer o quê na API Kubernetes em vários clusters Use a autorização Microsoft Entra ID para a API Kubernetes
Restringa o acesso a tipos específicos de recursos personalizados Condições ABAC na autorização do Entra ID
Conceder permissões por cluster, por namespace como objetos Kubernetes Use Kubernetes RBAC com integração com Entra
Deixe o cluster puxar do ACR ou ligar discos Identidades geridas no AKS
Deixe as cápsulas chegar ao Cofre da Chave ou ao Armazenamento sem segredos Visão geral do ID de carga de trabalho Microsoft Entra
Restringa quem pode descarregar o cluster kubeconfig Limitar o acesso ao ficheiro de configuração do cluster
Crie um cluster pronto para produção com a postura de identidade predefinida Criar um cluster automático AKS

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

Para as permissões Azure que o AKS utiliza (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 referência de permissões de serviço AKS.

Conteúdo relacionado

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

  • Last updated on