When Secrets Managers Are Useless

Recently I faced the decision whether to use a secrets manager or not. Secrets managers provide some convenient functionalities to deal with secrets, but they come at the cost of another dependency, add a point of failure, complexity and increase provider lock-in. I think if you are unsure about whether or not to use a secrets manager, you probably don't need one... A common misconception about secret managers It took me some time to understand the need for secrets managers. They are supposed to add an extra layer of security, but to me it seemed like they added much complexity but little benefit. My though process went like this: You either store secrets plain text on the server that your app can access or you store them encrypted somewhere else and fetch them at runtime. But in order to fetch them you need to keep a secret on the server to fetch your secrets. So what's the whole point of this? Secrets managers do not offer much additional security if someone ever gained access to your system. Storing the secret to fetch the secrets is pretty much the same as storing the secrets. But if someone has access to your system all hope is lost anyways. The problem that secrets managers really solve The point of secrets managers is not to secure your secrets on the server, but to secure them when they are not on the server! There is nothing inherently wrong with using .env files. They can be used in a secure way, but it simply requires a lot more care and effort to do so. If you think about it: if every collaborator has a copy of all secrets, how do you ensure that everyone treats them with care and no one makes a mistake? It's not an easy problem to fix. At a certain scale dealing with .env files just becomes inconvenient to work with and it requires a lot of attention and maintenance to use them securely. A secret manager can improve how secrets are shared within your team and remove the need to store them persistently on each collaborators machine in plain text. On top secrets managers add some more convenient functionalities like versioning secrets, secrets rotation or granular access control to secrets. The downsides of secrets managers In a small project, this extra convenience might never be necessary. Or do you remember the last time, you needed granular access control for your API keys in your personal portfolio? Using a secrets manager comes at a cost: increased complexity provider lock-in another party in the chain of trust performance overhead potential single point of failure If you are the only one who ever touches your secrets, you rotate them by hand if necessary. And as long as you follow some basic security best practices, being mindful about your actions can get you quite far. Summary Security isn't a yes-no question. Security is about reducing the possibilities something could go wrong at any stage of the process, from development to operations and beyond. Adding a secrets manager provides extra guide rails that make it harder to mess up security. But it comes at a cost and there isn't an end to this... You can spend unlimited time and resources on adding layers of bubble wrap, but there always will be a weak link in the chain. You always have to trust another human to act responsibly and there is no replacement for acting carefully. For your personal portfolio I wouldn't bother introducing another dependency. But if you are dealing with a team of constantly rotating devs, the need for additional tooling to manage secrets will become apparent very quickly and at that point it will be obvious to you. In the mean time, whether you add a secrets manager or not is really just a question of what risk you feel comfortable dealing with.

Mar 23, 2025 - 20:52

Recently I faced the decision whether to use a secrets manager or not.

Secrets managers provide some convenient functionalities to deal with secrets, but they come at the cost of another dependency, add a point of failure, complexity and increase provider lock-in.

I think if you are unsure about whether or not to use a secrets manager, you probably don't need one...

A common misconception about secret managers

It took me some time to understand the need for secrets managers. They are supposed to add an extra layer of security, but to me it seemed like they added much complexity but little benefit.

My though process went like this:

You either store secrets plain text on the server that your app can access or you store them encrypted somewhere else and fetch them at runtime.

But in order to fetch them you need to keep a secret on the server to fetch your secrets. So what's the whole point of this?

Secrets managers do not offer much additional security if someone ever gained access to your system. Storing the secret to fetch the secrets is pretty much the same as storing the secrets. But if someone has access to your system all hope is lost anyways.

The problem that secrets managers really solve

The point of secrets managers is not to secure your secrets on the server, but to secure them when they are not on the server!

There is nothing inherently wrong with using .env files. They can be used in a secure way, but it simply requires a lot more care and effort to do so.

If you think about it: if every collaborator has a copy of all secrets, how do you ensure that everyone treats them with care and no one makes a mistake? It's not an easy problem to fix.

At a certain scale dealing with .env files just becomes inconvenient to work with and it requires a lot of attention and maintenance to use them securely.

A secret manager can improve how secrets are shared within your team and remove the need to store them persistently on each collaborators machine in plain text.

On top secrets managers add some more convenient functionalities like versioning secrets, secrets rotation or granular access control to secrets.

The downsides of secrets managers

In a small project, this extra convenience might never be necessary. Or do you remember the last time, you needed granular access control for your API keys in your personal portfolio?

Using a secrets manager comes at a cost:

increased complexity
provider lock-in
another party in the chain of trust
performance overhead
potential single point of failure

If you are the only one who ever touches your secrets, you rotate them by hand if necessary. And as long as you follow some basic security best practices, being mindful about your actions can get you quite far.

Summary

Security isn't a yes-no question.

Security is about reducing the possibilities something could go wrong at any stage of the process, from development to operations and beyond.

Adding a secrets manager provides extra guide rails that make it harder to mess up security. But it comes at a cost and there isn't an end to this...

You can spend unlimited time and resources on adding layers of bubble wrap, but there always will be a weak link in the chain. You always have to trust another human to act responsibly and there is no replacement for acting carefully.

For your personal portfolio I wouldn't bother introducing another dependency. But if you are dealing with a team of constantly rotating devs, the need for additional tooling to manage secrets will become apparent very quickly and at that point it will be obvious to you.

In the mean time, whether you add a secrets manager or not is really just a question of what risk you feel comfortable dealing with.