Pipeline de IaC: plano aprovado, apply rastreável e drift triado
Objetivos desta aula
- Separar credenciais de plan e apply
- Aplicar o mesmo plano aprovado
- Interpretar códigos de saída sem mascarar falhas
- Distinguir mudanças esperadas de possível drift
- Definir limites de confiança em workflows
O pipeline anterior conectou ferramentas; agora o foco é garantir o que foi aprovado. Um plano é uma proposta calculada para código, variáveis, providers e state específicos. Rodar outro plan silenciosamente no job de apply pode executar algo diferente do que a revisão autorizou.
Separe validação sem credenciais de acesso à nuvem. fmt e verificações estáticas podem rodar em PRs não confiáveis; planos autenticados ficam restritos a código revisado e origens confiáveis. Nunca combine checkout de código de fork com segredos usando um gatilho privilegiado como atalho.
Autentique com OIDC e roles distintas. A trust policy deve restringir repositório, branch ou environment e audience. A role de plan lê recursos, lê state e, quando necessário, escreve o lockfile; isso não significa conceder alteração dos recursos de produção.
No plan persistido, fixe a revisão e salve plan.tfplan. O job de apply recebe esse mesmo arquivo, usa a mesma versão do Terraform e providers compatíveis e depende de aprovação do environment. Se outro apply alterar o state, o plano pode ficar obsoleto: gere outro e solicite nova aprovação.
Artifacts são sensíveis: o plano binário e sua representação JSON podem conter valores que a interface normalmente oculta. Restrinja acesso, retenção e origem do artifact. Não publique o plano completo em comentários abertos; apresente um resumo revisável sem segredos.
Trate exit codes como protocolo: com -detailed-exitcode, 0 indica ausência de mudanças, 1 indica erro e 2 indica mudanças propostas. O shell de CI pode encerrar no código 2 antes de você classificá-lo; capture o resultado explicitamente sem converter um erro real em sucesso.
Para drift detection, rode um plano agendado sobre a revisão implantada e as mesmas entradas aprovadas. Um código 2 apenas sinaliza diferença: ela também pode vir de alteração de código, variáveis ou provider. Correlacione o plano com histórico de deploy e auditoria antes de chamar tudo de drift.
O fluxo seguro é detectar, triar e aprovar, não corrigir automaticamente qualquer diferença. Abra um incidente ou tarefa com responsável e prazo; decida se a alteração externa deve virar código ou ser revertida. Use concorrência por ambiente no CI e mantenha o lock do backend como proteção adicional.
Na prática
Capturar o resultado do plano em um job autenticado
yaml
# Trecho de steps após checkout confiável, setup-terraform com
# terraform_wrapper: false, autenticação OIDC e terraform init.
- name: Gerar plano e classificar resultado
id: plan
shell: bash
working-directory: infra/envs/dev
run: |
set +e
terraform plan -input=false -lock-timeout=5m -detailed-exitcode -out=plan.tfplan
rc=$?
set -e
case "$rc" in
0) echo "changes=false" >> "$GITHUB_OUTPUT" ;;
2) echo "changes=true" >> "$GITHUB_OUTPUT" ;;
*) echo "Falha ao calcular plano" >&2; exit "$rc" ;;
esac
# No fluxo completo, envie o plano como artifact privado de curta retenção.
# O job de apply protegido baixa exclusivamente o artifact desta execução.Aplicar o plano revisado no job protegido
bash
# Pré-condições: aprovação de environment, checkout do mesmo commit,
# role de apply via OIDC e plano íntegro baixado desta mesma execução.
set -euo pipefail
cd infra/envs/dev
terraform init -input=false -lockfile=readonly
# Não executar um novo plan neste job: aplique o arquivo já aprovado.
terraform apply -input=false -lock-timeout=5m plan.tfplan
# Se o plano estiver obsoleto, interrompa e reinicie plan + aprovação.
# Em execução separada, valide convergência e notifique diferenças.Por que isso importa
Vincular revisão, plano e execução reduz mudanças inesperadas e permite reconstruir quem aprovou cada alteração.
Erro comum
Capturar qualquer falha de plan com || true e publicar o job como sucesso sem distinguir código 1 de 2.
Dica de produção
Use environment protegido, concorrência por ambiente sem cancelar apply em andamento e retenção curta de artifacts.
Alerta de segurança
Código de PR pode executar comandos arbitrários: não dê credenciais de plan ou acesso ao state a contribuições não confiáveis.
Pergunta de entrevista
Como garantir que o apply executa exatamente a mudança revisada e como tratar um plano obsoleto?
Glossário
- plano persistido
- Arquivo produzido por plan -out para aplicação posterior da mesma proposta.
- OIDC
- Protocolo usado para trocar identidade do job por credenciais temporárias na nuvem.
- environment protegido
- Contexto de implantação com restrições e aprovação antes da execução autorizada.
- artifact
- Arquivo preservado por uma execução de CI para uso controlado em outros jobs.
- drift detection
- Verificação periódica de divergências que exige triagem de causa e intenção.
Conexão com o CloudShop
Fortalecer o pipeline do CloudShop com plano persistido, aprovação, roles separadas e triagem de diferenças agendadas.
Quiz da aula
1. O plan retorna 2 com -detailed-exitcode. Isso significa:
2. O state mudou após a aprovação e o plano ficou obsoleto. O que fazer?
3. Quem pode receber acesso ao state em um workflow de PR?
Minhas anotações
Salvo automaticamente neste navegador.