Funções do IAM para contas de serviço (IRSA)

Quando um pod em execução no EKS precisa chamar uma API da AWS — por exemplo, ler dados do S3 ou gravar dados no DynamoDB — ele precisa de credenciais da AWS. A abordagem ingênua é criar um usuário do IAM e codificar suas chaves de acesso como variáveis de ambiente. Isso é inseguro e viola o princípio do privilégio mínimo, porque todos os pods no mesmo nó compartilham as credenciais. IAM Roles for Service Accounts (IRSA) resolve esse problema associando funções do IAM com permissões específicas diretamente a contas de serviço do Kubernetes.

O IRSA funciona por meio da federação OpenID Connect (OIDC). O EKS cria um provedor OIDC para o seu cluster. Quando um pod faz referência a uma conta de serviço anotada com um ARN de função do IAM, o EKS injeta no pod um token de conta de serviço projetado e assinado. O SDK da AWS no pod troca esse token por credenciais temporárias da AWS usando a API AssumeRoleWithWebIdentity do AWS STS — sem necessidade de chaves de longa duração.

Antes de usar o IRSA, você deve associar o emissor OIDC do EKS como um provedor de identidade confiável na sua conta da AWS. Isso cria um recurso de provedor OIDC do IAM que o AWS STS reconhecerá. O comando eksctl faz isso automaticamente. Depois de criado, você pode verificá-lo no console do IAM, em Provedores de identidade.

A função do IAM para o IRSA deve ter uma política de confiança que permita ao provedor OIDC assumi-la, com escopo restrito a um namespace específico do Kubernetes e a uma conta de serviço. A condição usa a declaração sub no token OIDC, definida como system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Isso garante que somente os pods que usam essa conta de serviço específica possam assumir a função — e não qualquer pod do cluster.

Crie uma ServiceAccount do Kubernetes no namespace de destino e anote-a com o ARN da função do IAM. Quando um pod fizer referência a essa conta de serviço, o EKS injetará automaticamente o token OIDC e duas variáveis de ambiente (AWS_WEB_IDENTITY_TOKEN_FILE e AWS_ROLE_ARN). O SDK da AWS as detecta automaticamente e chama o STS para obter credenciais temporárias — não são necessárias alterações no código da sua aplicação.

Na especificação do seu pod ou implantação, defina serviceAccountName como a conta de serviço anotada. Quando o EKS agendar o pod, ele montará automaticamente o token OIDC em /var/run/secrets/eks.amazonaws.com/serviceaccount/token e definirá as variáveis de ambiente necessárias. Qualquer chamada ao SDK da AWS dentro do pod usará de forma transparente as credenciais da função do IAM associada, sem nenhuma configuração explícita de credenciais.

Com uma função do IAM do nó, todos os pods em um nó herdam as mesmas permissões — um pod comprometido pode acessar todos os serviços da AWS aos quais o nó tem permissão de acesso. Com o IRSA, cada pod, por meio da sua conta de serviço, assume somente a função de que precisa. Isso segue o princípio do privilégio mínimo no nível do pod e limita o impacto de qualquer incidente de segurança. A AWS recomenda o IRSA em vez de funções no nível do nó para todas as novas implantações do EKS.

O eksctl pode criar a associação OIDC, a função do IAM, a política de confiança e a anotação da ServiceAccount do Kubernetes com um único comando, usando create iamserviceaccount. Essa é a maneira mais simples de configurar o IRSA sem escrever manualmente o JSON da política de confiança. Você especifica o namespace, o nome da conta de serviço e o ARN da política do IAM a ser associada, e o eksctl cuida do restante.

Muitos complementos e controladores do EKS precisam do IRSA para funcionar: o Cluster Autoscaler precisa de permissão para chamar a API do EC2 Auto Scaling, o AWS Load Balancer Controller precisa de permissão para criar e gerenciar recursos do ELB, o external-dns precisa de acesso de gravação ao Route 53, e o EBS CSI driver precisa de permissão para criar e associar volumes EBS. Use sempre o IRSA para esses componentes do sistema — nunca conceda as permissões no nível da função do IAM do nó.

Os tokens do IRSA têm curta duração e são rotacionados automaticamente pelo controlador de projeção de tokens do Kubernetes antes de expirarem. O público padrão do token é sts.amazonaws.com e a validade é de 24 horas, mas o controlador os atualiza quando atingem 80% da sua duração. As credenciais do AWS STS obtidas por meio do IRSA também são temporárias, normalmente válidas por 1 hora. Essa rotação automática elimina a sobrecarga de rotacionar credenciais de chaves de acesso do IAM de longa duração.

Sempre que um pod assume uma função do IAM por meio do IRSA, o AWS CloudTrail registra um evento AssumeRoleWithWebIdentity. O evento inclui o ARN da função assumida, o assunto do token OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) e o IP de origem. Isso fornece um registro de auditoria completo sobre quais pods acessaram quais serviços da AWS e quando — algo essencial para conformidade e investigação de incidentes em ambientes regulamentados.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: o IRSA usa a federação OIDC para trocar tokens de contas de serviço do Kubernetes por credenciais temporárias da AWS; as políticas de confiança das funções do IAM restringem o acesso a um namespace e uma conta de serviço específicos; e o IRSA fornece privilégio mínimo por pod, muito superior ao das funções do IAM no nível do nó. A seguir, exploraremos as métricas, os namespaces e as dimensões do CloudWatch para observar seus recursos da AWS.