Lab 42 — Identidade de workload: task role, execution role, IRSA

// Formato que o endpoint interno do agente ECS devolve ao SDK, na porta
// 169.254.170.2, quando ele busca a sessao da task role. O SDK nunca chama
// STS diretamente neste caminho — o agente ja fez isso por tras da task.
{
  "RoleArn": "arn:aws:iam::111122223333:role/ffv-lab-conciliacao-task",
  "AccessKeyId": "ASIAEXEMPLO000000000000",
  "SecretAccessKey": "***",
  "Token": "***",
  "Expiration": "2026-08-07T16:45:12Z"
}
// A forma exata pode variar por versao do agente — confirme na sua conta com
// um curl de dentro do conteiner antes de depender de um campo especifico.

# ecs-identidade.tf — a task role, e nenhuma chave em lugar nenhum

# Confianca: so o ECS pode assumir esta role, e so em nome de UMA task deste
# projeto. As duas condicoes protegem contra o "confused deputy": sem elas,
# uma task de OUTRO servico na mesma conta tambem poderia assumi-la.
data "aws_iam_policy_document" "confianca_ecs_task" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["ecs-tasks.amazonaws.com"]
    }
    condition {
      test     = "ArnLike"
      variable = "aws:SourceArn"
      values   = ["arn:aws:ecs:${var.regiao}:${var.conta}:*"]
    }
    condition {
      test     = "StringEquals"
      variable = "aws:SourceAccount"
      values   = [var.conta]
    }
  }
}

resource "aws_iam_role" "conciliacao_task" {
  name               = "${var.projeto}-conciliacao-task"
  assume_role_policy = data.aws_iam_policy_document.confianca_ecs_task.json
}

# Escopo real: um prefixo do bucket, uma tabela. A condicao por padrao de
# chave/tag mais fina fica para o L41 — aqui o alvo e a IDENTIDADE, nao o
# refinamento maximo da policy.
data "aws_iam_policy_document" "conciliacao_task_permissoes" {
  statement {
    sid       = "LerExportsDoDia"
    effect    = "Allow"
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.fechamentos.arn}/exports/*"]
  }
  statement {
    sid       = "GravarConciliacao"
    effect    = "Allow"
    actions   = ["dynamodb:PutItem", "dynamodb:UpdateItem"]
    resources = [aws_dynamodb_table.conciliacao.arn]
  }
}

resource "aws_iam_role_policy" "conciliacao_task" {
  role   = aws_iam_role.conciliacao_task.id
  policy = data.aws_iam_policy_document.conciliacao_task_permissoes.json
}

resource "aws_ecs_task_definition" "conciliacao" {
  family                   = "${var.projeto}-conciliacao"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 256
  memory                   = 512
  execution_role_arn       = aws_iam_role.execucao.arn        # so ECR + logs
  task_role_arn             = aws_iam_role.conciliacao_task.arn # so o que a APLICACAO usa

  container_definitions = jsonencode([{
    name      = "conciliacao"
    image     = "${aws_ecr_repository.conciliacao.repository_url}:${var.sha_da_imagem}"
    essential = true

    # NENHUM bloco "environment" com AWS_ACCESS_KEY_ID ou AWS_SECRET_ACCESS_KEY.
    # A ausencia e o ponto central deste arquivo — nao ha nada aqui para
    # "esconder melhor". A credencial nunca existe em forma gravavel.
    environment = [
      { name = "BUCKET_EXPORTS", value = aws_s3_bucket.fechamentos.bucket },
      { name = "TABELA_CONCILIACAO", value = aws_dynamodb_table.conciliacao.name },
    ]

    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = aws_cloudwatch_log_group.conciliacao.name
        "awslogs-region"        = var.regiao
        "awslogs-stream-prefix" = "conciliacao"
      }
    }
  }])
}

# Disparo diario. A periodicidade nao muda nada sobre a identidade — e por
# isso que o defeito do desenho minimo nao aparece aqui: ele nunca dependeu
# de QUANDO a task roda, so de COMO ela se autentica.
resource "aws_scheduler_schedule" "conciliacao_diaria" {
  name                = "${var.projeto}-conciliacao-diaria"
  schedule_expression = "cron(0 6 * * ? *)"

  flexible_time_window { mode = "OFF" }

  target {
    arn      = aws_ecs_cluster.principal.arn
    role_arn = aws_iam_role.scheduler_ecs.arn

    ecs_parameters {
      task_definition_arn = aws_ecs_task_definition.conciliacao.arn
      launch_type          = "FARGATE"
      network_configuration {
        subnets          = aws_subnet.privada[*].id
        security_groups  = [aws_security_group.conciliacao.id]
        assign_public_ip = false
      }
    }
  }
}

# eks-identidade.tf — o CronJob, e a role que so a ServiceAccount dele assume

# O provedor OIDC e um recurso POR CLUSTER, criado uma vez no L34. Recria-lo
# aqui duplicaria o provedor — cada IAM OIDC Provider tem endpoint proprio, e
# ter dois para o MESMO cluster confunde qual trust policy referencia qual.
# Por isso: leitura, nao criacao.
data "aws_iam_openid_connect_provider" "cluster" {
  url = "https://${data.aws_eks_cluster.principal.identity[0].oidc[0].issuer}"
}

data "aws_eks_cluster" "principal" {
  name = "${var.projeto}-eks" # o cluster ja existe, criado no L34
}

# A condicao dupla e o que faz esta role NAO ser assumivel por qualquer pod
# do cluster. `sub` restringe a UMA ServiceAccount; `aud` confirma que o token
# foi emitido para se apresentar ao STS — sem ela, um token emitido para OUTRA
# audiencia tambem passaria na checagem de `sub`.
data "aws_iam_policy_document" "confianca_irsa_conciliacao" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type        = "Federated"
      identifiers = [data.aws_iam_openid_connect_provider.cluster.arn]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(data.aws_iam_openid_connect_provider.cluster.url, "https://", "")}:sub"
      values   = ["system:serviceaccount:conciliacao:conciliacao-sa"]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(data.aws_iam_openid_connect_provider.cluster.url, "https://", "")}:aud"
      values   = ["sts.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "irsa_conciliacao" {
  name               = "${var.projeto}-irsa-conciliacao"
  assume_role_policy = data.aws_iam_policy_document.confianca_irsa_conciliacao.json
}

data "aws_iam_policy_document" "irsa_conciliacao_permissoes" {
  statement {
    sid       = "ConsumirPedidosPagos"
    effect    = "Allow"
    actions   = ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"]
    resources = [data.aws_sqs_queue.pedidos_pagos.arn] # a fila do L03/L34
  }
  statement {
    sid       = "LerChaveDoParceiro"
    effect    = "Allow"
    actions   = ["secretsmanager:GetSecretValue"]
    resources = [aws_secretsmanager_secret.chave_parceiro.arn]
  }
}

resource "aws_iam_role_policy" "irsa_conciliacao" {
  role   = aws_iam_role.irsa_conciliacao.id
  policy = data.aws_iam_policy_document.irsa_conciliacao_permissoes.json
}

# conciliacao-cronjob.yaml — a linha que liga a ServiceAccount a role IRSA

apiVersion: v1
kind: ServiceAccount
metadata:
  name: conciliacao-sa
  namespace: conciliacao
  annotations:
    # E esta linha, e so ela, que faz o pod receber AWS_ROLE_ARN e
    # AWS_WEB_IDENTITY_TOKEN_FILE no ambiente. Sem ela, o pod sobe com a
    # identidade fraca padrao do namespace — sem AccessDenied nenhum na hora
    # de subir, so quando a primeira chamada AWS acontecer.
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/ffv-lab-irsa-conciliacao
---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: conciliacao-diaria
  namespace: conciliacao
spec:
  schedule: "0 6 * * *" # mesmo horario da task ECS, por decisao de produto — nao tecnica
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: conciliacao-sa # sem isto, IRSA nao se aplica a este pod
          restartPolicy: OnFailure
          containers:
            - name: conciliacao
              image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/ffv-lab-conciliacao-eks:SHA_DA_IMAGEM
              env:
                - name: FILA_URL
                  value: https://sqs.us-east-1.amazonaws.com/111122223333/ffv-lab-pedidos-pagos
                - name: SEGREDO_PARCEIRO_ARN
                  value: arn:aws:secretsmanager:us-east-1:111122223333:secret:ffv-lab-chave-parceiro
              # Nenhum "envFrom" apontando para Secret do Kubernetes com chave
              # AWS dentro. Se voce ve isso num manifesto, e a chave estatica
              # de novo, so que trocou de gaveta.

// Program.cs — o desenho minimo. O codigo parece limpo; o risco mora no Terraform.

var builder = Host.CreateApplicationBuilder(args);

builder.Services.AddAWSService<IAmazonS3>();
builder.Services.AddAWSService<IAmazonDynamoDB>();

// Nenhuma credencial aqui. O construtor sem argumento deixa o SDK escolher
// sozinho, pela cadeia padrao — e e exatamente essa escolha silenciosa que
// torna a chave estatica da task definition perigosa: o codigo nao tem como
// saber, e nao pergunta, qual fonte respondeu.
var app = builder.Build();

var s3 = app.Services.GetRequiredService<IAmazonS3>();
var dynamo = app.Services.GetRequiredService<IAmazonDynamoDB>();

var bucket = Environment.GetEnvironmentVariable("BUCKET_EXPORTS")!;
var tabela = Environment.GetEnvironmentVariable("TABELA_CONCILIACAO")!;

var exports = await s3.ListObjectsV2Async(new ListObjectsV2Request
{
    BucketName = bucket,
    Prefix     = $"exports/{DateOnly.FromDateTime(DateTime.UtcNow):yyyy-MM-dd}/",
});

foreach (var obj in exports.S3Objects)
{
    // processamento do arquivo de fechamento, omitido — nao e o foco do laboratorio
    await dynamo.PutItemAsync(tabela, new Dictionary<string, AttributeValue>
    {
        ["pk"] = new() { S = $"CONCILIACAO#{obj.Key}" },
        ["processadoEm"] = new() { S = DateTimeOffset.UtcNow.ToString("O") },
    });
}

// Program.cs — o desenho de producao: recusa iniciar se achar chave estatica

var builder = Host.CreateApplicationBuilder(args);
var log = LoggerFactory.Create(b => b.AddConsole()).CreateLogger("Conciliacao");

// A GUARDA que o desenho minimo nao tem. Nao e defesa contra ataque: e defesa
// contra o proprio time, seis meses depois, colando uma chave "so para testar"
// e esquecendo de tirar. Falhar AQUI, alto e cedo, e mais barato que descobrir
// num scan de Terraform state.
var chaveEstatica = Environment.GetEnvironmentVariable("AWS_ACCESS_KEY_ID");
if (!string.IsNullOrEmpty(chaveEstatica))
{
    log.LogCritical(
        "AWS_ACCESS_KEY_ID presente no ambiente — credencial estatica detectada. " +
        "Encerrando antes de processar qualquer coisa. Remova a variavel da task " +
        "definition ou do manifesto; a task role/IRSA ja resolve isto.");
    Environment.Exit(1);
}

builder.Services.AddAWSService<IAmazonS3>();
builder.Services.AddAWSService<IAmazonDynamoDB>();

var app = builder.Build();

// Prova em runtime de QUAL provedor respondeu — a mesma pergunta que a secao
// de implantacao verifica de fora, aqui verificada de dentro do processo.
var credenciais = FallbackCredentialsFactory.GetCredentials();
log.LogInformation("credencial resolvida pela cadeia padrao: {Tipo}", credenciais.GetType().Name);
// Esperado em ECS: "ECSTaskCredentials" (ou equivalente do provedor de
// contêiner). Esperado em EKS: "AssumeRoleWithWebIdentityCredentials".
// Qualquer coisa contendo "Environment" ou "Basic" e a falha que este
// laboratorio existe para impedir.

var s3 = app.Services.GetRequiredService<IAmazonS3>();
var dynamo = app.Services.GetRequiredService<IAmazonDynamoDB>();

var bucket = Environment.GetEnvironmentVariable("BUCKET_EXPORTS")!;
var tabela = Environment.GetEnvironmentVariable("TABELA_CONCILIACAO")!;

var exports = await s3.ListObjectsV2Async(new ListObjectsV2Request
{
    BucketName = bucket,
    Prefix     = $"exports/{DateOnly.FromDateTime(DateTime.UtcNow):yyyy-MM-dd}/",
});

foreach (var obj in exports.S3Objects)
{
    await dynamo.PutItemAsync(tabela, new Dictionary<string, AttributeValue>
    {
        ["pk"] = new() { S = $"CONCILIACAO#{obj.Key}" },
        ["processadoEm"] = new() { S = DateTimeOffset.UtcNow.ToString("O") },
    });
}

log.LogInformation("conciliacao concluida: {Total} exports processados", exports.S3Objects.Count);

# achar-a-chave.sh — a prova que abre o laboratorio: a chave estava exposta

# Terraform state guarda o valor de toda variavel que passou por um recurso,
# em TEXTO PLANO, a menos que voce marque como sensitive — e "environment"
# de task definition raramente e marcado.
terraform show -json terraform.tfstate \
  | jq -r '.. | objects | select(has("environment")) | .environment[]? | select(.name=="AWS_ACCESS_KEY_ID")'
# Esperado ANTES da correcao: uma linha com "value": "AKIA...".
# Esperado DEPOIS: nenhuma saida — a variavel nao existe mais na definicao.

# Segundo lugar onde ela aparece: log de aplicacao que imprime configuracao
# na partida "para depurar". Aconteceu na Cadencia numa versao antiga.
aws logs filter-log-events \
  --log-group-name /ecs/ffv-lab-conciliacao \
  --filter-pattern "AKIA" \
  --query "events[].message" --output text
# Qualquer resultado aqui e um incidente, nao um achado academico: a chave
# apareceu em texto plano num grupo de logs que dezenas de pessoas podem ler.

# prova-ordem-da-cadeia.sh — confirma qual credencial o SDK realmente usou

# ANTES da correcao: a task tem tanto a variavel de ambiente quanto a task
# role anexada. O log de partida do CS_GUARDA (ou um log equivalente) mostra
# qual delas venceu.
aws logs filter-log-events \
  --log-group-name /ecs/ffv-lab-conciliacao \
  --filter-pattern "credencial resolvida" \
  --query "events[].message" --output text
# Esperado ANTES: "... Tipo: EnvironmentVariablesAWSCredentials" (ou Basic).
# Isso PROVA que a task role, mesmo anexada e correta, nunca foi consultada.
# Se o log mostrar o tipo do provedor de contêiner mesmo com a chave presente,
# a ordem da cadeia documentada nao bate com o comportamento observado — pare
# e releia a task definition, porque algo nao confere.

# prova-correcao.sh — depois de remover a variavel, a sessao muda de tipo

terraform apply -auto-approve  # aplica ecs-identidade.tf sem environment de chave
aws ecs wait services-stable --cluster ffv-lab --services ffv-lab-conciliacao

aws logs filter-log-events \
  --log-group-name /ecs/ffv-lab-conciliacao \
  --filter-pattern "credencial resolvida" \
  --query "events[-1:].message" --output text
# Esperado DEPOIS: o tipo do provedor de credencial do conteiner (nao mais
# Environment nem Basic). Se ainda aparecer um tipo estatico, a variavel
# continua presente em algum lugar — confira tambem o Dockerfile e a imagem
# base, que podem ter um .env copiado por engano.

# prova-irsa.sh — dentro do pod, nenhuma chave; so token e role ARN

kubectl exec -n conciliacao deploy/conciliacao-debug -- env | grep ^AWS_
# Esperado: AWS_ROLE_ARN=arn:aws:iam::...:role/ffv-lab-irsa-conciliacao
#           AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
# NENHUMA linha com AWS_ACCESS_KEY_ID ou AWS_SECRET_ACCESS_KEY. Se aparecer
# uma delas, alguem colocou um Secret do Kubernetes com chave estatica dentro
# — a mesma falha do ECS, so que morando em outro objeto.

kubectl exec -n conciliacao deploy/conciliacao-debug -- aws sts get-caller-identity
# Esperado: "Arn" contendo "assumed-role/ffv-lab-irsa-conciliacao/..." — a
# sessao carrega o NOME DA ROLE, nao um nome de usuario. E a prova de que a
# troca do token por sessao realmente aconteceu.

# prova-cloudtrail.sh — a auditoria diferencia os dois caminhos

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetObject \
  --query "Events[?contains(CloudTrailEvent, 'ffv-lab-conciliacao-task')].CloudTrailEvent" \
  --max-results 5 --output text | jq '.userIdentity.arn, .userIdentity.sessionContext.sessionIssuer.arn'
# Esperado: um "assumed-role" com o taskArn no sessionContext — nao um "user".

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ReceiveMessage \
  --query "Events[?contains(CloudTrailEvent, 'irsa-conciliacao')].CloudTrailEvent" \
  --max-results 5 --output text | jq '.userIdentity.arn'
# Esperado: um "assumed-role" citando irsa-conciliacao, com o sub da
# ServiceAccount visivel no token — nao um nome de usuario IAM em nenhum caso.

# 1. Derrube o que o Terraform administra.
terraform destroy -auto-approve

# 2. USUARIO IAM E CHAVE DA PROVA DE CONCEITO: se voce recriou o cenario de
#    abertura para testar, ele NAO esta no Terraform (foi criado a mao, e e
#    esse o ponto). O destroy nao toca nele.
aws iam list-access-keys --user-name cadencia-conciliacao-poc
aws iam delete-access-key --user-name cadencia-conciliacao-poc \
  --access-key-id "$(aws iam list-access-keys --user-name cadencia-conciliacao-poc \
                       --query 'AccessKeyMetadata[0].AccessKeyId' --output text)"
aws iam delete-user --user-name cadencia-conciliacao-poc

# 3. ROLE IRSA E O PROVEDOR OIDC: a role sai no destroy. O PROVEDOR OIDC nao
#    sai, porque foi lido com `data`, nao criado aqui — ele pertence ao L34 e
#    outros workloads do cluster podem depender dele.
aws iam get-open-id-connect-provider \
  --open-id-connect-provider-arn "$(terraform output -raw oidc_provider_arn)" \
  >/dev/null && echo "provedor OIDC preservado, como esperado — pertence ao L34"

# 4. GRUPO DE LOGS da task de conciliacao: retencao propria, sobrevive ao servico.
aws logs delete-log-group --log-group-name /ecs/ffv-lab-conciliacao 2>/dev/null || true

# 5. Prova final: nenhuma role, usuario ou chave com o nome do projeto de pe.
aws iam list-roles --query "Roles[?contains(RoleName, 'ffv-lab')].RoleName" --output table
aws iam list-users --query "Users[?contains(UserName, 'ffv-lab')].UserName" --output table