Este artigo descreve como o Amazon EKS (Serviço de Kubernetes Elástico da Amazon) e o AKS (Serviço de Kubernetes do Azure) fornecem identidade para cargas de trabalho do Kubernetes acessarem serviços de plataforma na nuvem. Para obter uma comparação detalhada do IAM (Gerenciamento de Identidades e Acesso) do AWS (Amazon Web Services) e do Microsoft Entra ID, consulte:
- Gerenciamento de identidade e acesso do Microsoft Entra para AWS
- Como mapear conceitos do IAM do AWS para semelhantes no Azure
Este guia explica como clusters, serviços internos e complementos do AKS usam identidades gerenciadas para acessar recursos do Azure, como balanceadores de carga e discos gerenciados. O artigo também demonstra como usar a ID de Carga de Trabalho do Microsoft Entra para que as cargas de trabalho do AKS possam acessar os recursos do Azure sem precisar de uma cadeia de conexão, chave de acesso ou credenciais de usuário.
Observação
Este artigo faz parte de uma série de artigos que ajudam profissionais familiarizados com o Amazon EKS a entender o Serviço Azure Kubernetes (AKS).
Gerenciamento de Identidades e Acesso do Amazon EKS
O Amazon EKS tem duas opções nativas para chamar serviços do AWS de dentro de um pod do Kubernetes: funções do IAM para contas de serviço e funções vinculadas ao serviço do Amazon EKS.
As funções do IAM para contas de serviço associam funções do IAM a uma conta de serviço do Kubernetes. Essa conta de serviço fornece permissões do AWS para os contêineres em qualquer pod que a utilize. As funções do IAM para contas de serviço oferecem os seguintes benefícios:
Privilégio mínimo: você não precisa fornecer permissões estendidas para a função do IAM do nó para pods nesse nó para chamar APIs do AWS. É possível definir o escopo das permissões do IAM para uma conta de serviço e somente os pods que usam essa conta terão acesso a essas permissões. Esse recurso também elimina a necessidade de soluções de terceiros, como
kiamoukube2iam.Isolamento de credenciais: um contêiner só pode recuperar credenciais para a função do IAM associada à conta de serviço à qual pertence. Um contêiner nunca tem acesso às credenciais de outro contêiner que pertence a outro pod.
Auditabilidade: o Amazon CloudTrail fornece acesso e log de eventos para ajudar a garantir a auditoria retrospectiva.
As funções vinculadas a serviço do Amazon EKS são funções do IAM exclusivas vinculadas diretamente ao Amazon EKS. As funções vinculadas a serviço são predefinidas pelo Amazon EKS e incluem todas as permissões necessárias para chamar outros serviços do AWS em nome da função. Para a função do IAM do nó do Amazon EKS, o daemon kubelet do nó do Amazon EKS chama APIs do AWS em nome do nó. Os nós obtêm permissões para essas chamadas à API de um perfil de instância do IAM e políticas associadas.
Identidades gerenciadas do cluster do AKS
Um cluster do AKS precisa de uma identidade para acessar recursos do Azure como balanceadores de carga e discos gerenciados. Essa identidade pode ser uma identidade gerenciada ou uma entidade de serviço. Por padrão, a criação de um cluster do AKS cria automaticamente uma identidade gerenciada atribuída pelo sistema. A plataforma do Azure gerencia a identidade e você não precisa provisionar nem girar segredos. Para saber mais sobre identidades gerenciadas do Microsoft Entra, confira Identidades gerenciadas para recursos do Azure.
O AKS não cria uma entidade de serviço automaticamente, portanto, se você quiser usar uma entidade de serviço, deverá criá-la. Por fim, a entidade de serviço expira e você deve renová-la para manter o cluster funcionando. O gerenciamento de entidades de serviço aumenta a complexidade, então é mais fácil usar identidades gerenciadas.
As identidades gerenciadas são essencialmente wrappers em torno de entidades de serviço que simplificam o gerenciamento. Os mesmos requisitos de permissão se aplicam a entidades de serviço e identidades gerenciadas. As identidades gerenciadas usam autenticação baseada em certificado. Cada credencial de identidade gerenciada expira em 90 dias e gira após 45 dias.
O AKS usa os tipos de identidade gerenciada atribuídos pelo sistema e pelo usuário e essas identidades são imutáveis. Quando você cria ou usa uma rede virtual do AKS, disco do Azure anexado, endereço IP estático, tabela de rotas ou identidade kubelet atribuída pelo usuário com recursos fora do grupo de recursos do nó, a CLI do Azure adiciona a atribuição de função automaticamente.
Se você usar outro método para criar o cluster do AKS, como um modelo Bicep, um modelo do Azure Resource Manager ou um módulo do Terraform, será necessário usar a ID da entidade de segurança da identidade gerenciada do cluster para realizar uma atribuição de função. A identidade do cluster do AKS precisa ter, pelo menos, função de Colaborador de Rede na sub-rede da sua rede virtual. Se você desejar definir uma função personalizada em vez de usar a função interna de Colaborador de Rede, precisará das seguintes permissões:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/read
Quando a identidade do cluster precisa acessar um recurso existente, por exemplo, quando um cluster do AKS é implantado em uma rede virtual existente, é necessário usar uma identidade gerenciada atribuída pelo usuário. Se uma identidade de painel de controle atribuída pelo sistema for usada, o provedor de recursos não poderá obter sua ID de entidade de segurança antes de criar o cluster, portanto, não será possível criar as atribuições de função adequadas antes do provisionamento de cluster.
Resumo das identidades gerenciadas
O AKS usa as seguintes identidades gerenciadas atribuídas pelo usuário para serviços internos e complementos.
| Identidade | Nome | Caso de uso | Permissões padrão | Traga sua própria identidade |
|---|---|---|---|---|
| Painel de controle | Nome do cluster AKS | Gerencia recursos de cluster, incluindo balanceadores de carga de entrada e IPs gerenciados pelo AKS, dimensionador automático de cluster e drivers do Azure Disk e da CSI de arquivos do Azure | Função de colaborador para o grupo de recursos de nó | Com suporte |
| Kubelet | Nome do cluster do AKS – agentpool | Autentica com o Registro de Contêiner do Azure | NA (para Kubernetes v1.15+) | Com suporte |
| Complemento | HTTPApplicationRouting | Gerencia os recursos de rede necessários | Função de leitor para o grupo de recursos de nó, função de Colaborador para a zona DNS | Não |
| Complemento | Gateway de aplicativo de entrada | Gerencia os recursos de rede necessários | Função de colaborador para o grupo de recursos de nó | Não |
| Complemento | omsagent | Envia as métricas do AKS para o Azure Monitor | Função de Publicador de Métricas de Monitoramento | Não |
| Complemento | Virtual-Node (ACIConnector) | Gerencia os recursos de rede necessários para Instâncias de Contêiner do Azure | Função de colaborador para o grupo de recursos de nó | Não |
Para obter mais informações, confira Usar identidade gerenciada no Serviço de Kubernetes do Azure.
ID de carga de trabalho do Microsoft Entra para Kubernetes
As cargas de trabalho do Kubernetes exigem credenciais de aplicativo do Microsoft Entra para acessar recursos protegidos pelo Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. Um desafio comum para desenvolvedores é o gerenciamento de segredos e credenciais para proteger a comunicação entre os diferentes componentes de uma solução.
A ID de Carga de Trabalho do Microsoft Entra para Kubernetes elimina a necessidade de gerenciar credenciais para acessar serviços de nuvem como o Azure Cosmos DB, o Azure Key Vault ou o Armazenamento de Blobs do Azure. Um aplicativo de carga de trabalho hospedado pelo AKS pode usar a ID de Carga de Trabalho do Microsoft Entra para acessar um serviço gerenciado do Azure usando um token de segurança do Microsoft Entra, em vez de credenciais explícitas como uma cadeia de conexão, um nome de usuário e senha ou uma chave primária.
Conforme mostrado no diagrama a seguir, o cluster do Kubernetes se torna um emissor de token de segurança que emite tokens para contas de serviço do Kubernetes. Você pode configurar esses tokens para serem confiáveis em aplicativos do Microsoft Entra. Os tokens podem ser trocados por tokens de acesso do Microsoft Entra usando os SDKs de Identidade do Azure ou a MSAL (Biblioteca de Autenticação da Microsoft).
- O agente
kubeletprojeta um token de conta de serviço para a carga de trabalho em um caminho de arquivo configurável. - A carga de trabalho do Kubernetes envia o token de conta de serviço assinado e projetado para o Microsoft Entra ID e solicita um token de acesso.
- O Microsoft Entra ID usa um documento de descoberta OIDC para verificar a confiança na identidade gerenciada definida pelo usuário ou no aplicativo registrado e validar o token de entrada.
- O Microsoft Entra ID emite um token de acesso de segurança.
- A carga de trabalho do Kubernetes acessa os recursos do Azure usando o token de acesso do Microsoft Entra.
A federação de ID de Carga de Trabalho do Microsoft Entra para Kubernetes atualmente tem suporte apenas para aplicativos do Microsoft Entra, mas o mesmo modelo tem potencial para ser estendido para identidades gerenciadas do Azure.
Para obter mais informações, automação e documentação para a ID de Carga de Trabalho do Microsoft Entra, consulte:
- Projeto de código aberto da Identidade de Carga de Trabalho do Azure.
- Federação de identidade de carga de trabalho
- Federação da ID de Carga de Trabalho do Microsoft Entra com o Kubernetes
- Federação da ID de Carga de Trabalho do Microsoft Entra com provedores de identidade OIDC externos
- Federação mínima da ID de Carga de Trabalho do Microsoft Entra
- Carga de trabalho do Microsoft Entra ID
- Início rápido da ID de Carga de Trabalho do Microsoft Entra
- Usar a ID de carga de trabalho do Microsoft Entra para Kubernetes com uma identidade gerenciada atribuída pelo usuário em um aplicativo .NET Standard
Carga de trabalho de exemplo
A carga de trabalho de exemplo executa um front-end e um serviço de back-end em um cluster do AKS. Os serviços de carga de trabalho usam a ID de Carga de Trabalho do Microsoft Entra para acessar os seguintes serviços do Azure usando tokens de segurança do Microsoft Entra:
- Cofre de Chave do Azure
- Azure Cosmos DB
- Conta de Armazenamento do Azure
- Namespace do Barramento de Serviço do Azure
Pré-requisitos
- Configure um cluster do AKS com o emissor OIDC habilitado.
- Instale o webhook de admissão de mutação.
- Crie uma conta de serviço do Kubernetes para as cargas de trabalho.
- Crie um aplicativo do Microsoft Entra, conforme mostrado no início rápido.
- Atribua funções com as permissões corretas aos aplicativos registrados do Microsoft Entra necessários.
- Estabeleça uma credencial de identidade federada entre o aplicativo do Microsoft Entra e o emissor da conta de serviço e sujeito.
- Implante o aplicativo de carga de trabalho no cluster do AKS.
Fluxo de mensagens da ID da Carga de Trabalho do Microsoft Entra
Os aplicativos do AKS obtêm tokens de segurança para sua conta de serviço do emissor OIDC do cluster do AKS. A ID de Carga de Trabalho do Microsoft Entra troca os tokens de segurança com tokens de segurança emitidos pelo Microsoft Entra ID e os aplicativos usam os tokens de segurança emitidos pelo Microsoft Entra ID para acessar os recursos do Azure.
O diagrama a seguir mostra como os aplicativos de front-end e back-end adquirem tokens de segurança do Microsoft Entra para usar os serviços de PaaS (plataforma como serviço) do Azure.
Baixe um Arquivo Visio dessa arquitetura.
- O Kubernetes emite um token para o pod quando ele é agendado em um nó, com base na especificação do pod ou da implantação.
- O pod envia o token emitido pelo OIDC para o Microsoft Entra ID para solicitar um token do Microsoft Entra para o
appIdespecífico e o recurso. - O Microsoft Entra ID verifica a confiança do aplicativo e valida o token de entrada.
- O Microsoft Entra ID emite um token de segurança:
{sub: appId, aud: requested-audience}. - O pod usa o token do Microsoft Entra para acessar o recurso de destino do Azure.
Para usar a ID de Carga de Trabalho do Microsoft Entra de ponta a ponta em um cluster do Kubernetes:
- Configure o cluster do AKS para emitir tokens e publicar um documento de descoberta OIDC a fim de permitir a validação desses tokens.
- Configure os aplicativos do Microsoft Entra para confiar nos tokens do Kubernetes.
- Os desenvolvedores configuram suas implantações para usar as contas de serviço do Kubernetes a fim de obter tokens do Kubernetes.
- A ID de Carga de Trabalho do Microsoft Entra troca os tokens do Kubernetes por tokens do Microsoft Entra.
- As cargas de trabalho de cluster do AKS usam os tokens do Microsoft Entra para acessar recursos protegidos, como o Microsoft Graph.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Paolo Salvatori | Engenheiro principal de serviço
- Martin Gjoshevski | Engenheiro sênior de serviços
Outros colaboradores:
- Laura Nicolas | Engenheira sênior de software
- Chad Kittel | Engenheiro de Software Principal
- Ed Price | Gerente sênior de programa de conteúdo
- Theano Petersen | Escritor técnico
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- AKS para profissionais do Amazon EKS
- Monitoramento e registro em log do Kubernetes
- Acesso seguro de rede ao Kubernetes
- Opções de armazenamento para um cluster do Kubernetes
- Gerenciamento de custos para Kubernetes
- Gerenciamento de nós e pool de nós do Kubernetes
- Governança de cluster
- Gerenciamento de identidade e acesso do Microsoft Entra para AWS