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

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

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.

Para a maioria das cargas de trabalho de produção do AKS, o AKS Automatic é o padrão recomendado porque já vem com uma base de plataforma pronta para produção, incluindo configurações padrão relacionadas à identidade, e preserva o mesmo modelo de identidade do AKS descrito neste artigo.

Este artigo apresenta uma breve introdução a cada cenário, explica como as diretrizes se aplicam ao AKS Automatic e ao AKS Standard e indica a documentação detalhada.

Os cinco cenários de identidade no AKS

Scenario Pergunta respondida Documentos de aprofundamento
A. Autenticação do plano de controle do Kubernetes Quem está acessando a API do Kubernetes? Conceitos de autenticação de cluster, provedores de identidade externos
B. Autorização do plano de controle do Kubernetes O que o chamador pode fazer uma vez autenticado na API do Kubernetes? Conceitos de autorização de cluster
C. Autorização de recurso do AKS (Azure Resource Manager) Quem pode realizar operações no nível do Azure no recurso AKS, como fazer pull kubeconfig? Limitar o acesso ao arquivo de configuração de cluster, funções internas do Azure
D. Identidade do cluster (cluster → Azure) Como o cluster do AKS atua no Azure para gerenciar recursos em seu nome? Identidades gerenciadas no AKS
E. Identidade da carga de trabalho (pod → Azure) Como os pods se autenticam nos serviços do Azure, como Key Vault ou Armazenamento? ID de carga de trabalho do Microsoft Entra visão geral

Postura de identidade no AKS Automatic e no AKS Standard

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

  • O AKS Automatic fornece mais padrões de segurança e identidade pré-configurados.
  • O AKS Standard fornece mais controle manual e requer mais opções de instalação.

Use o AKS Automatic como o 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 de plataforma personalizada mais profunda.

Para obter uma visão geral do AKS Automatic, consulte Introdução ao AKS (Serviço de Kubernetes do Azure) Automatic.

Comparação de postura de identidade automática do AKS e do AKS Standard

Área de identidade Postura automática do AKS Postura padrão do AKS Saiba mais
Autenticação da API do Kubernetes Configurações padrão voltadas para produção com integração com o Microsoft Entra como o modelo recomendado Configurável, incluindo contas locais e opções de integração do Entra Conceitos de autenticação de cluster
Autorização da API do Kubernetes O Azure RBAC para autorização do Kubernetes é pré-configurado Modelo de autorização com conta local em primeiro lugar selecionado pela configuração do cluster Conceitos de autorização de cluster
Autorização de recurso do AKS Usa o modelo padrão do Azure RBAC para operações de recursos do AKS Usa o modelo padrão do Azure RBAC nas operações de recursos do AKS Controlar o acesso ao kubeconfig
Identidade do cluster Usa o modelo de identidade gerenciada com padrões da configuração base de produção Usa o modelo de identidade gerenciada com a configuração selecionada pelo operador Identidades gerenciadas no AKS
Identidade da carga de trabalho A identidade da carga de trabalho e o emissor do OIDC são pré-configurados Opcional e configurado pelo operador Visão geral da identidade da carga de trabalho

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 integrado de administrador do cluster que contorna 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 de Microsoft Entra ID. Consulte Autenticação do Provedor de Identidade Externo.

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

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 Role, ClusterRole e RoleBinding nativo do Kubernetes avaliado pelo servidor da API. As permissões residem no cluster como objetos do Kubernetes.
  • Autorização do Microsoft Entra ID: um webhook de autorização do AKS delega decisões de autorização ao Microsoft Entra ID usando atribuições de função 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. Gerencie permissões centralmente no Microsoft Entra ID para governar vários clusters por meio de uma única atribuição de função no escopo da assinatura, do grupo de gerenciamento ou do grupo de recursos.

No AKS Automatic, a autorização do Azure RBAC para Kubernetes é pré-configurada como parte da configuração padrão pronta para produção.

Para obter uma comparação 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. Essa operação usa o RBAC padrão do Azure em relação ao provedor de recursos Microsoft.ContainerService, é separada da autorização da API Kubernetes e se aplica da mesma forma ao AKS Automatic e ao AKS Standard. Para obter mais informações, consulte Limitar o acesso ao arquivo de configuração do cluster e as funções integradas 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: usada pelo plano de controle do cluster para gerenciar recursos do Azure para o cluster.
  • Identidade do kubelet: usada pelo kubelet em cada nó para se autenticar 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.

O AKS Automatic mantém esse mesmo modelo de identidade, reduzindo o atrito de instalação por meio de padrões de produção pré-configurados.

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

O AKS Automático inclui a identidade da carga de trabalho e o emissor OIDC como padrões pré-configurados. No AKS Standard, esses recursos são opcionais e configurados pelo operador.

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

Goal Use esses documentos
Comece com uma base de identidade pronta para produção para a maioria das cargas de trabalho Introdução ao AKS Automatic
Conectar usuários ao cluster com a ID do Microsoft Entra Habilitar a integração do Microsoft Entra
Governe quem pode fazer o que na API do Kubernetes em vários clusters Utilizar a autorização do Microsoft Entra ID para a API do Kubernetes
Restringir o acesso a tipos de recursos personalizados específicos Condições ABAC na autorização do Entra ID
Autorizar permissões por cluster, por namespace como objetos Kubernetes. Usar RBAC do Kubernetes com integração com Entra
Permita que o cluster faça o pull do ACR ou conecte discos Identidades gerenciadas no AKS
Permita que os pods acessem o Key Vault ou o Armazenamento sem segredos ID de carga de trabalho do Microsoft Entra visão geral
Restringir quem pode baixar o cluster kubeconfig Limitar o acesso ao arquivo de configuração do cluster
Criar um cluster pronto para produção com a configuração de identidade padrão Criar um cluster automático do AKS

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

Para obter as permissões do Azure que o AKS usa (a identidade que cria o cluster, a identidade do cluster em tempo de execução, permissões adicionais de identidade do cluster e acesso aos nós do AKS), consulte a referência de permissões de serviço do AKS.

Conteúdo relacionado

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

  • Last updated on