DevOpsQuest
0 XP
Módulo 5 · CI/CD com GitHub Actions

Secrets, OIDC e permissões mínimas

Avançado 40 min+25 XPGitHub ActionsOIDCAWS IAM

Objetivos desta aula

  • Gerenciar secrets por ambiente
  • Autenticar na AWS sem chave estática
  • Aplicar menor privilégio no token do workflow

Secret em CI é alvo de ataque. Boas práticas: usar secrets por ambiente com regra de aprovação, nunca imprimir valores, evitar passar segredo por argumento de linha de comando e restringir quem pode disparar workflows que acessam produção.

A evolução mais importante dos últimos anos é OIDC: em vez de guardar chave de acesso da AWS no GitHub, o workflow troca um token de identidade por credenciais temporárias assumindo uma role. Não há chave para vazar nem rotacionar, e a role limita exatamente o que o pipeline pode fazer, inclusive por repositório e branch.

Some a isso permissões mínimas do GITHUB_TOKEN (contents: read por padrão, escrita só onde necessário) e você elimina a maior parte dos vetores de comprometimento de pipeline.

1. O problema das chaves de longa duração

Guardar AWS_ACCESS_KEY_ID em secrets funciona, mas a chave vale para sempre, pode vazar em logs e precisa de rotação manual.

2. OIDC: credenciais temporárias

O GitHub emite um token assinado dizendo 'sou o workflow do repositório X, branch main'. A AWS confia nesse emissor e, se as condições baterem, entrega credenciais válidas por uma hora. Nenhum segredo fica armazenado.

3. Condições de confiança

Restrinja o sub do token a repositório e branch (ou environment). Sem isso, qualquer repositório poderia assumir o papel.

4. permissions do GITHUB_TOKEN

Declare o mínimo: contents: read por padrão, packages: write só no job que publica, id-token: write só onde usa OIDC.

5. Actions de terceiros

Fixe actions externas pelo SHA do commit, não por tag; uma tag pode ser movida para código malicioso.

6. Checagem final

O pipeline do CloudShop acessa a AWS sem nenhuma chave salva e cada job tem só as permissões necessárias.

Na prática

Deploy autenticando por OIDC

yaml

name: deploy

on:
  push:
    tags: ["v*"]

permissions:
  contents: read
  id-token: write        # necessario para OIDC

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: producao   # exige aprovacao configurada no repo
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/cloudshop-deploy
          aws-region: us-east-1
      - run: aws sts get-caller-identity
      - run: aws ecs update-service --cluster cloudshop --service api --force-new-deployment

Nota de segurança: A trust policy da role deve restringir sub para o repositório e o ref específicos; sem isso, qualquer repo poderia assumi-la.

Trust policy restritiva

json

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
      "StringLike": { "token.actions.githubusercontent.com:sub": "repo:sua-org/cloudshop-app:ref:refs/tags/v*" }
    }
  }]
}

Assumir papel na AWS via OIDC

yaml

permissions:
  contents: read
  id-token: write          # necessario para pedir o token OIDC
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/cloudshop-deploy
          aws-region: us-east-1
      - run: aws sts get-caller-identity   # prova que as credenciais temporarias funcionam

Política de confiança restrita

json

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::123456789012: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:cloudshop-org/cloudshop-app:environment:production"
    }
  }
}

Nota de segurança: Sem a condição sub, qualquer repositório do GitHub poderia assumir esse papel.

Por que isso importa

Vagas de nível mais alto perguntam explicitamente sobre OIDC e menor privilégio em CI.

Erro comum

Guardar AWS_ACCESS_KEY_ID no repositório e nunca rotacionar.

Dica de produção

Use ambientes protegidos com revisor obrigatório para deploy em produção.

Alerta de segurança

echo de secret aparece em log; o mascaramento não cobre valores transformados (base64, por exemplo).

Pergunta de entrevista

Explique como OIDC substitui chaves estáticas no pipeline.

Glossário

OIDC
Protocolo de identidade que permite trocar token de confiança por credencial temporária.
environment
Recurso do GitHub que agrupa secrets e regras de aprovação por destino de deploy.
OIDC
Protocolo de identidade que permite trocar um token assinado por credenciais temporárias.
GITHUB_TOKEN
Token automático do workflow, com permissões configuráveis.
environment
Ambiente do GitHub com regras de aprovação e secrets próprios.

Conexão com o CloudShop

Configurar a role de deploy do CloudShop restrita a tags do repositório.

Quiz da aula

  1. 1. Qual permissão o workflow precisa para usar OIDC?

  2. 2. Maior vantagem do OIDC no CI?

  3. 3. Como fixar uma action de terceiros com segurança?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima