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

Artigo
02/16/2024

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.

Neste artigo, discutimos quais práticas recomendadas um operador de cluster pode seguir para gerenciar o acesso e a identidade para clusters AKS. Saberá como:

Autentique usuários do cluster AKS com o Microsoft Entra ID.
Controle o acesso aos recursos com o controle de acesso baseado em função do Kubernetes (Kubernetes RBAC).
Use o RBAC do Azure para controlar granularmente 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 a partir de seus pods.

Aviso

A identidade gerenciada por pod do Microsoft Entra de código aberto (visualização) no Serviço Kubernetes do Azure foi preterida a partir de 24/10/2022.

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

Usar o Microsoft Entra ID

Orientações sobre boas práticas

Implante clusters AKS com a integração do 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 usuários ou grupos para o valor mínimo de permissões usando Funções, ClusterRoles ou Associações.

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

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 Microsoft Entra, como kubectl create pod.
O Kubernetes valida o token com o ID do Microsoft Entra e busca as associações de grupo do desenvolvedor.
RBAC do Kubernetes e políticas de cluster são aplicadas.
A solicitação do desenvolvedor é bem-sucedida com base na validação anterior da associação ao grupo Microsoft Entra e das políticas e RBAC do Kubernetes.

Para criar um cluster AKS que utilize o Microsoft Entra ID, consulte Integrar o Microsoft Entra ID com o AKS.

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

Orientações sobre boas práticas

Defina permissões de usuário ou grupo para recursos de cluster com o Kubernetes RBAC. Crie funções e associações que atribuam a menor quantidade 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, você aplica essas funções a usuários ou grupos com uma associação. Para obter mais informações sobre Funções, ClusterRoles e Associações, consulte Opções de acesso e identidade para o Serviço Kubernetes do Azure (AKS).

Por exemplo, você cria uma função com acesso total a recursos no namespace chamado 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 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.

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

Usar o RBAC do Azure

Orientações sobre boas práticas

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
- Puxe o seu kubeconfigarquivo .
Para saber como controlar o acesso ao recurso AKS e ao , consulte Limitar o acesso ao kubeconfigarquivo de configuração do cluster.
Acesso à API do Kubernetes.

Este nível de acesso é controlado por:
- Kubernetes RBAC (tradicionalmente) ou
- Integrando o RBAC do Azure com o AKS para autorização de kubernetes.
Para saber como conceder permissões granularmente à API do Kubernetes usando o RBAC do Azure, consulte Usar o RBAC do Azure para autorização do Kubernetes.

Usar identidades gerenciadas por pod

Aviso

A identidade gerenciada por pod do Microsoft Entra de código aberto (visualização) no Serviço 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 o risco de exposição ou abuso. Em vez disso, use identidades pod para solicitar acesso automaticamente usando o Microsoft Entra ID.

Para acessar outros recursos do Azure, como o Azure Cosmos DB, o Cofre da Chave ou o armazenamento de Blob, o pod precisa 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 alternadas regularmente.

Com identidades gerenciadas por pod (visualização) para recursos do Azure, você solicita automaticamente acesso a serviços por meio da ID do Microsoft Entra. As identidades gerenciadas por pods estão atualmente em pré-visualização para o AKS. Consulte a documentação Usar identidades gerenciadas por pod do Microsoft Entra no Serviço Kubernetes do Azure (Visualização) para começar.

A identidade gerenciada por pod do Microsoft Entra (visualização) suporta dois modos de operação:

Modo padrão : Neste modo, os 2 componentes a seguir são implantados no cluster AKS:
- Managed Identity Controller(MIC): um controlador Kubernetes que observa alterações em pods, AzureIdentity e AzureIdentityBinding por meio do Kubernetes API Server. Quando deteta 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 escala de máquina virtual 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 escala da máquina virtual do pool de nós, a menos que a mesma identidade gerenciada seja usada por outros pods. O MIC executa ações semelhantes quando AzureIdentity ou AzureIdentityBinding são criados ou excluídos.
- Node Managed Identity (NMI): é um pod que é executado como um DaemonSet em cada nó no cluster AKS. O NMI interceta solicitações de token de segurança para o Serviço de Metadados de Instância do Azure em cada nó. Ele redireciona as solicitações para si mesmo e valida 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: neste modo, há apenas NMI. A identidade precisa ser atribuída e gerenciada manualmente pelo usuário. Para obter mais informações, consulte Identidade do pod no modo gerenciado. Nesse modo, quando você usa o comando az aks pod-identity add para adicionar uma identidade pod a um cluster do Serviço Kubernetes do Azure (AKS), ele cria o AzureIdentity e AzureIdentityBinding no namespace especificado pelo parâmetro, enquanto o provedor de recursos AKS atribui a identidade gerenciada especificada pelo --namespace--identity-resource-id parâmetro ao conjunto de escala de máquina virtual de cada pool de nós no cluster AKS.

Nota

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

O managed modo oferece as seguintes vantagens sobre o standard:

A atribuição de identidade no conjunto de escala de máquina virtual de um pool de nós pode levar de 40 a 60 anos. Com cronjobs ou aplicativos que exigem acesso à identidade e não podem tolerar o atraso de atribuição, é melhor usar managed o modo, pois a identidade é pré-atribuída ao conjunto de escala de máquina virtual do pool de nós. Manualmente ou usando o comando az aks pod-identity add .
No standard modo, o MIC requer permissões de gravação no conjunto de escala de máquina virtual usado pelo cluster AKS e Managed Identity Operator permissão nas identidades gerenciadas atribuídas pelo usuário. Ao executar 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 pods solicitam um token de acesso em tempo real, usando-o para acessar apenas os recursos atribuídos. No AKS, há dois componentes que lidam com as operações para permitir que os pods usem identidades gerenciadas:

O servidor Node Management Identity (NMI) é um pod que é executado como um DaemonSet em cada nó no cluster AKS. O servidor NMI escuta solicitações de pod para 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 pods que solicitam acesso aos recursos do Azure com base em seu endereço remoto.
- Consulta o Provedor de Recursos do Azure.
O Provedor de Recursos do Azure verifica se há mapeamentos de identidade do Azure no cluster AKS.
O servidor NMI solicita um token de acesso do Microsoft Entra ID com base no mapeamento de identidade do pod.
Microsoft Entra ID fornece acesso ao servidor NMI, que é retornado para o pod.
- Esse token de acesso pode ser usado pelo pod para solicitar acesso a recursos no Azure.

No exemplo a seguir, um desenvolvedor cria um pod que usa uma identidade gerenciada para solicitar acesso ao 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 a recursos.
O servidor NMI é implantado para retransmitir quaisquer solicitações de pod, juntamente com o Provedor de Recursos do Azure, para tokens de acesso à ID do Microsoft Entra.
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 o Banco de Dados SQL do Azure

Para usar identidades gerenciadas por pod, consulte Usar identidades gerenciadas por pod do Microsoft Entra no Serviço Kubernetes do Azure (visualização).

Próximos passos

Este artigo de práticas recomendadas se concentrou na autenticação e autorização para 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: