Quem pode desbloquear prod? Uma checklist de aprovações de deploy

26.08.20263 min de leituraEquipa Atalaia

Pergunte a uma equipa quem pode fazer deploy para produção e a resposta costuma ser "só pelo pipeline, com aprovação". Pergunte quem pode aprovar, quem pode alterar o pipeline e quem consegue chegar às credenciais de produção sem ele, e a resposta fica mais longa.

Uma aprovação de deploy só é um controlo se não puder ser contornada e se quem aprova for independente da alteração. Esta checklist usa os environments do GitHub como exemplo, mas as perguntas aplicam-se a qualquer sistema de CI/CD.

O princípio: segregação de funções

Segregação de funções significa que nenhuma pessoa sozinha consegue levar uma alteração da ideia até produção. Num pipeline, isso resume-se a três separações:

1. EscreverUm engenheiro escreve a alteração e abre um pull request.
2. RevisãoOutro engenheiro aprova o código antes do merge.
3. ReleaseUm revisor obrigatório, diferente da pessoa que acionou a execução, aprova o deploy em produção.
4. DeployÉ o pipeline, não uma pessoa, que usa credenciais que só existem dentro do ambiente de produção.

Se uma única pessoa consegue fazer sozinha dois desses passos, ou saltar um, a aprovação é cerimónia. A checklist serve para encontrar onde isso acontece.

Isto não é só uma preocupação de auditoria. A segregação de funções também limita o que uma única conta comprometida consegue fazer. Se um portátil alvo de phishing ou um token pessoal exposto conseguir fazer push, merge e release sozinho, o atacante herda todo o caminho até produção de uma só vez.

Environments no GitHub Actions

Um environment do GitHub associa regras de proteção e segredos aos jobs que o referenciam. Um job que tem produção como alvo fica em pausa até as regras serem cumpridas:

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@<full-length-commit-sha>
      - name: Deploy
        run: ./scripts/deploy.sh production

Nas definições do ambiente configura os revisores obrigatórios, se a pessoa que despoletou a execução a pode aprovar, que branches ou tags podem fazer deploy, e os secrets ou variáveis que só este ambiente consegue ler. Usar OIDC para o seu fornecedor de cloud, com uma trust policy associada ao claim do ambiente production, significa que não há nenhuma chave de deploy de longa duração para vazar.

A checklist

Onde costumam estar as lacunas

• O break-glass que se tornou a porta. Um bypass de admin de emergência usado todas as semanas é o verdadeiro processo de deploy.
• O workflow antigo. Um job de deploy legado, anterior aos environments, que ainda tem um segredo de repositório.
• A equipa minúscula. Com dois engenheiros, a separação é difícil. Faça com que a segunda pessoa aprove, e registe cada exceção em vez de desligar a regra.
• A edição do workflow. Se qualquer pessoa puder alterar o workflow num branch que tem permissão para fazer deploy, pode remover a linha environment. Restrições de branch e revisão por code owners nos ficheiros de workflow fecham isto.

Faça-o em 30 minutos

1. Liste todos os workflows que conseguem chegar a produção. Procure scripts de deploy, credenciais de cloud e nomes de ambientes.
2. Para cada um, responda às dez perguntas com as definições do repositório abertas no ecrã.
3. Registe qualquer "não" ou "não sei" como ticket com um dono.
4. Corrija primeiro os bypasses: secrets soltos, linhas environment em falta, overrides de admin.
5. Repita sempre que for acrescentado um novo destino de deploy. É o último gate da linha, por isso vale a pena verificar duas vezes.

Onde isto fica na linha

Na torre (em desenvolvimento):