TL;DR: If you couple your some other deployment process to your Secrets Management, then you would have to redeploy for new creds. And that's bad.
There are a few "tight couplings" to avoid for Secrets Management:
- Coupling to Infrastructure as Code (IaC)
- Coupling to Configuration as Code (CaC)
- Coupling to Application Deployment (CI/CD)
The test is, if I need to do an emergency revocation, do I have to wait for any of the above to complete?
For example, if you happen to be using git2consul for secrets management*, used in one of the above 3 systems, is the only way to update secrets, then you have to wait for a deployment for one of the above to complete. If the lack of those credentials is what's causing the problem in the first place, or the build happens to be broken at the same time as the emergency revocation occurs, you'd be in trouble.
A kinder, gentler way to decouple these work flows from Secrets Management? You could ensure that Consul could be edited directly for emergency. While still having a git2consul pipeline for the configs.
If you are generating database creds, and giving them to the application, that isn’t dynamic any longer as the application can not generate them but now receives them.
As long as git2consul isn't the only way to revoke / re-issue creds, I think that makes a lot of sense.
*If you have HashiCorp Vault available, it may be better to consider Vault for this, especially since Vault works with consul-template, or better yet envconsul or Vault Agent.
Top comments (0)