Conceder às workloads do Kubernetes acesso a AWS usando contas de serviço do Kubernetes - Amazon EKS
Tokens de contas de serviçoComplementos de clusterConcessão de permissões do AWS Identity and Access Management para workloads em clusters do Amazon Elastic Kubernetes Service

Conceder às workloads do Kubernetes acesso a AWS usando contas de serviço do Kubernetes

Uma conta de serviço do Kubernetes fornece uma identidade para processos executados em um Pod. Para obter mais informações, consulte Managing Service Accounts (Gerenciar contas de serviço) na documentação do Kubernetes. Se o seu Pod precisar de acesso aos serviços do AWS, você poderá mapear a conta de serviço para uma identidade do AWS Identity and Access Management para conceder esse acesso. Para ter mais informações, consulte Perfis do IAM para contas de serviço.

Tokens de contas de serviço

O recurso BoundServiceAccountTokenVolume é habilitado por padrão nas versões Kubernetes. Esse recurso melhora a segurança de tokens de contas de serviços, permitindo que workloads sejam executadas no Kubernetes para solicitar tokens de Web JSON que são restritos a um público, prazo e chave.. Tokens de contas de serviço têm uma expiração de uma hora. Em versões anteriores do Kubernetes, os tokens não tinham expiração. Isso significa que os clientes que dependem desses tokens precisam atualizá-los em até uma hora. Os seguintes exemplos de SDKs cliente Kubernetes atualizam tokens automaticamente no período de tempo necessário:

  • Versão do Go 0.15.7 e posteriores

  • Versão do Python 12.0.0 e posteriores

  • Versão Java 9.0.0 e posterior

  • Versão JavaScript 0.10.3 e posterior

  • Ramificação Ruby master

  • Versão do Haskell 0.3.0.0

  • Versão do C# 7.0.5 ou posterior.

Se sua workload estiver usando uma versão anterior do cliente, você deverá atualizá-la. Para permitir uma migração suave de clientes para os tokens de conta de serviço com limite de tempo mais recentes, o Kubernetes adiciona um período de expiração estendido ao token da conta de serviço além do tempo padrão de uma hora. Para clusters do Amazon EKS, o período de expiração prolongado equivale a 90 dias. O servidor de API do Kubernetes do seu cluster do Amazon EKS rejeita solicitações com tokens com mais de 90 dias. É recomendável verificar as aplicações e suas dependências para garantir que os SDKs de cliente do Kubernetes sejam iguais ou posteriores às versões listadas anteriormente.

Quando o servidor de API recebe solicitações com tokens com mais de uma hora, ele anota o evento de logs de auditoria da API com annotations.authentication.k8s.io/stale-token. O valor da anotação é parecido com o exemplo a seguir:

subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.

Se o cluster tiver registro em log do Enviar logs do ambiente de gerenciamento para o CloudWatch Logsambiente de gerenciamento habilitado, as anotações estarão nos logs de auditoria. É possível utilizar a seguinte consulta do Cloudwatch Log Insights para identificar todos os Pods no cluster do Amazon EKS que estejam utilizando tokens obsoletos:

fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime

O subject refere-se à conta de serviço que o Pod utilizou. O elapsedtime indica o tempo decorrido (em segundos) após a leitura do token mais recente. As solicitações para o servidor de API são negadas quando o elapsedtime excede 90 dias (7.776.000 segundos). É necessário atualizar proativamente o SDK do cliente do Kubernetes das suas aplicações para utilizar uma das versões listadas anteriormente que atualizam o token automaticamente. Se o token da conta de serviço utilizado estiver se aproximando dos 90 dias e você não tiver tempo suficiente para atualizar as versões do SDK do cliente antes da expiração desse token, será possível encerrar os Pods existentes e criar novos. Isso provoca a reformulação do token da conta de serviço, fornecendo mais 90 dias para você atualizar os SDKs da versão do cliente.

Se o Pods fizer parte de uma implantação, a maneira sugerida de encerrar Pod e, ao mesmo tempo, manter a alta disponibilidade é executar uma implantação com o comando a seguir. Substitua my-deployment pelo nome da sua implantação.

kubectl rollout restart deployment/my-deployment

Complementos de cluster

Os seguintes complementos de cluster foram atualizados para utilizar os SDKs de cliente Kubernetes, que redefinem tokens de conta de serviço automaticamente: Convém garantir que as versões listadas ou posteriores estejam instaladas no seu cluster.

Concessão de permissões do AWS Identity and Access Management para workloads em clusters do Amazon Elastic Kubernetes Service

O Amazon EKS oferece duas maneiras de conceder permissões de gerenciamento de acesso e identidade AWS a workloads executadas em clusters do Amazon EKS: Funções de IAM para contas de serviço e identidades de pod do EKS.

Perfis do IAM para contas de serviço

Os perfis do IAM para contas de serviço (IRSA) configuram aplicações Kubernetes em execução na AWS com permissões minuciosas do IAM para acessar vários outros recursos da AWS, como buckets do Amazon S3, tabelas do Amazon DynamoDB e muito mais. É possível executar várias aplicações juntas no mesmo cluster do Amazon EKS e garantir que cada aplicação tenha apenas o conjunto mínimo de permissões de que precisa. O IRSA foi criado para oferecer suporte a várias opções de implementação do Kubernetes suportadas pelo AWS, como Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service no AWS e clusters Kubernetes autogerenciados em instâncias do Amazon EC2. Assim, o IRSA foi criado usando um serviço da AWS básico, como o IAM, e não dependia diretamente do serviço Amazon EKS e da API do EKS. Para ter mais informações, consulte Perfis do IAM para contas de serviço.

EKS Pod Identities

O EKS Pod Identity oferece aos administradores de clusters um fluxo de trabalho simplificado para autenticar aplicações para acessar vários outros recursos da AWS, como buckets do Amazon S3, tabelas do Amazon DynamoDB e muito mais. O EKS Pod Identity é somente para EKS e, como resultado, simplifica como os administradores de cluster podem configurar aplicações Kubernetes para obter permissões do IAM. Essas permissões agora podem ser facilmente configuradas com menos etapas diretamente em AWS Management Console, na API do EKS e na CLI de AWS, e não há nenhuma ação a ser executada dentro do cluster em nenhum objeto de Kubernetes. Os administradores de cluster não precisam alternar entre os serviços EKS e IAM nem usar operações privilegiadas do IAM para configurar as permissões exigidas por suas aplicações. Os perfis do IAM agora podem ser usados em vários clusters sem a necessidade de atualizar a política de confiança do perfil ao criar novos clusters. As credenciais do IAM fornecidas pelo EKS Pod Identity incluem tags de sessão de perfil, com atributos como nome do cluster, namespace e nome da conta de serviço. As tags de sessão de perfil permitem que os administradores criem um único perfil que pode funcionar em várias contas de serviço, permitindo o acesso aos recursos da AWS com base em tags correspondentes. Para ter mais informações, consulte Saiba como a EKS Pod Identity concede aos pods acesso aos serviços da AWS.

Comparação entre o EKS Pod Identity e o IRSA

Em alto nível, tanto o EKS Pod Identity quanto o IRSA permitem conceder permissões do IAM para aplicações executadas em clusters do Kubernetes. No entanto, eles são fundamentalmente diferentes na forma como você os configura, nos limites aceitos e nos recursos ativados. A seguir, comparamos algumas das principais características de ambas as soluções.

Atributo EKS Pod Identity IRSA

Extensibilidade de perfis

É necessário configurar cada perfil uma vez para estabelecer confiança com a recém-introduzida entidade principal do serviço Amazon EKS pods.eks.amazonaws.com. Após essa etapa única, não será necessário atualizar a política de confiança do perfil sempre que ela for usada em um novo cluster.

Você precisará atualizar a política de confiança do perfil do IAM com o novo endpoint do provedor OIDC do cluster EKS sempre que quiser usar o perfil em um novo cluster.

Escalabilidade de clusters

O EKS Pod Identity não exige que os usuários configurem o provedor OIDC do IAM, portanto, esse limite não se aplica.

Cada cluster do EKS tem um URL do emissor OpenID Connect (OIDC) associado a ele. Para usar o IRSA, é necessário criar um provedor OpenID Connect exclusivo para cada cluster do EKS no IAM. O IAM tem um limite global padrão de 100 provedores OIDC para cada conta AWS. Se você planeja ter mais de 100 clusters EKS para cada conta AWS com IRSA, você atingirá o limite do provedor IAM OIDC.

Escalabilidade de funções

O EKS Pod Identity não exige que os usuários definam uma relação de confiança entre o perfil do IAM e a conta de serviço na política de confiança, portanto, esse limite não se aplica.

No IRSA, é necessário definir a relação de confiança entre um perfil do IAM e uma conta de serviço na política de confiança do perfil. Por padrão, a duração do tamanho da política de confiança é 2048. Isso significa que você pode definir quatro relações de confiança normalmente em uma única política de confiança. Embora seja possível aumentar o limite de duração da política de confiança, em geral você tem um limite máximo de 8 relações de confiança em uma única política de confiança.

Reutilização de perfis

AWS As credenciais temporárias do STS fornecidas pelo EKS Pod Identity incluem tags de sessão de perfil, como nome do cluster, namespace, nome da conta de serviço. As tags de sessão de perfil permitem que os administradores criem um único perfil do IAM que pode ser usado com várias contas de serviço, com diferentes permissões efetivas, permitindo acesso a recursos da AWS com base nas tags anexadas a elas. Isso também é chamado controle de acesso por atributo (ABAC). Para ter mais informações, consulte Conceder acesso aos pods a recursos da AWS baseados em tags.

AWS Não há suporte para tags de sessão STS. Você pode reutilizar um perfil entre clusters, mas cada pod recebe todas as permissões do perfil.

Ambientes compatíveis

O EKS Pod Identity só está disponível no Amazon EKS.

O IRSA pode ser usado como Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service em AWS e clusters Kubernetes autogerenciados em instâncias do Amazon EC2.

Versões do EKS compatíveis

EKS Kubernetes versões 1.24 ou posteriores. Para obter números de versão específicos, consulte Versões de cluster do EKS Pod Identity.

Todas as versões de cluster do EKS compatíveis.