Práticas recomendadas para autenticação e autorização no Azure Kubernetes Service (AKS)

Artigo
02/16/2024

À 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.

Neste artigo, discutimos as melhores práticas que um operador de cluster pode seguir para gerenciar o acesso e a identidade para clusters do AKS. Você aprenderá a:

Autenticar usuários de cluster do AKS com o Microsoft Entra ID.
Controlar o acesso a recursos com o RBAC do Kubernetes (controle de acesso baseado em função do Kubernetes).
Usar o Azure RBAC para controlar de forma granular o acesso ao recurso AKS, à API do Kubernetes em escala e ao kubeconfig.
Use uma identidade de carga de trabalho para acessar os recursos do Azure de seus pods.

Aviso

A identidade gerenciada por pod do Microsoft Entra de software livre (versão prévia) no Serviço de Kubernetes do Azure foi preterida a partir de 24/10/2022.

Se você tiver a identidade gerenciada por pod do Microsoft Entra habilitada no cluster do AKS ou estiver considerando implementá-la, recomendamos que você examine o artigo de visão geral da identidade da carga de trabalho para entender nossas recomendações e opções para configurar o cluster para usar uma ID de carga de trabalho do Microsoft Entra (versão prévia). Esse método de autenticação substitui a identidade gerenciada por pod (versão prévia), que se integra aos recursos nativos do Kubernetes para federar com os provedores de identidade externos.

Usar a ID do Microsoft Entra

Orientação de melhor prática

Implantar 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. Saiba mais sobre esses RBAC do Kubernetes na próxima seção. A integração do Microsoft Entra e como você controla o acesso a recursos pode ser vista no seguinte diagrama:

Cluster-level authentication for Microsoft Entra integration with AKS

O desenvolvedor se autentica com o Microsoft Entra ID.
O ponto de extremidade de emissão de token do Microsoft Entra emite o token de acesso.
O desenvolvedor executa uma ação usando o token do Microsoft Entra, como kubectl create pod.
O Kubernetes valida o token com o Microsoft Entra ID e busca as associações de grupo do desenvolvedor.
O RBAC do Kubernetes e as políticas de cluster são aplicados.
A solicitação do desenvolvedor é realizada com sucesso de acordo com a validação anterior da associação ao grupo do Microsoft Entra e do RBAC e das políticas do Kubernetes.

Para criar um cluster do AKS que usa o Microsoft Entra ID, confira como Integrar o Microsoft Entra ID ao AKS.

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

Orientação de melhor prática

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. Para obter mais informações sobre Funções, ClusterRoles e Vinculações, consulte Opções de acesso e identidade para o Serviço de Kubernetes do Azure (AKS).

Por exemplo, crie uma função com acesso total aos recursos no namespace denominado finance-app, conforme mostrado no seguinte exemplo de manifesto YAML:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Em seguida, você cria um RoleBinding e vincula o usuário developer1@contoso.com do Microsoft Entra a ele, conforme mostrado no seguinte manifesto YAML:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

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

Para saber como usar os grupos do Microsoft Entra para controlar o acesso aos recursos do Kubernetes usando o RBAC do Kubernetes, confira como Controlar o acesso aos recursos de cluster usando o controle de acesso baseado em função e as identidades do Microsoft Entra no AKS.

Usar o Azure RBAC

Orientação de melhor prática

Use o RBAC do Azure para definir o mínimo necessário de permissões de usuário e grupo para recursos 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.
Para saber como controlar o acesso ao recurso AKS e ao kubeconfig, confira Limitar o acesso ao arquivo de configuração de cluster.
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.
Para saber como conceder permissões de forma granular à API do Kubernetes usando o RBAC do Azure, confira Usar o RBAC do Azure para a autorização de Kubernetes.

Usar identidades gerenciadas por pod

Aviso

A identidade gerenciada por pod do Microsoft Entra de software livre (versão prévia) no Serviço de Kubernetes do Azure foi preterida a partir de 24/10/2022.

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. Atualmente, as identidades gerenciadas por pod estão em versão prévia para AKS. Confira a documentação Usar identidades gerenciadas por pod do Microsoft Entra no Serviço de Kubernetes do Azure (versão prévia) para começar.

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

Modo padrão: nesse modo, os dois componentes a seguir 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. Para obter mais informações, confira Identidade do Pod no modo gerenciado. Nesse 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 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 para o conjunto de dimensionamento de máquinas virtuais de cada pool de nós no cluster do AKS.

Observação

Se, em vez disso, você decidir instalar a identidade gerenciada por pod do Microsoft Entra usando o complemento de cluster do AKS, a instalação usará o modo managed.

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 demorar 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 NMI (Node Management Identity) é um pod executado como um DaemonSet em cada nó no cluster 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 há 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.

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.
O Provedor de Recursos do Azure verifica mapeamentos de identidade do Azure no cluster do AKS.
O servidor NMI solicita um token de acesso do Microsoft Entra ID com base no mapeamento de identidade do pod.
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:

Pod identities allow a pod to automatically request access to other resources.

O operador de cluster cria uma conta de serviço para mapear identidades quando os pods solicitam acesso aos recursos.
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.
Um desenvolvedor implanta um pod com uma identidade gerenciada que solicita um token de acesso por meio do servidor NMI.
O token é retornado ao pod e usado para acessar uma instância do Banco de Dados SQL do Azure

Para usar identidades gerenciadas por pod, veja Usar identidades gerenciadas por pod do Microsoft Entra no Serviço de Kubernetes do Azure (versão prévia).

Próximas etapas

Este artigo de práticas recomendadas enfocou a autenticação e a autorização de seu cluster e recursos. Para implementar algumas dessas práticas recomendadas, consulte os seguintes artigos:

Para obter mais informações sobre operações de cluster no AKS, consulte as seguintes práticas recomendadas: