Editar

Partilhar via

Identidade e acesso à carga de trabalho do Kubernetes

Microsoft Entra ID
Azure Kubernetes Service (AKS)

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:

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.

Nota

Este artigo faz parte de uma série de artigos que ajudam os profissionais familiarizados com o Amazon EKS a entender o AKS.

Gerenciamento de identidade e acesso do Amazon EKS

O Amazon EKS tem duas opções nativas para chamar serviços da 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 as funções do IAM a uma conta de serviço do Kubernetes. Essa conta de serviç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ê não precisa fornecer permissões estendidas para a função do IAM do nó para pods nesse nó chamarem APIs da AWS. Você pode definir o escopo de permissões do IAM para uma conta de serviço e somente os pods que usam essa conta de serviço têm acesso a essas permissões. Esse recurso também elimina a necessidade de soluções de terceiros, como kiam ou kube2iam.

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

  • Capacidade de auditoria: o Amazon CloudTrail fornece acesso e registro de eventos para ajudar a garantir a auditoria retrospetiva.

As funções vinculadas ao serviço do Amazon EKS são funções exclusivas do IAM vinculadas diretamente ao Amazon EKS. As funções vinculadas ao serviço são predefinidas pelo Amazon EKS e incluem todas as permissões necessárias para chamar outros serviços da AWS em nome da função. Para a função do IAM do nó do Amazon EKS, o daemon do kubelet nó do Amazon EKS chama as APIs da AWS em nome do nó. Os nós obtêm permissões para essas chamadas de API de um perfil de instância do IAM e políticas associadas.

Identidades gerenciadas pelo cluster AKS

Um cluster AKS requer 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 AKS cria automaticamente uma identidade gerenciada atribuída ao sistema. A plataforma Azure gerencia a identidade e você não precisa provisionar ou girar nenhum segredo. Para obter mais informações sobre identidades gerenciadas do Microsoft Entra, consulte 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. A entidade de serviço eventualmente expira e você deve renová-la para manter o cluster funcionando. O gerenciamento de entidades de serviço adiciona complexidade, por isso é 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 identidades gerenciadas tem uma expiração de 90 dias e é girada após 45 dias.

O AKS usa 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 AKS, disco do Azure anexado, endereço IP estático, tabela de rotas ou identidade atribuída pelo kubelet 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 AKS, como um modelo Bicep, um modelo ARM (Azure Resource Manager) ou um módulo Terraform, precisará usar a ID principal da identidade gerenciada do cluster para fazer uma atribuição de função. A identidade do cluster AKS deve ter pelo menos a função de Colaborador de Rede na sub-rede da sua rede virtual. Para definir uma função personalizada em vez de usar a função interna de Colaborador de Rede, você precisa das seguintes permissões:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Quando a identidade do cluster precisa acessar um recurso existente, por exemplo, quando você implanta um cluster AKS em uma rede virtual existente, você deve usar uma identidade gerenciada atribuída pelo usuário. Se você usar uma identidade de plano de controle atribuída pelo sistema, o provedor de recursos não poderá obter sua ID principal antes de criar o cluster, portanto, é impossível criar as atribuições de função adequadas antes do provisionamento do cluster.

Resumo das identidades gerenciadas

O AKS usa as seguintes identidades gerenciadas atribuídas pelo usuário para serviços e complementos internos.

Identidade Nome Caso de utilização Permissões padrão Traga a sua própria identidade
Plano de controlo Nome do cluster AKS Gerencia recursos de cluster, incluindo balanceadores de carga de entrada e IPs públicos gerenciados pelo AKS, autodimensionador de cluster e drivers Azure Disk e Azure File CSI Função de colaborador para o grupo de recursos do nó Suportado
Kubelet AKS Cluster-agentpool de nomes Autentica com o Registro de Contêiner do Azure NA (para kubernetes v1.15+) Suportado
Suplemento HTTPApplicationRouting Gerencia os recursos de rede necessários Função de leitor para grupo de recursos de nó, função de colaborador para zona DNS Não
Suplemento Gateway de aplicativo de ingresso Gerencia os recursos de rede necessários Função de colaborador para o grupo de recursos do nó Não
Suplemento omsagent Enviar métricas do AKS para o Azure Monitor Função de Publicador de Métricas de Monitoramento Não
Suplemento Nó virtual (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 do nó Não

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

ID de carga de trabalho do Microsoft Entra para Kubernetes

As cargas de trabalho do Kubernetes exigem credenciais do aplicativo Microsoft Entra para acessar recursos protegidos pelo Microsoft Entra ID, como o Azure Key Vault e o Microsoft Graph. Um desafio comum para os desenvolvedores é gerenciar segredos e credenciais para proteger a comunicação entre os diferentes componentes de uma solução.

O 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, nome de usuário e senha ou 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 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).

Diagrama mostrando um fluxo de trabalho simplificado para uma identidade gerenciada por pod no Azure.

  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.

Atualmente, a federação de ID de Carga de Trabalho do Microsoft Entra para Kubernetes é suportada apenas para aplicativos Microsoft Entra, mas o mesmo modelo pode se estender a identidades gerenciadas do Azure.

Para obter mais informações, automação e documentação para o ID de carga de trabalho do Microsoft Entra, consulte:

Exemplo de carga de trabalho

A carga de trabalho de exemplo executa um serviço de front-end e um serviço de back-end em um cluster 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:

  • Azure Key Vault
  • Azure Cosmos DB
  • Conta de armazenamento do Azure
  • Namespace do Barramento de Serviço do Azure

Pré-requisitos

  1. Configure um cluster AKS com o 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 como mostrado no início rápido.
  5. Atribua funções com as permissões certas aos aplicativos registrados necessários 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

Os aplicativos AKS obtêm tokens de segurança para sua conta de serviço do emissor OIDC do cluster AKS. O Microsoft Entra Workload ID troca os tokens de segurança por 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 recursos do Azure.

O diagrama a seguir mostra como os aplicativos frontend e back-end adquirem tokens de segurança do Microsoft Entra para usar serviços de plataforma como serviço (PaaS) do Azure.

Diagrama mostrando um aplicativo de exemplo que usa o ID de carga de trabalho do Microsoft Entra.

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:

Outros contribuidores:

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

Próximos passos