- passwords would end up in version control repositories. A whole article could be written on this point alone but to summarise: those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history)
- you can’t then change the credentials easily without having to push a new version of the application
- you expose the password to developers, which might be fine in smaller teams but larger organisations might separate those duties. You might also bring in contractors who you wouldn’t trust with DB access or shouldn’t have access for data compliance reasons
- you make it harder to have different credentials for different environments (Eg dev, UAT, staging and production). There is no workaround for that doesn’t introduce other problems....aside from removing hardcoded passwords.
2/ you probably can't change the credentials just by changing the ENV anyway: there will likely be some kind of restart/reload to perform on one or many components (and such actions better be well logged and tracked, which happens with a redeploy)
3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem
4/ it's not harder, it's just an if/switch away from you (instead of another set of tools)
It's good to have secrets managed, like API keys, private keys, ... but most of the time it more of hiding them, which is not sufficient! And as the article says, it is very easy to let them slip through logs/dump, as well as let some code treat them in a insecure (or even malicious) manner.
2. A service restart is always going to be less risky than shipping a new application (which would also require a restart as well).
3. In an ideal world I’d agree with you. However in many places it is and even in places where it’s not, not hardcoding passwords helps provide defence in depth.
4. Harder to do it securely. Your solution leaks all passwords to all environments and is possibly the worst workaround to the problem (I’ve seen CI/CD inject the correct passwords, which seems the best approach but if you’re going to those lengths then you might as well use a secrets management service)
>those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history)
With Git, it's not "nuking" so much as "retroactively creating a different timeline in which the secret wasn't shared." Still a pain in the ass if there's more than one developer.
- passwords would end up in version control repositories. A whole article could be written on this point alone but to summarise: those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history)
- you can’t then change the credentials easily without having to push a new version of the application
- you expose the password to developers, which might be fine in smaller teams but larger organisations might separate those duties. You might also bring in contractors who you wouldn’t trust with DB access or shouldn’t have access for data compliance reasons
- you make it harder to have different credentials for different environments (Eg dev, UAT, staging and production). There is no workaround for that doesn’t introduce other problems....aside from removing hardcoded passwords.