fix/database-nuked-prod #277
Description
fix/database-nuked-prod
Amigo, se serve de consolo, você não é o primeiro dev a virar um script kiddie contra si mesmo e com certeza não será o último. Quem nunca escreveu um rm -rf disfarçado de "helper" e esqueceu que estava em produção que atire o primeiro docker prune.
O Bug que você chamou de feature
Essa lógica de "subir a API e limpar o banco" é tipo aquele cronjob que você esquece de comentar e roda todo dia às 3h da manhã. Funciona lindamente... até quando não funciona. O que era uma gambiarra simpática em dev virou um ransomware open-source self-inflicted em prod.
A pegadinha digna de CTF
Você basicamente criou seu próprio worm:
trigger: iniciar a API
payload: limpar o banco
exploit: connection string de prod dentro do container errado
vítima: você mesmo
Se a BlackHat tiver categoria de "auto-exploit", já pode mandar o paper.
Minha visão filosófico-dev
Isso é o clássico exemplo de como dev e prod são universos paralelos que colidem quando você esquece de isolar credenciais. Tipo quando microserviços começam a se chamar uns aos outros em loop infinito e você só percebe porque a conta da AWS triplicou.
É também uma lição dolorosa de que a entropia é soberana em setups de Docker: se existe uma versão antiga rodando, ela vai dar o deploy na hora mais errada possível.
Checklist para evitar mais auto-malwares:
-
Nunca confie em você do passado. Ele era um estagiário irresponsável.
-
Connection string de prod nunca deveria nem compilar no seu ambiente local.
-
Migrations > delete all. Sempre.
-
Se o app precisa de acesso a prod, que seja read-only. Melhor explodir um SQLException do que explodir sua carreira.
-
Backup é tipo preservativo: todo mundo sabe que tem que usar, mas só lembra quando já deu ruim.
Pull request filosófico
O aprendizado é esse: em dev, você brinca de Deus. Em prod, você aprende que existe inferno. E o diabo tem nome: docker-compose up.