Recently I faced the decision whether to use a secrets manager or not.
Secrets managers provide some convenient functionalities to deal with secre...
For further actions, you may consider blocking this person and/or reporting abuse
The best way to avoid vendor lock-in or dependency on the 3rd parties etc. is to custom build an asymmetric encryption library or a package that could be potentially utilized across the board within an organization.
Haha, good one! 😄
If you are afraid of lock-in or another party to trust, you can build your own. A secrets manager is basically a key-value store. If you only expose that to the networks you trust, it is like any other key-value store you add to a network.
I think a secrets manager shines when you are doing CI/CD. When deploys happen in multiple environments a secrets manager makes it easier to get the secrets for a specific project on a specific environment.
I agree it is a failure point, to prevent it from becoming one you could create an action/task in the CI/CD workflow that adds the secrets to the server.
Sometimes you need to see a tool for more than the advertised purpose. Just take the idea and see how it can benefit you.
You can build anything yourself, and sometimes a crappy version of software that already exists is enough, but it adds complexity and another headache to deal with... I think if developers tracked their time more precisely and had to pay their own hours, they probably think twice about entering these rabbit holes...
I see the CICD benefits though. To clarify, I am not entirely against using secrets managers (and in fact I use one) - but I think overengineering is real and there is a right time and place to do so...
With the rise of supply chain attacks it feels like security measures need to be more a focus than usual. They even changed devOps to devSecOps. Probably not for that reason, but I found it funny because that is an inherent part of the ops tasks.
You don't need to build something. It can be as easy as a private file on a cloud storage that is added to the server during a deploy. For added security the values can be encrypted.
If you have one project you can handle secrets manually. Once there are multiple projects with secrets I would look for the most barebones solution. And add features or look for a service when it is needed.
For me a secrets manager is more a convenience solution than a security solution.
You don't need to "keep a secret on your server to fetch your secrets" like you say. Are you unfamiliar with IAM permissions?
Sure, but it's pretty much the same thing... You don't store a secret yourself, but the machine comes preconfigured with a secret installed (that you don't see or set) that enables you to access secrets... IAM just means, Amazon (or whoever provider you are using) takes care of this step for you and does rotation etc. in the background.
I don't think that's correct... Admittedly I've never worked for Amazon/Google/Microsoft so I don't know exactly how their proprietary IAM/IMDS authentication works, and they don't exactly publish those details publicly. But I'm quite confident that they aren't storing static secrets on the server and then rotating them.
Somebody asked a question about how Azure does this over on StackOverflow and there's speculation in the answers that they are rotating certificates on the servers. But another answer points out that the cloud provider validates requests to the Identity Service through their own virtualized networking, which is not exactly something an attacker could spoof even if they had the hidden certificate. In other words, it's a little more complicated that just storing a secret on the server.
Yeah, I also don't exactly know how they do it, but you're right, probably not with a static secret... I was using the term "secret" more symbolically to say, that the server is authenticated to retrieve other secrets, be it a static secret, a certificate, through the virtual network, or whatever...
Also, not every provider offers IAM. I use Hetzner a lot, they are great! But their core offer is just plain VMs
Hmm... biggest reason I have seen for secrets managers is that env variables remain accessible to the process for the entire duration of its life...so if someone can inject some program input that excutes an env dump, they can view such credentials. Php and Node js have built in global mechanisms to dump env variables from any module without need to import anything new
Secrets manager changes this flow in that the secret is fetched, used once in the project and overridden in memory. Later memory dumps can never show such a secret.
When done right, The secrets manager should not need another secret...it should be about authorizing the account under which the process runs to access the secrets manager apis. The account has the permission to access, not the credentials to access.
But even if you use a secret to access the secrets manager, it is better that it gets exposed and not your actual secrets for different internal/external systems and apis because it should be useless outside of your environment.
Basically for an attacker to use it, they literally have to write, compile and execute the fetch secret code from the server itself which is a significantly harder attack to pull off. Remote code execution of an env dump is easier than remote code execution of custom raw code.
Its really about limiting duration of exposure rather than indirection or obfuscation.
Glad to know that! Thank you