[seguranca] feat(deploy): guard de autorização do deploy de produção v2 — fecha 4 bypasses [INFRA-68070] #81
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/INFRA-68070-guard-deploy-global-v2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
[seguranca] INFRA-68070: guard de autorização do deploy de produção, versão canônica (v2)
Substitui o #80, que foi fechado sem merge porque a revisão de segurança achou formas de pular a autorização. O guard existe para que o token do bot não consiga disparar um deploy de produção sozinho.
v*passava sem conferência, e o bot conseguia criar a tag em qualquer commit e disparar o deploymain, com ato humano e dentro de 24 h. Sem token de API, falha fechado. Se oGITHUB_SHAdivergir da tag, recusaAUTORIZO hotfixera aceito de qualquer humano não-autor, e orefs/pull/abria isso para qualquer PR paramainDEPLOY_APROVADORES(padrãotarcisio) para os três atos: review, merged_by e comentário. Bot nunca contaDISPATCH_REF, que o produto pode alimentar com inputGITHUB_REF. Se oDISPATCH_REFdivergir, recusa. Omaincurto deixou de valerofficial is TrueTambém entram as 4 regras da v1: fuso de São Paulo valendo só hoje e ontem, strip, caractere de controle e
::recusados sem eco,(#N)e(!N)reconhecidos.Limite documentado: a frase manual não é criptográfica, porque quem dispara o workflow pode escrevê-la. O bloqueio real vem com o runner de deploy com identidade própria (INFRA-68022/68023).
Prova:
pytest tests -q: 864 passed.tests/deploy-guard: 82 passed.9e029ef(v1) e passam agora.Adoção nos produtos:
autorizacaoprecisa deFORGEJO_API+FORGEJO_TOKENsó de leitura, porque o push de tag agora consulta a API;DISPATCH_REFou o push livre precisam ser ajustados.🤖 Generated with Claude Code
https://claude.ai/code/session_017QrAM1chSgVpSwDrKJVLVn