README.md

Projeto 04 — CI/CD seguro com GitHub Actions e OIDC

Este projeto automatiza a validação do código e demonstra um deploy controlado da infraestrutura do Projeto 03. A autenticação usa OIDC e credenciais temporárias; nenhuma access key é armazenada no GitHub.

Cenário e arquitetura

A equipe da Aurora Commerce precisa impedir que código Python sem teste, Terraform mal formatado ou uma mudança sem revisão chegue à conta AWS. Pull requests devem produzir feedback sem credenciais; deploys devem usar um artefato revisado, aprovação humana e uma sessão temporária limitada ao repositório correto.

pull request -> validate -> testes + Terraform checks
workflow manual -> aprovação -> OIDC -> STS -> plan aprovado -> apply

O fluxo completo, incluindo os limites de confiança, está em architecture/cicd-oidc.md.

Workflows entregues

• .github/workflows/validate.yml: compila Python, executa testes e valida Terraform em pull requests e pushes.
• .github/workflows/deploy.yml: workflow manual, com environment protegido, OIDC, plan salvo e apply condicionado a uma confirmação explícita.
• docs/guia-de-execucao.md: configuração da trust policy restrita a repositório, branch e audience.
• checklist.md: critérios de segurança, evidência e rollback.

Como usar em um repositório próprio

1. Copie os workflows para .github/workflows/ na raiz do repositório do projeto.
2. Ajuste working-directory se a infraestrutura estiver em outro caminho.
3. Crie uma role AWS para OIDC e restrinja sub ao seu repositório e branch.
4. Cadastre o ARN como variável do repositório AWS_ROLE_ARN.
5. Crie o environment aws-dev e exija aprovação.
6. Abra um pull request propositalmente correto e outro com terraform fmt quebrado.
7. Execute o deploy manual somente em conta de estudo e após ler o plan.

Antes de publicar, valide localmente a estrutura dos workflows:

python -m unittest discover -s projetos/04-cicd-com-github-actions/tests -v
python projetos/04-cicd-com-github-actions/python/validate_workflows.py

Controles de segurança

• permissões padrão mínimas no workflow;
• id-token: write somente no job que autentica via OIDC;
• actions referenciadas por versões principais conhecidas e revisáveis;
• nenhuma etapa de deploy em pull request;
• apply usa o arquivo de plan criado na mesma execução;
• environment protegido antes do job de deploy;
• a role limita escrita aos recursos curso-data-pipeline-* e restringe PassRole a Lambda e Glue;
• concorrência impede dois deploys simultâneos no mesmo ambiente.

Resultado esperado

Pull requests recebem validação automática. O deploy não ocorre por push: exige acionamento manual, confirmação, aprovação do environment e autenticação OIDC bem-sucedida. As evidências devem mostrar checks, plan e outputs sanitizados, nunca tokens ou dados da conta.

Entrega e encerramento

No portfólio, mostre uma validação aprovada, uma falha intencional bloqueada e a trust policy com conta e repositório anonimizados. Explique por que id-token: write aparece apenas no job de deploy e como o environment separa validação de autorização.

Depois do exercício, remova a variável AWS_ROLE_ARN e a role de estudo caso não sejam reutilizadas. Revogue sessões pelo fim natural da credencial temporária, preserve apenas evidências sanitizadas e verifique se nenhum workflow agendado ou recurso implantado continua ativo.