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

Concluído

À medida que você implanta e mantém clusters no AKS (Azure Kubernetes Service), você implementa maneiras de gerenciar o acesso a recursos e serviços. Sem esses controles:

• As contas podem ter acesso a recursos e serviços desnecessários.
  
• As credenciais de acompanhamento usadas para fazer alterações podem ser difíceis.

Usar a ID do Microsoft Entra

Diretrizes de melhores práticas: Implante clusters do AKS com a integração do Microsoft Entra. O uso do Microsoft Entra ID centraliza a camada de gerenciamento de identidade. Qualquer alteração na conta do usuário ou no status do grupo é atualizada automaticamente no acesso ao cluster do AKS. Delimitar usuários ou grupos à quantidade mínima de permissões usando Funções, ClusterRoles ou Associações.

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

Com os clusters integrados do Microsoft Entra no AKS, você cria Funções ou ClusterRoles que definem as permissões de acesso aos recursos. Em seguida, você vincula as funções a usuários ou grupos do Microsoft Entra ID.

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

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 do Microsoft Entra, como kubectl create pod.

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

5. O RBAC do Kubernetes e as políticas de cluster são aplicados.

6. A solicitação do desenvolvedor é baseada com êxito na validação anterior da associação de grupo do Microsoft Entra e RBAC e políticas do Kubernetes.

Usar o controle de acesso baseado em função do Kubernetes (RBAC do Kubernetes)

Diretrizes de melhores práticas: Defina permissões de usuário ou grupo para recursos de cluster com o RBAC do Kubernetes. Crie funções e ligações que atribuam a menor quantidade de permissões necessárias. Integre-se ao Microsoft Entra ID para atualizar automaticamente qualquer alteração de status de usuário ou de associação de grupo e manter o acesso aos recursos de cluster atuais.

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

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

Usar o Azure RBAC

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

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

• Acessar o recurso do AKS em sua assinatura do Azure.
• Esse nível de acesso permite que você:
  • Controle o dimensionamento ou a atualização do cluster usando as APIs AKS
  • Efetue pull do kubeconfig.
• Acesso à API do Kubernetes.
• Esse nível de acesso é controlado por:
  • RBAC do Kubernetes (tradicionalmente) ou
  • Integrando o RBAC do Azure ao AKS para autorização do Kubernetes.

Usar identidades gerenciadas por pod

Não use credenciais fixas em pods ou imagens de contêiner, pois elas correm risco de exposição ou abuso. Em vez disso, use as identidades do pod para solicitar acesso automaticamente usando o Microsoft Entra ID.

Para acessar outros recursos do Azure, como o Azure Cosmos DB, Key Vault ou Armazenamento de Blobs, o pod precisa de credenciais de autenticação. Você pode definir credenciais de autenticação com a imagem de contêiner ou inseri-las como um segredo do Kubernetes. De qualquer forma, você precisaria criá-los e atribuí-los manualmente. Geralmente, essas credenciais são reutilizadas nos pods e não são giradas regularmente.

Com as identidades gerenciadas por pod (versão prévia) para recursos do Azure, você solicita automaticamente acesso a serviços por meio do Microsoft Entra ID. As identidades gerenciadas por pod estão atualmente em versão prévia para o AKS.

A identidade gerenciada por pod do Microsoft Entra (versão prévia) dá suporte a dois modos de operação:

• Modo Standard: Neste modo, os seguintes dois componentes são implantados no cluster do AKS:
  • MIC (Controlador de Identidades Gerenciadas): um controlador Kubernetes que inspeciona alterações em pods, AzureIdentity e AzureIdentityBinding por meio do Servidor de API do Kubernetes. Quando detecta uma alteração relevante, o MIC adiciona ou exclui AzureAssignedIdentity conforme necessário. Especificamente, quando um pod é agendado, o MIC atribui a identidade gerenciada no Azure ao conjunto de dimensionamento de máquinas virtuais subjacente usado pelo pool de nós durante a fase de criação. Quando todos os pods que usam a identidade são excluídos, ele remove a identidade do conjunto de dimensionamento de máquinas virtuais do pool de nós, a menos que a mesma identidade gerenciada seja usada por outros pods. O MIC toma ações semelhantes quando AzureIdentity ou AzureIdentityBinding é criado ou excluído.
    
  • NMI (Node Management Identity): é um pod executado como um DaemonSet em cada nó no cluster AKS. A NMI intercepta as solicitações de token de segurança para o Serviço de Metadados da Instância do Azure em cada nó. Ela redireciona as solicitações para si mesma e verifica se o pod tem acesso à identidade para a qual está solicitando um token e busca o token do locatário do Microsoft Entra em nome do aplicativo.
    
• Modo gerenciado: nesse modo, existe apenas a NMI. A identidade precisa ser atribuída manualmente e gerenciada pelo usuário. Neste modo, quando você usa o comando “az aks pod-identity add” para adicionar uma identidade de pod a um cluster do AKS (Serviço de Kubernetes do Azure), ele cria o AzureIdentity e AzureIdentityBinding no namespace especificado pelo parâmetro --namespace, enquanto o provedor de recursos do AKS atribui a identidade gerenciada especificada pelo parâmetro --identity-resource-id ao conjunto de dimensionamento de máquinas virtuais de cada pool de nós no cluster do AKS.
  

Observação

Se você optar por instalar a identidade gerenciada por pod do Microsoft Entra usando o complemento do cluster do AKS, a configuração será feita no modo gerenciado.

O modo managed oferece as seguintes vantagens com relação ao standard:

• A atribuição de identidade no conjunto de dimensionamento de máquinas virtuais de um pool de nós pode levar de 40 a 60 segundos. Com cronjobs ou aplicativos que exigem acesso à identidade e não podem tolerar o atraso de atribuição, é melhor usar o modo managed, pois a identidade é previamente atribuída ao conjunto de dimensionamento de máquinas virtuais do pool de nós. Manualmente ou usando o comando az aks pod-identity add.
  
• No modo standard, o MIC exige permissões de gravação no conjunto de dimensionamento de máquinas virtuais usado pelo cluster do AKS e a permissão Managed Identity Operator nas identidades gerenciadas atribuídas pelo usuário. Durante a execução no managed mode, como não há MIC, as atribuições de função não são necessárias.

Em vez de definir manualmente as credenciais para pods, as identidades gerenciadas por pod solicitam um token de acesso em tempo real, usando-o para acessar apenas seus recursos atribuídos. No AKS, há dois componentes que trabalham com as operações para permitir que os pods usem identidades gerenciadas:

• O servidor de Identidade Gerenciada do Nó (NMI) é um pod que é executado como um DaemonSet em cada nó no cluster do AKS. O servidor NMI ouve solicitações de pod a serviços do Azure.
• O Provedor de Recursos do Azure consulta o servidor de API do Kubernetes e verifica se existe um mapeamento de identidade do Azure que corresponda a um pod.

Quando os pods solicitam um token de segurança do Microsoft Entra ID para acessar um recurso do Azure, as regras de rede redirecionam o tráfego para o servidor NMI.

1. O servidor NMI:

   • Identifica os pods solicitando acesso aos recursos do Azure com base em seu endereço remoto.
   • Consultas ao Provedor de Recursos do Azure.

2. O Provedor de Recursos do Azure verifica mapeamentos de identidade do Azure no cluster do AKS.

3. O servidor NMI solicita um token de acesso do Microsoft Entra ID com base no mapeamento de identidade do pod.

4. O Microsoft Entra ID fornece acesso ao servidor NMI, que é retornado ao pod.

   • Esse token de acesso pode ser usado pelo pod para solicitar acesso aos recursos no Azure.

No exemplo a seguir, um desenvolvedor cria um pod que usa uma identidade gerenciada para solicitar acesso a uma instância do Banco de Dados SQL do Azure:

1. O operador de cluster cria uma conta de serviço para mapear identidades quando os pods solicitam acesso aos recursos.
2. O servidor NMI é implantado para retransmitir qualquer solicitação de pod, juntamente com o provedor de recursos do Azure, para tokens de acesso ao Microsoft Entra ID.
3. Um desenvolvedor implanta um pod com uma identidade gerenciada que solicita um token de acesso por meio do servidor NMI.
4. O token é retornado ao pod e usado para acessar uma instância do Banco de Dados SQL do Azure