Acesso e identidade da carga de trabalho do Kubernetes

2025-04-17

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

Este guia explica como clusters do 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 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 AKS (Serviço de Kubernetes do Azure).

Gerenciamento de identidade e acesso do Amazon EKS

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

Funções IAM para contas de serviço

Você pode associar funções IAM a contas de serviço do Kubernetes. Essa associação fornece permissões 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 de 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. Essa 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 parceiro, como o kube2iam. Para obter mais informações, consulte Funções IAM para contas de serviço.
Isolamento de credenciais: Cada contêiner dentro de um pod só pode recuperar as credenciais para a função IAM associada à respectiva 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.
Capacidade de auditoria: O Amazon EKS usa o AWS CloudTrail para fornecer acesso e registro em log de eventos, o que facilita a auditoria retrospectiva e a conformidade.

Para obter mais informações, consulte Funções 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 IAM exclusivas que vinculam diretamente ao Amazon EKS. Essas funções predefinidas incluem as permissões necessárias para chamar serviços AWS em nome da função associada. A principal função vinculada ao serviço do Amazon EKS é Função IAM do nó Amazon EKS.

O daemon do nó kubelet do Amazon EKS usa a função IAM do nó do Amazon EKS para fazer chamadas à 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 à API. Esta configuração simplifica o gerenciamento das funções do IAM para os nós no cluster EKS.

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

Mais informações sobre gerenciamento de identidade e acesso

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

Autorização do RBAC do Amazon EKS: o Amazon EKS dá suporte ao RBAC (controle de acesso baseado em função). 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 identidade para serviços 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 do cluster do AKS

Os clusters do AKS exigem uma identidade do 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 do AKS a outros serviços do Azure.

Tipos de identidade gerenciada

Os desenvolvedores geralmente lutam com o gerenciamento de segredos, credenciais, certificados e chaves que ajudam a proteger a comunicação entre os serviços. As identidades gerenciadas eliminam a necessidade de você gerenciar essas credenciais. Você pode usar identidades gerenciadas para autenticar seu cluster do 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 pelo sistema:
- Um tipo especial de entidade de serviço é criado no Microsoft Entra ID para a identidade. A entidade de serviço é vinculada ao ciclo de vida desse recurso do Azure. Quando o recurso do Azure é excluído, o Azure exclui automaticamente o principal 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 da entidade de serviço atribuída pelo sistema é idêntico ao nome do recurso do Azure para o qual ela foi criada.
Atribuída 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. O principal de serviço é gerenciado separadamente dos recursos que o utilizam.
- Diversos recursos podem usá-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 do cluster do AKS.

Para obter mais informações, confira Tipos de identidade gerenciada.

Identidades gerenciadas no AKS

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

Uma identidade gerenciada atribuída pelo sistema está associada a um único recurso do Azure, como um cluster do 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 do cluster do AKS. Ele persiste separadamente do cluster e vários recursos do Azure podem usá-lo.
Uma identidade gerenciada de 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 de kubelet atribuída pelo usuário no grupo de recursos do nó.

Configurar identidades gerenciadas para clusters do AKS

Quando você implanta um cluster do AKS, uma identidade gerenciada atribuída pelo 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 que ela acesse segredos em um cofre de chaves do Azure. Use essa abordagem para autorizar facilmente o acesso ao cluster sem gerenciar credenciais.

Benefícios e gerenciamento de identidades gerenciadas no AKS

Quando você usa identidades gerenciadas no AKS, não precisa provisionar nem trocar segredos. 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 do AKS que usa uma identidade gerenciada, poderá atualizar o cluster para um tipo diferente de identidade gerenciada. No entanto, essa atualização pode apresentar um atraso enquanto os componentes do painel de controle mudam para a nova identidade. Esse processo pode levar 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 internos e complementos.

Identidade gerenciada	Caso de uso	Permissões padrão
Plano de controle (atribuído pelo sistema)	Os componentes do plano de controle do AKS usam essa identidade para gerenciar recursos de cluster. Esses recursos incluem balanceadores de carga de entrada, endereços IP públicos gerenciados pelo AKS, o dimensionador automático de cluster e drivers CSI de disco, arquivo e blob do Azure.	Função de colaborador para o grupo de recursos de nó
Kubelet (atribuído pelo usuário)	Autenticar 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 do AzureCNI, Azure Policy e Calico)	Esses complementos não exigem uma identidade.	Não aplicável
Roteamento de aplicativo	Gerencia certificados do Azure DNS e do Azure Key Vault.	Função de usuário de Segredos do Key Vault para o Key Vault, função de colaborador de zona DNS para zonas DNS, função de colaborador de zona DNS privada para zonas DNS privadas
Gateway de aplicativo de entrada	Gerencia os recursos de rede necessários.	Função de colaborador para o grupo de recursos de nó
Agente da suíte de gerenciamento de operações (OMS)	Envia métricas do 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 de nó
Análise de custo	Coleta dados de alocação de custos.	Não aplicável
Identidade da carga de trabalho (ID da carga de trabalho)	Permite que os aplicativos acessem com segurança os recursos de nuvem com a ID da carga de trabalho.	Não aplicável

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

ID de carga de trabalho para Kubernetes

A ID da carga de trabalho se integra ao Kubernetes para habilitar cargas de trabalho implantadas por cluster do AKS para acessar recursos protegidos do Microsoft Entra, como o Key Vault e o Microsoft Graph. O ID de carga de trabalho usa recursos nativos do Kubernetes para federar-se com provedores de identidade externos. Para obter mais informações, consulte Usar ID de carga de trabalho com o AKS.

Para usar a 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 de carga de trabalho funciona bem com as bibliotecas de clientes dos serviços de identidade do Azure ou com a coleção de bibliotecas de autenticação da Microsoft. Você deve registrar o aplicativo na ID do Microsoft Entra para gerenciar permissões e controle de acesso para as identidades.

Para usar totalmente a identidade de carga de trabalho em um cluster Kubernetes, configure o cluster AKS para emitir tokens e publicar um documento de descoberta OIDC (OpenID Connect) para validar tokens. Para obter mais informações, consulte Criar um provedor OIDC no AKS.

Você também precisa configurar os aplicativos do Microsoft Entra para confiar nos tokens do 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 por tokens do Microsoft Entra. As cargas de trabalho de cluster do AKS podem usar esses tokens do Microsoft Entra para acessar com segurança os recursos protegidos no Azure.

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

O agente kubelet 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.
A ID do Microsoft Entra 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 a ID da carga de trabalho, consulte os seguintes recursos:

Carga de trabalho de exemplo

A carga de trabalho de exemplo a seguir é executada em um cluster do AKS e consiste em um front-end e um serviço de back-end. Esses serviços usam a ID de carga de trabalho para acessar os serviços do Azure, incluindo Key Vault, Azure Cosmos DB, contas de Armazenamento do Azure e namespaces do Barramento de Serviço do Azure. Para configurar esta carga de trabalho de exemplo, faça os seguintes pré-requisitos:

Configure um cluster do AKS que tenha o emissor do OIDC e a identidade de 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 do Microsoft Entra ou um aplicativo registrado.
Estabeleça uma credencial de identidade federada entre a identidade gerenciada do Microsoft Entra ou o aplicativo registrado e a conta de serviço de carga de trabalho.
Atribua as funções necessárias com permissões apropriadas à identidade gerenciada do Microsoft Entra ou ao aplicativo registrado.
Implantar a carga de trabalho e confirmar a autenticação utilizando a identidade correspondente à carga de trabalho.

Fluxo de mensagens da ID de carga de trabalho

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

Baixe um arquivo do Visio dessa arquitetura.

O Kubernetes emite um token para o pod quando o pod é agendado em um nó. Esse token é baseado nas especificações de pod ou implantação.
O pod envia o token emitido pelo OIDC para o Microsoft Entra ID, solicitando um token do Microsoft Entra para o recurso específico appId.
A ID do Microsoft Entra 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 do Microsoft Entra para acessar o recurso de destino do Azure.

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

Configure o cluster do AKS para emitir tokens e publicar um documento de descoberta OIDC para 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 da carga de trabalho 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.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

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 – Padrões e Práticas do Azure
Ed Price | Gerente sênior de programa de conteúdo
Theano Petersen | Escritor técnico

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.