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

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

Os cinco cenários de identidade no AKS

O restante deste artigo fornece uma breve orientação para cada cenário.

A. Autenticação do plano de controle do Kubernetes

A autenticação do plano de controle do Kubernetes estabelece a identidade de um usuário ou entidade de serviço que chama o servidor de API do Kubernetes. O AKS dá suporte a:

• Microsoft Entra ID (recomendado). Use identidades e grupos do Entra ID para fazer login no cluster. A integração com o Microsoft Entra é configurada e atualizada em seu nome. Para habilitar, consulte Usar a integração do Microsoft Entra.
• Contas locais. Um certificado de administrador de cluster incorporado que ignora o Entra ID. É recomendável desabilitar contas locais em produção. Consulte Gerenciar contas locais.
• Provedores de identidade externos. Use um provedor de identidade compatível com OIDC diferente da ID do Microsoft Entra. Consulte Autenticação do Provedor de Identidade Externo.

Para obter uma análise detalhada de como o AKS autentica solicitações de API do Kubernetes, consulte os conceitos de autenticação de cluster.

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

Depois que um chamador é autenticado na API do Kubernetes, o AKS autoriza a solicitação usando um (ou ambos) de dois modelos:

• RBAC do Kubernetes. O modelo nativo do Kubernetes Role / ClusterRole / RoleBinding avaliado pelo servidor de API. As permissões residem no cluster como objetos do Kubernetes.
• Autorização de identidade do Microsoft Entra. Um webhook de autorização do AKS delega as decisões de autorização ao Microsoft Entra ID por meio de atribuições de funções do Azure. As atribuições de função RBAC do Azure com dataActions são compatíveis com todos os recursos padrão da API do Kubernetes, e as atribuições de função com condições ABAC do Azure têm suporte para recursos personalizados. As permissões são gerenciadas centralmente no Microsoft Entra ID e podem administrar muitos clusters a partir de uma única atribuição de função no escopo de assinatura, grupo de gerenciamento ou grupo de recursos.

Para obter uma comparação lado a lado e diretrizes sobre quando usar cada modelo, consulte os conceitos de autorização de cluster.

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

Além de autorizar chamadas para a API do Kubernetes, você também precisa autorizar operações no nível do Azure no próprio recurso do AKS. O exemplo mais comum é controlar quem pode fazer o pull kubeconfig de um cluster, o que é uma operação independente do Azure Resource Manager que você pode gerenciar de forma granular com o Azure RBAC. Trata-se do RBAC padrão do Azure para o provedor de recursos Microsoft.ContainerService, distinto da autorização da API do Kubernetes. Consulte Limitar o acesso ao arquivo de configuração de cluster e as funções internas em funções internas do Azure.

D. Identidade do cluster (cluster → Azure)

Os clusters do AKS usam identidades gerenciadas do Azure para atuar nos recursos do Azure em seu nome, por exemplo, para criar balanceadores de carga, anexar discos ou efetuar pull de imagens do Registro de Contêiner do Azure. As principais identidades são:

• Identidade do plano de controle. Usado pelo painel de controle de cluster para gerenciar recursos do Azure para o cluster.
• Identidade do Kubelet. Utilizado pelo kubelet em cada nó para autenticar-se em serviços como o Registro de Contêiner do Azure.
• Identidade de complementos/extensões. Alguns complementos e extensões do AKS usam suas próprias identidades gerenciadas.

Para obter detalhes sobre cada tipo de identidade e como usar identidades atribuídas pelo sistema versus atribuídas pelo usuário, consulte Identidades gerenciadas no AKS.

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

A identidade da carga de trabalho permite que os pods em execução no cluster do AKS se autentiquem nos serviços do Azure protegidos pelo Microsoft Entra (como Key Vault, Armazenamento ou Cosmos DB) sem armazenar segredos no cluster. O AKS utiliza a Microsoft Entra Workload ID, que projeta um token de conta de serviço Kubernetes federado a um aplicativo do Microsoft Entra ou uma identidade gerenciada atribuída pelo usuário.

Não utilize a identidade gerenciada por pod do Microsoft Entra, que está em fase de descontinuação, para novas cargas de trabalho.

Guia de decisão

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

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

Próximas etapas

• Conceitos de autenticação de cluster
• Conceitos de autorização de cluster
• Utilizar a autorização do Microsoft Entra ID para a API do Kubernetes
• Identidades gerenciadas no AKS
• Microsoft Entra Workload ID visão geral

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

• Clusters e cargas de trabalho do Kubernetes/AKS
• Kubernetes / segurança do AKS
• Redes virtuais do Kubernetes/AKS
• Armazenamento do Kubernetes/AKS
• Escala do Kubernetes/AKS