Identidade e acesso à carga de trabalho do Kubernetes

Este artigo descreve como o Amazon Elastic Kubernetes Service (Amazon 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:

• Gerenciamento de identidades e acesso do Microsoft Entra para AWS
• Mapeamento de conceitos do AWS IAM para conceitos semelhantes no Azure

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. O artigo 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.

Gerenciamento de identidade e acesso do Amazon EKS

O Amazon Elastic Kubernetes Service (EKS) fornece opções nativas para gerenciar o gerenciamento de identidade e 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

As funções do IAM para contas de serviço permitem 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 utilize a conta de serviço. Os benefícios do uso de funções do IAM para contas de serviço são os seguintes:

• de privilégios mínimos: você pode atribuir permissões específicas do IAM a uma conta de serviço, garantindo que apenas os pods que usam essa conta de serviço tenham acesso a essas permissões. Isso elimina a necessidade de conceder permissões estendidas à função do IAM do nó para todos os pods em um nó, fornecendo uma abordagem mais segura e granular. Além disso, esse recurso elimina a necessidade de soluções de terceiros como kube2iam. Para obter mais informações, consulte funções do IAM para contas de serviço.

• de 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 pertencentes a outro contêiner em um pod diferente.

• de auditabilidade: o Amazon EKS aproveita do Amazon CloudTrail para fornecer acesso e registro de eventos, facilitando a auditoria retrospetiva e a conformidade.

Para obter mais informações sobre funções do IAM para contas de serviço, consulte a documentação oficial .

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 diretamente vinculadas ao Amazon EKS. Essas funções predefinidas incluem todas as permissões necessárias para chamar os serviços da AWS em nome da função associada. A principal função vinculada ao serviço para o Amazon EKS é a função do IAM do nó do Amazon EKS.

O daemon de kubelet do nó do Amazon EKS utiliza a função do IAM do nó do Amazon EKS para fazer 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. Essa configuração simplifica o gerenciamento de funções do IAM para nós dentro do cluster EKS.

Para saber mais sobre as funções vinculadas ao serviço Amazon EKS, visite o de documentação oficial .

Informações adicionais

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

1. de autorização RBAC do Amazon EKS: o Amazon EKS oferece suporte ao RBAC (controle de acesso baseado em função), permitindo que você defina permissões refinadas para recursos do Kubernetes em seu cluster.

2. AWS Identity and Access Management (IAM): o IAM fornece uma solução abrangente de gerenciamento de identidades para serviços da AWS, incluindo EKS. Ele permite que você crie e gerencie usuários, grupos e funções para controlar o acesso aos seus recursos EKS.

3. de grupos de segurança do Amazon EKS: o Amazon EKS permite que você aplique regras de grupo de segurança a pods em execução no cluster para controlar o tráfego de entrada e saída.

Para obter mais detalhes sobre o gerenciamento de identidade e acesso no Amazon EKS, consulte a documentação oficial do Amazon EKS .

Identidades gerenciadas pelo cluster AKS

Os clusters do Serviço Kubernetes do Azure (AKS) exigem um de identidade do Microsoft Entra para acessar recursos do Azure, como balanceadores de carga e discos gerenciados. As identidades gerenciadas para recursos do Azure são a maneira recomendada de autorizar o acesso de um cluster AKS a outros serviços do Azure.

O que são identidades gerenciadas?

Um desafio comum para os desenvolvedores é o gerenciamento de segredos, credenciais, certificados e chaves usadas para proteger a comunicação entre serviços. As identidades gerenciadas eliminar a necessidade de os desenvolvedores gerenciarem essas credenciais. As identidades gerenciadas permitem que você autentique seu cluster AKS sem gerenciar credenciais ou incluí-las em seu código. Com identidades gerenciadas, você atribui uma função de controle de acesso baseado em função do Azure (Azure RBAC) à identidade, concedendo-lhe permissões para recursos específicos no Azure.

Aqui estão dois tipos de identidades gerenciadas:

• atribuído pelo sistema . Alguns recursos do Azure, como máquinas virtuais, permitem que você habilite uma identidade gerenciada diretamente no recurso. Quando você habilita uma identidade gerenciada atribuída ao sistema:

  • Uma entidade de serviço de um tipo especial é criada no Microsoft Entra ID para a identidade. A entidade de serviço está vinculada ao ciclo de vida desse recurso do Azure. Quando o recurso do Azure é excluído, o Azure exclui automaticamente a entidade de serviço para você.
  • Por design, apenas esse recurso do Azure pode usar essa 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 ao sistema é sempre o mesmo que o nome do recurso do Azure para o qual foi criada. Para um slot de implantação, o nome de sua identidade atribuída ao sistema é <app-name>/slots/<slot-name>.

• atribuído pelo usuário . Você também pode criar uma identidade gerenciada como um recurso autônomo do Azure. Você pode criar um de identidade gerenciado atribuído pelo usuário e atribuí-lo a um ou mais Recursos do Azure. Quando você habilita uma identidade gerenciada atribuída pelo usuário:

  • Uma entidade de serviço de um tipo especial é criada no Microsoft Entra ID para a identidade. A entidade de serviço é gerenciada separadamente dos recursos que a utilizam.
  • As identidades atribuídas pelo usuário podem ser usadas por vários recursos.
  • Você autoriza a identidade gerenciada a ter acesso a um ou mais serviços.

Para obter mais informações sobre as diferenças entre os dois tipos de identidades gerenciadas, consulte Tipos de identidade gerenciados.

Identidades gerenciadas no Serviço Kubernetes do Azure (AKS)

Esses dois tipos de identidades gerenciadas são semelhantes, pois você pode usar qualquer tipo para autorizar o acesso aos recursos do Azure a partir do cluster AKS. A principal diferença entre eles é que uma identidade gerenciada atribuída ao sistema está associada a um único recurso do Azure, como um cluster AKS, enquanto uma identidade gerenciada atribuída pelo usuário é ela própria um recurso autônomo do Azure. Para obter mais detalhes sobre as diferenças entre os tipos de identidades gerenciadas, consulte Tipos de identidade gerenciados em Identidades gerenciadas para recursos do Azure.

Há três tipos de identidades gerenciadas que você pode usar com um cluster AKS:

1. Identidade gerenciada atribuída ao sistema: Esse tipo de identidade gerenciada está associado a um único recurso do Azure, como um cluster AKS. Ele existe apenas para o ciclo de vida do cluster.

2. Identidade gerenciada atribuída pelo usuário: 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 pode ser usado por vários recursos do Azure.

3. Identidade gerenciada kubelet pré-criada: Esta é uma identidade opcional atribuída pelo usuário que pode ser usada pelo kubelet 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ó.

Como o AKS usa identidades gerenciadas?

Quando você implanta um cluster AKS, uma de identidade gerenciada atribuída ao sistema é criada automaticamente para você. Você também pode optar por criar o cluster com um identidade gerenciada atribuída pelo usuário. O cluster usa essa identidade gerenciada para solicitar tokens do Microsoft Entra ID, que são usados para autorizar o acesso a outros recursos em execução 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. Dessa forma, você pode facilmente autorizar o acesso ao seu cluster sem gerenciar credenciais.

Usando identidades gerenciadas no AKS

Quando você usa identidades gerenciadas no AKS, não precisa provisionar ou girar nenhum segredo. O Azure gerencia as credenciais da identidade para você. Isso permite que você autorize o acesso de seus aplicativos sem gerenciar segredos adicionais.

Se você já tiver um cluster AKS que esteja usando uma identidade gerenciada, poderá atualizá-lo para um tipo diferente de identidade gerenciada. No entanto, tenha em atenção que pode haver um atraso enquanto os componentes do plano de controlo mudam para a nova identidade. Esse processo pode levar várias horas e, durante esse tempo, os componentes do plano de controle continuarão a usar a identidade antiga até que seu token expire.

Resumo das identidades gerenciadas usadas pelo AKS

O AKS usa diferentes tipos de identidades gerenciadas para habilitar vários serviços e complementos integrados. Aqui está um resumo das identidades gerenciadas usadas pelo AKS:

Para obter mais informações sobre identidades gerenciadas no AKS, consulte Usar uma identidade gerenciada no Serviço Kubernetes do Azure.

ID de carga de trabalho do Microsoft Entra para Kubernetes

de ID de Carga de Trabalho do Microsoft Entra integra-se ao Kubernetes para permitir que cargas de trabalho implantadas em um cluster AKS acessem recursos protegidos do Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. Ele usa os recursos nativos do Kubernetes para federar com provedores de identidade externos. Para obter mais informações, consulte Usar a ID de Carga de Trabalho do Microsoft Entra com o Serviço Kubernetes do Azure.

Para usar o ID de carga de trabalho do Microsoft Entra, você precisa configurar uma conta de serviço no Kubernetes. Essa conta de serviço é usada por pods para autenticar e acessar recursos do Azure com segurança. A ID de Carga de Trabalho do Microsoft Entra funciona bem com bibliotecas de cliente do Azure Identity ou a coleção Microsoft Authentication Library (MSAL), juntamente com o registro do aplicativo.

Para aproveitar totalmente o ID de carga de trabalho do Microsoft Entra em um cluster Kubernetes, você precisa configurar o cluster AKS para emitir tokens e publicar um documento de descoberta OIDC para validação de token. Para obter mais informações, consulte Criar um provedor OpenID Connect no Serviço Kubernetes do Azure.

Você também precisa configurar os aplicativos Microsoft Entra para confiar nos tokens Kubernetes. Os desenvolvedores podem então configurar suas implantações para usar contas de serviço do Kubernetes para obter tokens, que são trocados por tokens do Microsoft Entra pelo ID de carga de trabalho do Microsoft Entra. Finalmente, as cargas de trabalho de cluster AKS podem usar esses tokens do Microsoft Entra para acessar com segurança recursos protegidos no Azure.

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 Microsoft Entra. Os tokens podem ser trocados por tokens de acesso do Microsoft Entra usando os SDKs de Identidade do Azure ou a Biblioteca de Autenticação da Microsoft (MSAL).

1. O kubelet agente projeta um token de conta de serviço para a carga de trabalho em um caminho de arquivo configurável.
2. 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.
3. 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.
4. O Microsoft Entra ID emite um token de acesso de segurança.
5. A carga de trabalho do Kubernetes acessa recursos do Azure usando o token de acesso do Microsoft Entra.

Para obter mais informações, documentação e automação relacionadas ao ID de carga de trabalho do Microsoft Entra, consulte os seguintes recursos:

• de projeto de código aberto do Azure Workload Identity
• Federação de identidades de carga de trabalho
• Federação do Microsoft Entra Workload ID com Kubernetes
• Federação de ID de carga de trabalho do Microsoft Entra com provedores de identidade OIDC externos
• Federação mínima de ID de carga de trabalho do Microsoft Entra
• documentação do Microsoft Entra Workload ID
• Início rápido do Microsoft Entra Workload ID
• Exemplo: Use o ID de carga de trabalho do Microsoft Entra para Kubernetes com uma identidade gerenciada atribuída pelo usuário em um aplicativo .NET Standard

Exemplo de carga de trabalho

Um exemplo de carga de trabalho em execução em um cluster AKS consiste em um serviço de frontend e back-end. Esses serviços usam a ID de Carga de Trabalho do Microsoft Entra para acessar os serviços do Azure, incluindo o Azure Key Vault, o Azure Cosmos DB, a conta de Armazenamento do Azure e o namespace do Azure Service Bus. Para configurar este exemplo de carga de trabalho, os seguintes pré-requisitos devem ser atendidos:

1. Configure um cluster AKS com emissor OIDC ativado.
2. Instale o webhook de admissão mutante.
3. Crie uma conta de serviço Kubernetes para as cargas de trabalho.
4. Crie um aplicativo Microsoft Entra conforme mostrado no guia de início rápido .
5. Atribua as funções necessárias com as permissões apropriadas aos aplicativos registrados do Microsoft Entra.
6. Estabeleça uma credencial de identidade federada entre o aplicativo Microsoft Entra e o emissor e o assunto da conta de serviço.
7. Implante o aplicativo de carga de trabalho no cluster AKS.

Fluxo de mensagens do Microsoft Entra Workload ID

Neste exemplo de carga de trabalho, os aplicativos frontend e backend adquirem tokens de segurança do Microsoft Entra para acessar os serviços PaaS (Plataforma Azure as a Service). O diagrama a seguir ilustra o fluxo de mensagens:

Transfira um ficheiro do Visio desta arquitetura.

1. 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.
2. O pod envia o token emitido pelo OIDC para o Microsoft Entra ID para solicitar um token do Microsoft Entra para o específico appId e o recurso.
3. O Microsoft Entra ID verifica a confiança no aplicativo e valida o token de entrada.
4. O Microsoft Entra ID emite um token de segurança: {sub: appId, aud: requested-audience}.
5. O pod usa o token Microsoft Entra para acessar o recurso do Azure de destino.

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

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

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Paolo Salvatori - Brasil | Engenheiro de Serviços Principal
• Martin Gjoshevski - Brasil | Engenheiro de Serviços Sênior

Outros contribuidores:

• Laura Nicolas - Brasil | Engenheiro de Software Sênior
• Chade Kittel - Brasil | Engenheiro de Software Principal
• Ed Preço | Gerente de Programa de Conteúdo Sênior
• Theano Petersen - Brasil | Redator Técnico

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• AKS para profissionais do Amazon EKS
• Monitoramento e registro em log do Kubernetes
• Acesso seguro à rede do Kubernetes
• Opções de armazenamento para um cluster Kubernetes
• Gestão de custos para Kubernetes
• Gerenciamento de nós e pool de nós do Kubernetes
• Governança de cluster
• Gerenciamento de identidades e acesso do Microsoft Entra para AWS

Recursos relacionados

• Utilizar um principal do serviço com o Azure Kubernetes Service (AKS)
• Usar uma identidade gerenciada no Serviço Kubernetes do Azure
• Implementar o Serviço Kubernetes do Azure (AKS)
• Gerenciar identidade e acesso no Microsoft Entra ID