Segurança de Workloads no EKS:
Uma Identidade por Aplicação.

01 / CONTEXTO

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

Microsserviços executados no Amazon EKS precisavam acessar recursos como buckets S3 e secrets. O modelo inicial entregava AWS_ACCESS_KEY_IDe AWS_SECRET_ACCESS_KEY por variáveis de ambiente. Além de manter credenciais persistentes, isso vinculava a segurança do workload ao armazenamento correto de um secret.

A evolução adotou IRSA para associar uma IAM Role ao ServiceAccount de cada aplicação. Dessa forma, o pod passou a receber uma identidade temporária e controlada, sem guardar chaves da AWS no Kubernetes ou no código.

PRINCÍPIO DO PROJETO

Cada workload deve possuir identidade própria e acesso limitado à sua responsabilidade.

02 / DESAFIO

A infraestrutura estava pronta para o IRSA. A aplicação também precisava estar.

Remover as chaves do secret antes de ajustar o código faria a aplicação falhar. Alguns clientes AWS eram inicializados com credenciais explícitas e não utilizavam a cadeia padrão de credenciais do SDK. A migração precisou coordenar infraestrutura, manifests e aplicação.

03 / ARQUITETURA

Do ServiceAccount à sessão temporária da AWS.

O pod recebe um token projetado do Kubernetes vinculado ao seu ServiceAccount. O SDK da AWS utiliza esse token para solicitar ao STS uma sessão da IAM Role associada. A trust policy valida o provedor OIDC do cluster, o namespace e o nome do ServiceAccount antes de liberar o acesso.

04 / IMPLEMENTAÇÃO

Infraestrutura e código precisavam falar o mesmo idioma.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: lab-test
  namespace: brown
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/lab-test-irsa

apiVersion: apps/v1
kind: Deployment
metadata:
  name: lab-test
  namespace: brown
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: lab-test
  template:
    metadata:
      labels:
        app.kubernetes.io/name: lab-test
    spec:
      serviceAccountName: lab-test
      containers:
        - name: lab-test
          image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/lab-test: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

A retirada das chaves aconteceu somente depois da validação ponta a ponta.

1. 01

   Mapeamento

   Identificação das aplicações, caminhos, operações AWS e credenciais estáticas utilizadas.

2. 02

   Infraestrutura

   Criação das roles, trust policies e ServiceAccounts por ambiente.

3. 03

   Aplicação

   Ajuste dos clientes AWS para utilizar a cadeia padrão de credenciais.

4. 04

   Validação

   Teste de inicialização, leitura, gravação e tratamento de acesso negado conforme o escopo.

5. 05

   Remoção

   Exclusão das variáveis e secrets de access key após a confirmação do novo fluxo.

06 / RESULTADOS

Segurança aplicada no nível do workload.

Os benefícios abaixo são qualitativos e refletem a evolução do modelo de identidade, sem atribuir métricas não comprovadas.

07 / APRENDIZADOS

IRSA não é apenas uma configuração do cluster.

Uma migração segura exige alinhamento entre três camadas: a role criada na AWS, o ServiceAccount usado pelo deployment e o cliente AWS inicializado pela aplicação. Se uma delas continuar esperando credenciais estáticas, o modelo não se completa.

O melhor resultado surgiu ao tratar identidade como parte da arquitetura da aplicação. Isso permitiu remover secrets sensíveis sem perder clareza sobre qual serviço pode acessar cada recurso.