Identidade e acesso à carga de trabalho do Kubernetes

2025-06-05

Este artigo descreve como o Amazon Elastic Kubernetes Service (EKS) e o Azure Kubernetes Service (AKS) fornecem identidade para cargas de trabalho do Kubernetes acessarem serviços de plataforma de nuvem. Para obter uma comparação detalhada do Amazon Web Services (AWS) Identity and Access Management (IAM) e do Microsoft Entra ID, consulte os seguintes recursos:

Este guia explica como clusters AKS, serviços internos e complementos usam identidades gerenciadas para acessar recursos do Azure, como balanceadores de carga e discos gerenciados. Ele também demonstra como usar o ID de Carga de Trabalho do Microsoft Entra para que as cargas de trabalho do AKS possam acessar 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 os profissionais familiarizados com o Amazon EKS a entender o Serviço Kubernetes do Azure (AKS).

Gerenciamento de identidade e acesso do Amazon EKS

O Amazon EKS oferece opções nativas para gerenciar a identidade e o acesso em pods do Kubernetes. Essas opções incluem funções do IAM para contas de serviço e funções vinculadas ao serviço do Amazon EKS.

Funções do IAM para contas de serviço

Você pode associar funções do IAM a contas de serviço do Kubernetes. Essa associação fornece permissões da AWS para os contêineres em qualquer pod que use a conta de serviço. As funções do IAM para contas de serviço oferecem os seguintes benefícios:

Privilégio mínimo: Você pode atribuir permissões específicas do IAM a uma conta de serviço, o que garante que apenas os pods que usam essa conta de serviço tenham acesso a essas permissões. Esta configuração elimina a necessidade de conceder permissões estendidas à função IAM do nó para todos os pods em um nó. Essa abordagem fornece segurança aprimorada e controle granular e elimina a necessidade de soluções de parceiros, como o kube2iam. Para obter mais informações, consulte Funções do IAM para contas de serviço.
Isolamento de credenciais: Cada contêiner dentro de um pod só pode recuperar as credenciais da função do IAM associada à sua respetiva conta de serviço. Esse isolamento garante que um contêiner não possa acessar credenciais que pertencem a outro contêiner em um pod diferente.
Auditabilidade: O Amazon EKS usa o AWS CloudTrail para fornecer acesso e registro de eventos, o que facilita a auditoria retrospetiva e a conformidade.

Para obter mais informações, consulte Funções do IAM para contas de serviço.

Funções vinculadas ao serviço do Amazon EKS

As funções vinculadas ao serviço do Amazon EKS são funções exclusivas do IAM que se vinculam diretamente ao Amazon EKS. Essas funções predefinidas incluem as permissões necessárias para chamar serviços da AWS em nome da função associada. A principal função associada ao serviço Amazon EKS é a função IAM do nó do Amazon EKS.

O daemon de kubelet do nó do Amazon EKS utiliza a função IAM do nó do Amazon EKS para realizar chamadas de API para serviços da AWS em nome do nó. O perfil da instância do IAM e as políticas associadas fornecem permissões para essas chamadas de API. Esta configuração simplifica o gerenciamento de perfis do IAM nos nós dentro do cluster EKS.

Para obter mais informações, consulte Usar funções vinculadas a serviços para o Amazon EKS.

Mais informações sobre gerenciamento de identidade e acesso

Além das funções do IAM para contas de serviço e funções vinculadas ao serviço do Amazon EKS, outros aspetos essenciais do gerenciamento de identidade e acesso no Amazon EKS incluem:

Autorização do Amazon EKS RBAC: o Amazon EKS oferece suporte ao controle de acesso baseado em função (RBAC). Use esse recurso para definir permissões refinadas para recursos do Kubernetes em seu cluster.
AWS IAM: O IAM fornece uma solução abrangente de gerenciamento de identidades para serviços da AWS, incluindo o EKS. Use o IAM para criar e gerenciar usuários, grupos e funções para controlar o acesso aos recursos do EKS.
Grupos de segurança do Amazon EKS: use o Amazon EKS para aplicar regras de grupo de segurança a pods executados em seu cluster. Use esse recurso para controlar o tráfego de entrada e saída.

Para obter mais informações, consulte O que é o Amazon EKS?.

Identidades gerenciadas pelo cluster AKS

Os clusters AKS exigem uma identidade Microsoft Entra para acessar recursos do Azure, como balanceadores de carga e discos gerenciados. Recomendamos que você use identidades gerenciadas para recursos do Azure para autorizar o acesso de um cluster AKS a outros serviços do Azure.

Tipos de identidade gerenciados

Os desenvolvedores geralmente lutam com o gerenciamento de segredos, credenciais, certificados e chaves que ajudam a proteger a comunicação entre serviços. As identidades gerenciadas eliminam a necessidade de gerenciar essas credenciais. Você pode usar identidades gerenciadas para autenticar seu cluster AKS sem gerenciar credenciais ou incluí-las em seu código. Atribua uma função RBAC do Azure a uma identidade para conceder as permissões de identidade a recursos específicos no Azure.

Dois tipos de identidades gerenciadas incluem:

Atribuído pelo sistema. Você pode usar alguns recursos do Azure, como máquinas virtuais, para habilitar uma identidade gerenciada diretamente no recurso. Quando você habilita uma identidade gerenciada atribuída ao sistema:
- Um tipo especial de entidade de serviço é criado no Microsoft Entra ID para a identidade. O principal do serviço é ligado ao ciclo de vida desse recurso do Azure. Quando o recurso do Azure é excluído, o Azure exclui automaticamente a entidade de serviço.
- Somente esse recurso do Azure pode usar a identidade para solicitar tokens do Microsoft Entra ID.
- Você autoriza a identidade gerenciada a ter acesso a um ou mais serviços.
- O nome do principal de serviço atribuído ao sistema é o mesmo que o nome do recurso Azure para o qual é criado.
Atribuído pelo usuário. Você pode criar uma identidade gerenciada como um recurso autônomo do Azure. Você pode criar uma identidade gerenciada atribuída pelo usuário e atribuí-la a um ou mais recursos do Azure. Quando você habilita uma identidade gerenciada atribuída pelo usuário:
- Um tipo especial de entidade de serviço é criado no Microsoft Entra ID para a identidade. A entidade de serviço é gerenciada separadamente dos recursos que a utilizam.
- Vários recursos podem utilizá-lo.
- Você autoriza a identidade gerenciada a ter acesso a um ou mais serviços.

Você pode usar qualquer tipo de identidade gerenciada para autorizar o acesso aos recursos do Azure a partir do seu cluster AKS.

Para obter mais informações, consulte Tipos de identidade gerenciados.

Identidades gerenciadas no AKS

Você pode usar os seguintes tipos de identidades gerenciadas com um cluster AKS:

Uma identidade gerenciada atribuída ao sistema está associada a um único recurso do Azure, como um cluster AKS. Ele existe apenas para o ciclo de vida do cluster.
Uma identidade gerenciada atribuída pelo usuário é um recurso autônomo do Azure que você pode usar para autorizar o acesso a outros serviços do Azure a partir do seu cluster AKS. Ele persiste separadamente do cluster e vários recursos do Azure podem usá-lo.
Uma identidade gerenciada kubelet pré-criada é uma identidade opcional atribuída pelo usuário que o kubelet pode usar para acessar outros recursos no Azure. Se nenhuma identidade gerenciada atribuída pelo usuário for especificada para o kubelet, o AKS criará uma identidade kubelet atribuída pelo usuário no grupo de recursos do nó.

Configurar identidades gerenciadas para clusters AKS

Quando você implanta um cluster AKS, uma identidade gerenciada atribuída ao sistema é criada automaticamente. Você também pode criar o cluster com uma identidade gerenciada atribuída pelo usuário. O cluster usa a identidade gerenciada para solicitar tokens do Microsoft Entra ID. Os tokens autorizam o acesso a outros recursos executados no Azure.

Ao atribuir uma função RBAC do Azure à identidade gerenciada, você pode conceder permissões de cluster para acessar recursos específicos. Por exemplo, você pode atribuir à identidade gerenciada uma função RBAC do Azure que permite acessar segredos em um cofre de chaves do Azure. Use essa abordagem para autorizar facilmente o acesso ao cluster sem gerenciar credenciais.

Benefícios e gestão de identidades geridas no AKS

Quando se utilizam identidades geridas no AKS, não é necessário provisionar ou alterar senhas. O Azure gerencia as credenciais da identidade. Portanto, você pode autorizar o acesso de seus aplicativos sem gerenciar segredos extras.

Se você já tiver um cluster AKS que usa uma identidade gerenciada, poderá atualizá-lo para um tipo diferente de identidade gerenciada. No entanto, esta atualização pode introduzir um atraso enquanto os componentes do plano de controle mudam para a nova identidade. Este processo pode demorar várias horas. Durante esse tempo, os componentes do plano de controle continuam a usar a identidade antiga até que seu token expire.

Tipos de identidades gerenciadas no AKS

O AKS usa diferentes tipos de identidades gerenciadas para habilitar vários serviços e complementos integrados.

Identidade gerenciada	Caso de uso	Permissões padrão
Plano de controlo (atribuído pelo sistema)	Os componentes do plano de controle AKS usam essa identidade para gerenciar recursos de cluster. Esses recursos incluem balanceadores de carga de entrada, endereços IP públicos geridos pelo AKS, o autoescalador do cluster e os drivers CSI de disco, ficheiro e blob do Azure.	Função de colaborador para o grupo de recursos do nó
Kubelet (atribuído pelo usuário)	Autentique-se com o Registro de Contêiner do Azure.	N/A (para Kubernetes versão 1.15 e posterior)
Identidades de complemento (AzureNPM, monitoramento de rede AzureCNI, Azure Policy e Calico)	Esses complementos não exigem uma identidade.	N/A
Roteamento de aplicativos	Gerencia o DNS do Azure e os certificados do Azure Key Vault.	Segredos do Cofre da Chave Função de utilizador para o Cofre da Chave, função de Colaborador da Zona DNS para zonas DNS, função de Colaborador da Zona DNS Privada para zonas DNS privadas
Gateway de aplicativo de ingresso	Gerencia os recursos de rede necessários.	Função de colaborador para o grupo de recursos do nó
Agente do Operations Management Suite (OMS)	Envia métricas AKS para o Azure Monitor.	Função de Publicador de Métricas de Monitoramento
Nó virtual (conector de Instâncias de Contêiner do Azure)	Gerencia os recursos de rede necessários para instâncias de contêiner.	Função de colaborador para o grupo de recursos do nó
Análise de custos	Reúne dados de alocação de custos.	N/A
Identidade da carga de trabalho (ID da carga de trabalho)	Permite que os aplicativos acessem com segurança os recursos da nuvem com o ID da carga de trabalho.	N/A

Para obter mais informações, consulte Usar uma identidade gerenciada no AKS.

ID de trabalho para Kubernetes

O ID da carga de trabalho integra-se ao Kubernetes para permitir que cargas de trabalho implantadas em cluster AKS acessem recursos protegidos do Microsoft Entra, como o Cofre da Chave e o Microsoft Graph. O identificador de carga de trabalho usa capacidades nativas do Kubernetes para integrar-se com provedores de identidade externos. Para obter mais informações, consulte Usar ID de carga de trabalho com AKS.

Para usar o ID da carga de trabalho, configure uma conta de serviço no Kubernetes. Os pods usam essa conta de serviço para autenticar e acessar recursos do Azure com segurança. A ID da carga de trabalho funciona bem com as bibliotecas de cliente dos serviços de identidade do Azure ou com a coleção da Biblioteca de Autenticação da Microsoft. Você deve registrar o aplicativo no Microsoft Entra ID para gerenciar permissões e controle de acesso para as identidades.

Para utilizar completamente a Identidade de Carga de Trabalho num cluster Kubernetes, configure o cluster AKS para emitir tokens e publicar um documento de descoberta do OpenID Connect (OIDC) para validação de token. Para obter mais informações, consulte Criar um provedor OIDC no AKS.

Você também precisa configurar os aplicativos Microsoft Entra para confiar nos tokens Kubernetes. Os desenvolvedores podem configurar suas implantações para usar contas de serviço do Kubernetes para obter tokens. A ID de carga de trabalho troca os tokens pelos tokens do Microsoft Entra. As cargas de trabalho de cluster AKS podem usar esses tokens do Microsoft Entra para acessar recursos protegidos com segurança no Azure.

O diagrama a seguir mostra como um cluster 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 Microsoft Entra. Os tokens podem ser trocados por tokens de acesso do Microsoft Entra por meio dos SDKs de serviços de identidade do Azure ou da Biblioteca de Autenticação da Microsoft.

O kubelet agente projeta 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 projetado e assinado 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 por meio do token de acesso do Microsoft Entra.

Para obter mais informações sobre o ID da carga de trabalho, consulte os seguintes recursos:

Exemplo de carga de trabalho

O exemplo de carga de trabalho a seguir é executado em um cluster AKS e consiste em um serviço front-end e um serviço back-end. Esses serviços usam a ID da Carga de Trabalho para acessar os serviços do Azure, incluindo o Cofre da Chave, o Azure Cosmos DB, as contas de Armazenamento do Azure e os namespaces do Barramento de Serviço do Azure. Para configurar este exemplo de carga de trabalho, faça os seguintes pré-requisitos:

Configure um cluster AKS que tenha o emissor OIDC e a identidade da carga de trabalho habilitada.
Crie uma conta de serviço do Kubernetes no namespace da carga de trabalho.
Crie uma identidade gerenciada atribuída pelo usuário ou um aplicativo registrado do Microsoft Entra.
Estabeleça uma credencial de identidade federada entre a identidade gerenciada ou o aplicativo registrado do Microsoft Entra e a conta de serviço de carga de trabalho.
Atribua as funções necessárias com as permissões apropriadas à identidade gerenciada ou ao aplicativo registrado do Microsoft Entra.
Implante a carga de trabalho e verifique a autenticação com a identidade de trabalho.

Fluxo de mensagens de identificação da carga de trabalho

Neste exemplo de carga de trabalho, os aplicativos front-end e back-end adquirem tokens de segurança do Microsoft Entra para acessar soluções de plataforma como serviço (PaaS) do Azure. O diagrama a seguir mostra o fluxo de mensagens.

Descarregue um ficheiro Visio desta arquitetura.

O Kubernetes emite um token para o pod quando ele é agendado em um nó. Esse token é baseado nas especificações 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 appId específico e recurso.
O Microsoft Entra ID verifica a confiança no 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 Microsoft Entra para acessar o recurso do Azure de destino.

Para usar o ID da carga de trabalho de ponta a ponta em um cluster Kubernetes:

Configure o cluster AKS para emitir tokens e publicar um documento de descoberta OIDC para permitir a validação desses tokens.
Configure os aplicativos Microsoft Entra para confiar nos tokens do Kubernetes.
Os desenvolvedores configuram suas implantações para usar as contas de serviço do Kubernetes para obter tokens do Kubernetes.
O ID da carga de trabalho troca os tokens do Kubernetes por tokens do Microsoft Entra.
As cargas de trabalho de cluster AKS usam os tokens do Microsoft Entra para acessar recursos protegidos, como o Microsoft Graph.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

Paolo Salvatori | Engenheiro de Serviço Principal
Martin Gjoshevski | Engenheiro de Serviços Sénior

Outros contribuidores:

Laura Nicolas | Engenheira de Software Sénior
Chad Kittel | Engenheiro Principal de Software - Azure Patterns & Practices
Ed Price | Gerente de Programa de Conteúdo Senior
Theano Petersen | Redator Técnico

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.