Conceitos de autenticação de clusters no Serviço de Kubernetes da Azure (AKS)

Este artigo descreve como o Azure Kubernetes Service (AKS) autentica os chamadores à API Kubernetes — ou seja, quem pode ligar-se ao plano de controlo. Abrange o caminho recomendado de autenticação baseado em Entra ID da Microsoft e como restringir o acesso de emergência.

Para saber como o AKS avalia o que um chamador autenticado pode fazer, veja conceitos de autorização de cluster.

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

Para uma orientação em todos os quatro cenários de identidade do AKS, consulte Opções de Acesso e identidade para o 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 fornecedor de identidade externo, teria de gerir credenciais locais por cluster, o que não escala e cria lacunas na auditoria.

Recomendamos a implementação de clusters AKS com autenticação Microsoft Entra ID para o plano de controlo. Com esta integração, o cluster valida os pedidos recebidos da API Kubernetes contra o Microsoft Entra ID e utiliza a identidade Entra do chamador para decisões de autorização. O Microsoft Entra ID centraliza a camada de identidade — qualquer alteração no estado do utilizador ou grupo é automaticamente refletida no acesso ao cluster — e permite o Acesso Condicional, autenticação multifator e Gestão de Identidade Privilegiada.

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

Para configuração, consulte Ativar a autenticação do ID Microsoft Entra para o plano de controlo do AKS. Tenha em atenção o seguinte:

  • O tenant Microsoft Entra configurado para autenticação de cluster deve ser o mesmo que o tenant da subscrição que contém o cluster AKS.
  • Para logins não interativos ou para versões antigas kubectl, use o plug-in kubelogin.

Os provedores de identidade externos (pré-visualização)

Algumas organizações precisam de autenticar os utilizadores do cluster com um fornecedor de identidade compatível com OIDC diferente do Microsoft Entra ID — por exemplo, GitHub, Google Workspace, Okta ou um IdP auto-hospedado. O AKS suporta isto através de autenticação estruturada, que configura os autenticadores JWT do servidor API Kubernetes para validar tokens emitidos pelo seu fornecedor externo.

Use esta opção apenas quando tiver um requisito rígido de manter a identidade do cluster fora do Microsoft Entra ID. Caso contrário, prefira o caminho Microsoft Entra ID para uma integração mais rica com Acesso Condicional, autenticação multifator e Gestão de Identidade Privilegiada.

Para uma visão geral, veja Autenticação de fornecedor de identidade externo para clusters AKS. Para configuração, consulte Configurar fornecedores de identidade externos com autenticação estruturada AKS.

Desativar contas locais

As contas locais utilizam um certificado de administrador integrado no cluster que contorna o Microsoft Entra ID. Qualquer chamador que consiga listar esta credencial obtém acesso total de administrador do cluster sem passar pelo Entra ID, o que viola a auditoria centralizada, o Acesso Condicional e a Gestão de Identidades Privilegiadas. Em produção, desative as contas locais para que todo o acesso flua através do Microsoft Entra ID.

Para impor isto em larga escala em muitos clusters, atribua a política pré-definida do Azure Kubernetes Service Clusters devem ter métodos locais de autenticação desativados num âmbito de subscrição ou grupo de gestão. A política audita ou nega clusters que são criados ou atualizados com contas locais ativadas. Para a lista completa de políticas incorporadas relacionadas com AKS, consulte as definições incorporadas de Azure Policy para AKS.

Para mais detalhes, consulte Gerir contas locais no AKS.

Autenticar nos nós do cluster

Modos de acesso SSH

Para além de se autenticar na API do Kubernetes, pode também precisar de se autenticar diretamente a um nó através de SSH para solução de problemas. O AKS suporta três modos de acesso SSH que se definem por cada cluster ou pool de nós:

  • SSH desativado (pré-visualização): Bloquear completamente o acesso de SSH aos nós. Recomendado para produção onde o acesso ao nível de nós é governado apenas por kubectl debug ou outros caminhos nativos do Kubernetes.
  • SSH baseado em ID Microsoft Entra (pré-visualização): Iniciar sessão em nós usando identidades Microsoft Entra, sem chaves SSH para gerir. Este modo é consistente com o restante da autenticação de cluster: herda do Entra ID o Acesso Condicional e a autenticação multifatorial, suporta elevação em tempo real através do Azure RBAC e Privileged Identity Management, e centraliza a auditoria através dos registos de início de sessão do Entra ID.
  • SSH de utilizador local: Acesso tradicional baseado em chaves SSH. Usa isto apenas quando o SSH baseado no Entra ID não for uma opção, e rode as chaves regularmente.

Para os passos de configuração e de definição por modo, consulte Gerir o acesso SSH nos nós do cluster AKS.

Passos seguintes

  • Last updated on