Cada aplicação no EKS
com a sua própria identidade.

01 / CONTEXTO

A aplicação estava no Kubernetes, mas sua identidade ainda era uma access key.

Os microsserviços no EKS precisavam acessar S3 e secrets. Do jeito que estava, recebiam AWS_ACCESS_KEY_ID eAWS_SECRET_ACCESS_KEY por variável de ambiente. Ou seja, chave fixa, e a segurança da aplicação dependia de ninguém errar ao guardar um secret.

Com IRSA, liguei uma IAM Role ao ServiceAccount de cada aplicação. O pod passou a receber uma credencial temporária, e nenhuma chave da AWS ficou no Kubernetes nem no código.

PRINCÍPIO DO PROJETO

Cada aplicação com a sua identidade, e acesso só ao que é dela.

02 / DESAFIO

A infraestrutura estava pronta para o IRSA. A aplicação, ainda não.

Se eu apagasse as chaves antes de mexer no código, a aplicação caía. Alguns clientes da AWS eram criados passando a chave direto, sem usar o caminho padrão do SDK para buscar credencial. Tive que acertar infraestrutura, manifests e código juntos.

03 / ARQUITETURA

Do ServiceAccount até a credencial temporária.

O Kubernetes entrega ao pod um token ligado ao ServiceAccount dele. O SDK da AWS usa esse token para pedir ao STS uma sessão da role. Antes de liberar, a trust policy confere o provedor OIDC do cluster, o namespace e o nome do ServiceAccount.

04 / IMPLEMENTAÇÃO

Infraestrutura e código tinham que andar juntos.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-pagamentos
  namespace: pagamentos-dev
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<conta>:role/dev-api-pagamentos-irsa

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-pagamentos
  namespace: pagamentos-dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: api-pagamentos
  template:
    metadata:
      labels:
        app.kubernetes.io/name: api-pagamentos
    spec:
      serviceAccountName: api-pagamentos # a identidade vem daqui
      containers:
        - name: api-pagamentos
          image: <conta>.dkr.ecr.us-east-1.amazonaws.com/api-pagamentos:1.4.2-8f3a1c2
          env:
            - name: AWS_REGION
              value: us-east-1
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi

# Nenhuma access key é injetada no pod.

const client = new S3Client({
  region: process.env.AWS_REGION
});

// Sem accessKeyId ou secretAccessKey no código.

05 / MIGRAÇÃO

Só apaguei as chaves depois de testar o caminho inteiro.

1. 01

   Mapeamento

   Levantei quais aplicações usavam chave, em quais pastas e para fazer o quê.

2. 02

   Infraestrutura

   Criei as roles, as trust policies e os ServiceAccounts de cada ambiente.

3. 03

   Aplicação

   Ajustei o código para o SDK buscar a credencial sozinho.

4. 04

   Validação

   Testei subir a aplicação, ler, gravar e ver o acesso negado onde devia ser negado.

5. 05

   Remoção

   Com tudo funcionando, apaguei as variáveis e os secrets com as chaves.

06 / RESULTADOS

Segurança em cada aplicação, não só no cluster.

Não tenho números para mostrar, então conto o que mudou.

07 / APRENDIZADOS

IRSA não é só configurar o cluster.

Para funcionar, três coisas precisam estar certas ao mesmo tempo: a role na AWS, o ServiceAccount do deployment e o jeito que a aplicação cria o cliente da AWS. Se qualquer uma continuar esperando chave fixa, não funciona.

O que mais ajudou foi tratar a identidade como parte da aplicação, e não como detalhe de infraestrutura. Assim deu para apagar os secrets sensíveis sabendo exatamente qual serviço acessa cada recurso.