Conceitos de autenticação de cluster no AKS (Serviço de Kubernetes do Azure)

Este artigo descreve como o AKS (Serviço de Kubernetes do Azure) autentica os chamadores para a API do Kubernetes , ou seja, quem pode se conectar ao plano de controle. Ele aborda a rota de autenticação recomendada baseada no Microsoft Entra ID e como restringir o acesso de emergência.

Para saber como o AKS avalia o que um chamador autenticado tem permissão para fazer, consulte os conceitos de autorização de cluster.

Para os outros cenários de identidade no AKS, consulte:

Para obter uma orientação em todos os quatro cenários de identidade do AKS, consulte as opções de acesso e identidade do AKS.

Autenticar no servidor de API do Kubernetes (plano de controle)

O próprio Kubernetes não fornece um diretório de identidade. Sem um provedor de identidade externo, você precisaria gerenciar credenciais locais por cluster, o que não dimensiona e cria lacunas de auditoria.

Recomendamos implantar clusters AKS com autenticação de Microsoft Entra ID para o plano de gerenciamento. Com essa integração, o cluster valida as solicitações de API do Kubernetes recebidas contra o Microsoft Entra ID e usa a identidade Entra do chamador para decisões de autorização. A ID do Microsoft Entra centraliza a camada de identidade – qualquer alteração no status do usuário ou do grupo é refletida automaticamente no acesso ao cluster – e habilita o Acesso Condicional, a autenticação multifator e o Privileged Identity Management.

Diagrama que mostra a integração do Microsoft Entra com clusters do AKS para autenticação.

Para a configuração, consulte Ativar a autenticação do Microsoft Entra ID para o plano de controle do AKS. Observe o seguinte:

  • O locatário do Microsoft Entra configurado para a autenticação do cluster deve ser o mesmo que o locatário da assinatura que hospeda o cluster AKS.
  • Para logins não interativos ou versões mais antigas kubectl, use o kubelogin plugin.

Provedores de identidade externos (versão prévia)

Algumas organizações precisam autenticar usuários de cluster com um provedor de identidade compatível com OIDC diferente da ID do Microsoft Entra , por exemplo, GitHub, Google Workspace, Okta ou um IdP auto-hospedado. O AKS dá suporte a isso por meio da autenticação estruturada, que configura os autenticadores JWT do servidor de API do Kubernetes para validar os tokens emitidos pelo provedor externo.

Use essa opção somente quando você tiver um requisito difícil para manter a identidade do cluster fora da ID do Microsoft Entra. Caso contrário, opte pela solução Microsoft Entra ID para obter uma integração mais completa com o Acesso Condicional, a autenticação multifatorial e o Privileged Identity Management.

Para obter uma visão geral, consulte a autenticação do provedor de identidade externo para clusters do AKS. Para configurar, consulte Configurar provedores de identidade externos com autenticação estruturada do AKS.

Desabilitar contas locais

As contas locais usam um certificado de administrador de cluster interno que ignora a ID do Microsoft Entra. Qualquer chamador que possa listar essa credencial obtém acesso completo de administrador de cluster sem passar pela ID do Entra, que interrompe a auditoria centralizada, o Acesso Condicional e o Privileged Identity Management. Em produção, desabilite as contas locais para que todo o acesso seja processado por meio do Microsoft Entra ID.

Para aplicar essa política em grande escala em vários clusters, atribua a política integrada dos clusters do Serviço de Kubernetes do Azure do Azure Policy devem ter métodos de autenticação local desativados no âmbito de uma assinatura ou de um grupo de gerenciamento. A política audita ou nega clusters criados ou atualizados com contas locais habilitadas. Para obter a lista completa de políticas internas relacionadas ao AKS, consulte as definições internas do Azure Policy para AKS.

Para obter detalhes, consulte Gerenciar contas locais no AKS.

Autenticar-se nos nós do cluster

Modos de acesso SSH

Além de autenticar na API do Kubernetes, talvez você também precise se autenticar diretamente em um nó no SSH para solução de problemas. O AKS dá suporte a três modos de acesso SSH definidos por cluster ou pool de nós:

  • SSH desabilitado (versão prévia): bloqueie totalmente o acesso SSH aos nós. Recomendado para ambientes de produção em que o acesso no nível do nó é controlado exclusivamente por meio de kubectl debug ou outras vias nativas do Kubernetes.
  • SSH baseado em Microsoft Entra ID (versão prévia): autentique-se em unidades usando identidades do Microsoft Entra, sem chaves SSH para gerenciar. Este modo é compatível com o restante da autenticação em cluster: ele herda o Acesso Condicional e a autenticação multifatorial do Entra ID, oferece suporte à elevação de privilégios just-in-time por meio do Azure RBAC e do Privileged Identity Management e centraliza a auditoria por meio dos registros de login do Entra ID.
  • SSH do usuário local: acesso baseado em chave SSH tradicional. Use isso somente quando o SSH com autenticação pelo ID do Entra não for uma opção, e alterne as chaves regularmente.

Para obter instruções sobre a instalação e a configuração por modo, consulte Gerenciar o acesso SSH nos nós do cluster AKS.

Próximas Etapas 

  • Last updated on