Configurar a autenticação para o Serviço Kubernetes do Azure

  • {númeroDeMinutos} minutos

Ao implantar e manter clusters no Serviço Kubernetes do Azure (AKS), você implementa maneiras de gerenciar o acesso a recursos e serviços. Sem estes controlos:

  • As contas podem ter acesso a recursos e serviços desnecessários.
  • Controlar as credenciais usadas para fazer alterações pode ser difícil.

Usar o Microsoft Entra ID

Orientação de práticas recomendadas: Implante clusters AKS com integração com o Microsoft Entra. O uso do Microsoft Entra ID centraliza a camada de gerenciamento de identidades. Qualquer alteração na conta de usuário ou status do grupo é automaticamente atualizada no acesso ao cluster AKS. Defina o escopo de utilizadores ou grupos para o nível mínimo de permissões usando Roles, ClusterRoles ou Vínculos.

Os desenvolvedores de cluster do Kubernetes e os proprietários de aplicativos precisam ter acesso a diferentes recursos. O Kubernetes não possui uma solução de gerenciamento de identidades para você controlar os recursos com os quais os usuários podem interagir. Em vez disso, você pode integrar seu cluster a uma solução de identidade existente, como o Microsoft Entra ID, uma solução de gerenciamento de identidades pronta para empresas.

Com clusters integrados do Microsoft Entra no AKS, você cria Roles ou ClusterRoles definindo permissões de acesso a recursos. Em seguida, você vincula as funções a usuários ou grupos a partir da ID do Microsoft Entra.

A integração do Microsoft Entra e como você controla o acesso aos recursos pode ser vista no diagrama a seguir:

Diagrama mostrando um exemplo de um fluxo de autenticação de cluster kubernetes.

  1. O desenvolvedor se autentica com o Microsoft Entra ID.

  2. O ponto de extremidade de emissão de token do Microsoft Entra emite o token de acesso.

  3. O desenvolvedor executa uma ação usando o token Microsoft Entra, como kubectl create pod.

  4. O Kubernetes valida o token com o ID do Microsoft Entra e busca as associações de grupo do desenvolvedor.

  5. RBAC do Kubernetes e políticas de cluster são aplicadas.

  6. O pedido do programador é bem-sucedido com base na validação prévia da adesão ao grupo Microsoft Entra e do RBAC e políticas do Kubernetes.

Usar controlo de acesso baseado em funções do Kubernetes (Kubernetes RBAC)

Orientação de práticas recomendadas: defina permissões de usuário ou grupo para agrupar recursos com o Kubernetes RBAC. Crie papéis e associações que atribuam o número mínimo de permissões necessárias. Integre-se com o Microsoft Entra ID para atualizar automaticamente qualquer alteração de status de usuário ou associação de grupo e manter o acesso aos recursos do cluster atualizado.

No Kubernetes, você fornece controle de acesso granular para recursos de cluster. Você define permissões no nível do cluster ou para namespaces específicos. Você determina quais recursos podem ser gerenciados e com quais permissões. Em seguida, aplica essas funções a utilizadores ou grupos com uma vinculação.

Quando developer1@contoso.com é autenticado no cluster AKS, eles têm permissões totais para recursos no namespace do aplicativo de finanças. Dessa forma, você separa e controla logicamente o acesso aos recursos. Use o Kubernetes RBAC com a integração de ID do Microsoft Entra.

Usar o RBAC do Azure

Orientação de práticas recomendadas: use o RBAC do Azure para definir as permissões mínimas necessárias de usuário e grupo para recursos do AKS em uma ou mais assinaturas.

Há dois níveis de acesso necessários para operar totalmente um cluster AKS:

  • Aceda ao recurso AKS na sua subscrição do Azure. Este nível de acesso permite-lhe:
    • Controle o dimensionamento ou a atualização do cluster usando as APIs do AKS
    • Recupere o teu kubeconfig.
  • Acesso à API do Kubernetes. Este nível de acesso é controlado por:
    • Kubernetes RBAC (tradicionalmente) ou
    • Integrando Azure RBAC com AKS para autorização Kubernetes.

Usar identidade de carga de trabalho

Orientação de boas práticas: Use a identidade da carga de trabalho com a federação OIDC para autenticação de pods nos recursos Azure. Não use credenciais fixas em pods ou imagens de contêiner, pois elas correm o risco de exposição ou abuso.

Para aceder a outros recursos Azure, como Azure Cosmos DB, Key Vault ou armazenamento Blob, os pods precisam de credenciais de autenticação. Você pode definir credenciais de autenticação com a imagem do contêiner ou injetá-las como um segredo do Kubernetes. De qualquer forma, você precisaria criá-los e atribuí-los manualmente. Normalmente, essas credenciais são reutilizadas em pods e não são rotacionadas regularmente.

Com a identidade de carga de trabalho para recursos do Azure, você solicita automaticamente acesso a serviços usando o Microsoft Entra ID com a federação OpenID Connect (OIDC). A identidade da carga de trabalho é o método de autenticação recomendado para cargas de trabalho do AKS.

Como funciona a identidade de carga de trabalho:

A identidade da carga de trabalho utiliza contas de serviço Kubernetes e federação OIDC para fornecer tokens aos pods sem necessidade de segredos ou componentes de identidade gerida nos nós:

  1. Configuração de federação: Estabelece-se uma credencial de identidade federada que cria uma relação de confiança entre o ID Microsoft Entra e a conta de serviço Kubernetes.

  2. Projeção de tokens: A AKS projeta um token de conta de serviço assinado no pod, que inclui alegações sobre a conta de serviço Kubernetes.

  3. Troca de tokens: O Azure Identity SDK na sua aplicação troca o token da conta de serviço Kubernetes por um token de acesso Microsoft Entra usando OIDC.

  4. Acesso a recursos: A aplicação utiliza o token de acesso Microsoft Entra para autenticar nos recursos Azure.

Principais benefícios da identidade da carga de trabalho:

  • Sem segredos necessários: Elimina a necessidade de armazenar credenciais ou gerir segredos no seu cluster.
  • Rotação de credenciais: Os tokens são rotacionados automaticamente e atualizados pela plataforma.
  • Controlo de acesso detalhado: Cada conta de serviço pode ser mapeada para uma identidade gerida específica com apenas as permissões necessárias.
  • Baseado em normas: Utiliza protocolo OIDC padrão da indústria para federação.
  • Sem componentes ao nível do nó: Ao contrário da identidade gerida por pod, não requer DaemonSets nem interceção de chamadas para o Azure Instance Metadata Service.

No exemplo seguinte, um programador cria um pod que usa a identidade da carga de trabalho para solicitar acesso à Azure SQL Database:

Diagrama que mostra um exemplo de como um programador cria um pod que usa identidade de carga de trabalho.

  1. O operador do cluster cria uma conta de serviço Kubernetes e estabelece uma credencial de identidade federada que a liga a uma identidade gerida atribuída pelo utilizador.
  2. O webhook de admissão mutante injeta automaticamente as variáveis de ambiente necessárias e o volume de tokens nos pods usando a conta de serviço.
  3. Um programador implementa um pod que faz referência à conta do serviço Kubernetes.
  4. O pod recebe o token projetado da conta de serviço, troca-o por um token de acesso Microsoft Entra via OIDC e usa-o para aceder à Azure SQL Database.