Acesso e identidade da carga de trabalho do Kubernetes

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.

Gerenciamento de Identidades 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 IAM para contas de serviço e funções vinculadas ao serviço do Amazon EKS.

Funções IAM para contas de serviço

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

• Privilégio mínimo: você pode atribuir permissões específicas de IAM a uma conta de serviço, garantindo que somente 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 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 IAM para contas de serviço.

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

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

Para obter mais informações sobre funções 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 IAM exclusivas diretamente vinculadas ao Amazon EKS. Essas funções predefinidas incluem todas 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 é a função IAM do nó Amazon EKS.

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

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

Informações adicionais

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

1. de Autorização rbac do Amazon EKS: o Amazon EKS dá 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. IAM (Gerenciamento de Identidade e Acesso) do AWS: o IAM fornece uma solução abrangente de gerenciamento de identidades para serviços AWS, incluindo o EKS. Ele permite que você crie e gerencie usuários, grupos e funções para controlar o acesso aos recursos do EKS.

3. Grupos de Segurança do Amazon EKS: o Amazon EKS permite aplicar regras de grupo de segurança a pods em execução em seu cluster para controlar o tráfego de entrada e saída.

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

Identidades gerenciadas do cluster do AKS

Os clusters do AKS (Serviço de Kubernetes do Azure) 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 do 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 os serviços. identidades gerenciadas eliminar a necessidade de os desenvolvedores gerenciarem essas credenciais. As identidades gerenciadas permitem que você autentique seu cluster do AKS sem gerenciar credenciais ou incluí-las em seu código. Com identidades gerenciadas, você atribui uma função RBAC (controle de acesso baseado em função) do Azure à identidade, concedendo-lhe permissões a recursos específicos no Azure.

Aqui estão dois tipos de identidades gerenciadas:

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

  • Uma entidade de serviço de um tipo especial é criada na ID do Microsoft Entra 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, somente o recurso do Azure pode usar essa identidade para solicitar tokens da ID do Microsoft Entra.
  • 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 é sempre o mesmo que o nome do recurso do Azure para o qual ele foi criado.

• atribuídas pelo usuário. Você também 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:

  • Uma entidade de serviço de um tipo especial é criada na ID do Microsoft Entra para a identidade. A entidade de serviço é gerenciada separadamente dos recursos que a usam.
  • 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 gerenciada.

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

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

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

1. identidade gerenciada atribuída pelo sistema: Esse tipo de identidade gerenciada está associado a um único recurso do Azure, como um cluster do 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 do cluster do AKS. Ele persiste separadamente do cluster e pode ser usado por vários recursos do Azure.

3. identidade gerenciada de kubelet pré-criada: Essa é 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 do AKS, um identidade gerenciada atribuída pelo sistema é criado automaticamente para você. Você também pode optar por criar o cluster com uma identidade gerenciada atribuída pelo usuário . O cluster usa essa identidade gerenciada para solicitar tokens da ID do Microsoft Entra, 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 que ela acesse segredos em um Azure Key Vault. Dessa forma, você pode autorizar facilmente o acesso ao cluster sem gerenciar credenciais.

Usando identidades gerenciadas no AKS

Quando você usa identidades gerenciadas no AKS, não precisa provisionar nem girar segredos. 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 do AKS que esteja usando uma identidade gerenciada, poderá atualizá-lo para um tipo diferente de identidade gerenciada. No entanto, observe que pode haver um atraso enquanto os componentes do plano de controle 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 internos e complementos. 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 de Kubernetes do Azure.

ID de carga de trabalho do Microsoft Entra para Kubernetes

id de carga de trabalho do Microsoft Entra se integra ao Kubernetes para habilitar cargas de trabalho implantadas em um cluster do AKS para acessar 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 de Kubernetes do Azure.

Para usar a 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 clientes da Identidade do Azure ou com a coleção MSAL (Biblioteca de Autenticação da Microsoft), juntamente com o registro do aplicativo.

Para aproveitar totalmente a ID da Carga de Trabalho do Microsoft Entra em um cluster do Kubernetes, você precisa configurar o cluster do 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 do OpenID Connect no Serviço de Kubernetes do Azure.

Você também precisa configurar os aplicativos do Microsoft Entra para confiar nos tokens do Kubernetes. Os desenvolvedores podem então configurar suas implantações para usar contas de serviço do Kubernetes para obter tokens, que são então trocados por tokens do Microsoft Entra pela ID de Carga de Trabalho do Microsoft Entra. Por fim, 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.

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).

1. O agente kubelet 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 assinado e projetado 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 os recursos do Azure usando o token de acesso do Microsoft Entra.

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

• de software livre 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
• documentação da ID da Carga de Trabalho do Microsoft Entra
• Início rápido da ID de Carga de Trabalho do Microsoft Entra
• exemplo: 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

Uma carga de trabalho de exemplo em execução em um cluster do AKS consiste em um front-end e um serviço de 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 Barramento de Serviço do Azure. Para configurar esta carga de trabalho de exemplo, os seguintes pré-requisitos devem ser atendidos:

1. Configure um cluster do AKS com o emissor do OpenID Connect e a ID de Carga de Trabalho do Microsoft Entra habilitada.
2. Crie uma conta de serviço do Kubernetes na carga de trabalho namespace.
3. Crie um microsoft Entra de identidade gerenciada atribuída pelo usuário ou de aplicativo registrado.
4. 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.
5. Atribua as funções necessárias com permissões apropriadas à identidade gerenciada do Microsoft Entra ou ao aplicativo registrado.
6. Implantar a carga de trabalho e verificar a autenticação com a identidade da carga de trabalho.

Fluxo de mensagens da ID da Carga de Trabalho do Microsoft Entra

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

Baixe um Arquivo Visio dessa 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 appId específico e o recurso.
3. O Microsoft Entra ID verifica a confiança do 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 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:

1. Configure o cluster do AKS para emitir tokens e publicar um documento de descoberta OIDC a fim de permitir a validação desses tokens.
2. Configure os aplicativos do Microsoft Entra para confiar nos tokens do Kubernetes.
3. Os desenvolvedores configuram suas implantações para usar as contas de serviço do Kubernetes a fim de obter tokens do Kubernetes.
4. A 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 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

Recursos relacionados

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