Lab 54 — Pipeline: CodePipeline ou GitHub Actions com OIDC

# Antes de mudar qualquer coisa, meça a exposição real — nao a percepcao dela.
aws iam get-access-key-last-used --access-key-id "$AKIAXXXX"
aws iam list-access-keys --user-name ana-deploy \
  --query "AccessKeyMetadata[].{Id:AccessKeyId,Criada:CreateDate,Status:Status}"

# Na Cadencia: CreateDate de 11 meses atras, Status Active, ultimo uso ha 2 dias
# (um "ecs update-service" de deploy legitimo). A chave nao e um resquicio
# esquecido — e o caminho de producao em uso todo dia.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:ffv/api:ref:refs/heads/main"
      }
    }
  }]
}

# oidc.tf — o provedor federado, e a role que so o pipeline pode assumir

# Um provedor OIDC por EMISSOR, nao por repositorio. Se a conta ja tiver um
# provider para token.actions.githubusercontent.com (outro time criou), REUSE
# com `data`, como o L42 fez para o provider do EKS — criar um segundo para o
# mesmo emissor falha, porque a URL tem de ser unica na conta.
data "tls_certificate" "github_actions" {
  url = "https://token.actions.githubusercontent.com/.well-known/openid-configuration"
}

resource "aws_iam_openid_connect_provider" "github_actions" {
  url = "https://token.actions.githubusercontent.com"

  # "aud" que a AWS aceita para esta federacao. GitHub pode emitir token para
  # outras audiencias tambem, mas so esta e reconhecida do lado da AWS.
  client_id_list = ["sts.amazonaws.com"]

  # A AWS hoje valida o certificado TLS do endpoint JWKS contra sua propria
  # lista de CAs confiaveis, e so recorre ao thumbprint configurado se essa
  # validacao falhar. O campo continua obrigatorio no recurso — obtido aqui
  # dinamicamente para nao apodrecer quando o GitHub rotacionar o certificado.
  thumbprint_list = [data.tls_certificate.github_actions.certificates[0].sha1_fingerprint]
}

data "aws_iam_policy_document" "confianca_github" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRoleWithWebIdentity"]

    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.github_actions.arn]
    }

    # aud: sempre presente, sempre "sts.amazonaws.com" para este uso. Sem esta
    # condicao, um token emitido pelo MESMO emissor para OUTRA integracao
    # tambem passaria — o emissor e o mesmo, a audiencia nao.
    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:aud"
      values   = ["sts.amazonaws.com"]
    }

    # sub: o repositorio E a branch, exatos — nao "qualquer repositorio da
    # org" e nao "qualquer branch deste repositorio". StringLike com
    # "repo:${var.org_github}/*:*" pareceria mais conveniente e autorizaria
    # pull request de fork a tentar a mesma role (o "sub" de PR de fork tem
    # outro formato, mas o wildcard tambem cobriria ele).
    #
    # ATENCAO: repositorios criados apos 15/jul/2026 (ou que optaram por
    # migrar) recebem "sub" com IDs imutaveis:
    # "repo:org@123456/repo@456789:ref:refs/heads/main". Confira no PROPRIO
    # repositorio qual formato esta em uso antes de fixar este valor —
    # nao existe "padrao geral" que sirva para os dois.
    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:sub"
      values   = ["repo:${var.org_github}/${var.repo_github}:ref:refs/heads/main"]
    }
  }
}

resource "aws_iam_role" "deploy_pipeline" {
  name               = "${var.projeto}-deploy-pipeline"
  assume_role_policy = data.aws_iam_policy_document.confianca_github.json

  # Sessao curta: mesmo que o job va acima do usual, a credencial nao serve
  # depois disso. Nao e o TTL do token do GitHub (quem decide isso e o
  # GitHub); e o teto que esta ROLE impoe sobre a sessao assumida.
  max_session_duration = 1200 # 20 min — o pipeline completo mede 6 a 9 min
}

data "aws_caller_identity" "atual" {}

data "aws_iam_policy_document" "permissoes_deploy" {
  statement {
    sid    = "PublicarImagem"
    effect = "Allow"
    actions = [
      "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:BatchCheckLayerAvailability",
      "ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload",
    ]
    resources = [aws_ecr_repository.api.arn] # so ESTE repositorio, nunca "ecr:*" da conta
  }

  statement {
    sid       = "TokenDeAutenticacao"
    effect    = "Allow"
    actions   = ["ecr:GetAuthorizationToken"] # operacao de CONTA — nao aceita recurso especifico
    resources = ["*"]
  }

  statement {
    sid    = "AtualizarServico"
    effect = "Allow"
    actions = [
      "ecs:DescribeServices", "ecs:UpdateService",
      "ecs:RegisterTaskDefinition", "ecs:DescribeTaskDefinition",
    ]
    resources = [
      "arn:aws:ecs:${var.regiao}:${data.aws_caller_identity.atual.account_id}:service/${aws_ecs_cluster.principal.name}/${aws_ecs_service.api.name}",
      "arn:aws:ecs:${var.regiao}:${data.aws_caller_identity.atual.account_id}:task-definition/${var.projeto}-api:*",
    ]
  }

  statement {
    sid       = "PassarAsRolesDaTask"
    effect    = "Allow"
    actions   = ["iam:PassRole"]
    resources = [aws_iam_role.execucao.arn, aws_iam_role.task.arn]
    # PassRole sem Resource restrito e o jeito mais comum de uma role de
    # deploy virar role de QUALQUER coisa: quem pode passar qualquer role
    # pode fazer o ECS rodar com privilegio maior do que o pipeline deveria ter.
  }
}

resource "aws_iam_role_policy" "deploy_pipeline" {
  role   = aws_iam_role.deploy_pipeline.id
  policy = data.aws_iam_policy_document.permissoes_deploy.json
}

output "role_de_deploy" {
  value       = aws_iam_role.deploy_pipeline.arn
  description = "ARN a colocar em role-to-assume no workflow do GitHub Actions"
}

# .github/workflows/deploy.yml
name: Deploy para producao

on:
  push:
    branches: [main]

# Sem isto, o job nao consegue pedir token nenhum — e a falha e um erro de
# PERMISSAO no primeiro passo, nao um erro misterioso de rede.
permissions:
  id-token: write   # pedir o token OIDC
  contents: read    # checkout do codigo

concurrency:
  group: deploy-producao
  cancel-in-progress: false   # nunca cancele um deploy em andamento pela metade

jobs:
  build-test-publicar:
    runs-on: ubuntu-latest
    timeout-minutes: 15   # nao e o SLA do rollout (L03); e o teto do PIPELINE

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Testar antes de construir a imagem
        run: dotnet test --configuration Release
        # Um push que falha aqui NUNCA chega ao ECR. E a diferenca central em
        # relacao ao laptop: o pipeline nao pede que alguem lembre de rodar o
        # teste, ele bloqueia sozinho.

      # AssumeRoleWithWebIdentity acontece DENTRO desta action. Ela troca o
      # token OIDC do job pela credencial STS e a expoe como variavel de
      # ambiente para os passos seguintes — nunca como arquivo em disco.
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/ffv-lab-deploy-pipeline
          role-session-name: gh-${{ github.run_id }}-${{ github.run_attempt }}
          aws-region: us-east-1

      - name: Construir e publicar a imagem
        env:
          REPO: 111122223333.dkr.ecr.us-east-1.amazonaws.com/ffv-lab-api
          SHA: ${{ github.sha }}
        run: |
          aws ecr get-login-password --region us-east-1 \
            | docker login --username AWS --password-stdin "${REPO%%/*}"
          docker build --platform linux/amd64 -t "$REPO:$SHA" .
          # Tag imutavel (L03): reenviar o mesmo SHA falha, e a falha e
          # desejavel — diz que nao ha nada novo a publicar.
          docker push "$REPO:$SHA" || { echo "nada a publicar: SHA ja existe"; exit 0; }

      - name: Implantar com o rollout do L03
        env:
          SHA: ${{ github.sha }}
        run: |
          terraform init -input=false
          terraform apply -input=false -auto-approve -var="sha_da_imagem=${SHA}"
          aws ecs wait services-stable --cluster ffv-lab --services ffv-lab-api

# provas.sh — cinco medicoes; nenhuma conclusao vem de "o workflow ficou verde"

ROLE_ARN="arn:aws:iam::111122223333:role/ffv-lab-deploy-pipeline"

# ── Prova 1: a chave pessoal nao publica mais ────────────────────────────────
# Desative a access key da Ana e repita o deploy manual antigo. Tem de falhar.
aws iam update-access-key --user-name ana-deploy --access-key-id "$AKIAXXXX" \
  --status Inactive
./implantar-manual-antigo.sh \
  && echo "FALHA DA PROVA: o deploy manual ainda funciona" \
  || echo "OK: sem a chave, o caminho antigo nao publica mais"

# ── Prova 2: um token de outra branch e recusado ─────────────────────────────
# Rode o workflow numa branch diferente de main (ou mude o "on:" temporariamente
# num branch de teste). O passo de configure-aws-credentials tem de falhar com
# "not authorized to perform sts:AssumeRoleWithWebIdentity".
gh workflow run deploy.yml --ref branch-de-teste
gh run watch --exit-status \
  && echo "FALHA DA PROVA: token de outra branch foi aceito" \
  || echo "OK: a trust policy recusou o sub que nao bate"

# ── Prova 3: quem publicou fica registrado, por execucao ────────────────────
# O role-session-name carrega o run_id — a resposta a "quem publicou essa
# versao" fica em UMA consulta, nao em correlacionar logs a mao.
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
  --query 'Events[?contains(Username, `gh-`)].[EventTime,Username]' --output table

# ── Prova 4: a credencial nao sobrevive ao job ───────────────────────────────
# Nao ha comando de "revogar" a rodar — e essa e a prova. Confira que a role
# nao aparece em nenhum lugar do repositorio como secret persistido.
gh secret list --repo ffv/api | grep -iE "AWS_SECRET|AWS_ACCESS_KEY" \
  && echo "FALHA DA PROVA: ha uma chave de longa duracao guardada como secret" \
  || echo "OK: nenhuma credencial AWS persistida no repositorio"

# ── Prova 5: o rollout do L03 continua identico ──────────────────────────────
# O criterio de aceite do L03 (zero 5xx durante a troca) tem de continuar
# valendo — so a origem do "quem chamou update-service" mudou.
URL="https://$(terraform output -raw dominio)/api/health/ready"
( while true; do curl -s -o /dev/null -w '%{http_code} ' "$URL"; sleep 0.2; done ) & LACO=$!
gh workflow run deploy.yml --ref main && gh run watch --exit-status
kill $LACO
# Esperado: fileira continua de 200, exatamente como no L03.

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

# 2. PROVEDOR OIDC: pode sobreviver se outro repositorio o estiver usando. Confira
#    antes de apagar — apagar o provider quebra TODO pipeline federado pelo mesmo emissor.
aws iam list-open-id-connect-providers
aws iam list-roles --query "Roles[?contains(AssumeRolePolicyDocument, 'token.actions.githubusercontent.com')].RoleName" --output table

# 3. CHAVE PESSOAL: o laboratorio nao a cria, mas o objetivo dele so se cumpre com
#    ela desativada. Confirme, nao presuma.
aws iam list-access-keys --user-name ana-deploy

# 4. SECRET NO REPOSITORIO: se alguem cadastrou uma chave de garantia, ela nao sai
#    com terraform destroy nenhum — vive nas configuracoes do GitHub.
gh secret list --repo ffv/api

# 5. Prova final: nada com o nome do projeto de pe que nao devia estar.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab --query "ResourceTagMappingList[].ResourceARN"