4 ms·

I can't seem to understand how a "secrets manager" helps things. Could someone who does ELI5 why it's better than a config file with permissions locked down?

bvandewalle 6y ago
It makes sense at scale. If you are a company of two there are probably better solutions. At scale, you can very granularly define policies for each secret. When a secret is accessed, it is done so through a user or application identity. Each access is also logged.
- scott00 6y ago
  So then how do you manage the secret that authenticates an application's identity? And what good is the logging if after an application has the secret it can do whatever it wants with it?
  - bvandewalle 6y ago
    if it is an instance on the cloud, GCP and AWS let you define ServiceAccounts that get populated on the Instance at boot time. you should only let the instance access the secret it requires.
    - rdslw 6y ago
      and how do you manage secrets that let you define that ServiceAccounts? As OP wrote, you did not solve it, just moved it to a different level.
closeparen 6y ago
In a monolithic application they're pretty close. In a microservices architecture, suppose you have 100 services and schedule 6 service containers per host. That is 94 services worth of secrets that don't need to be there, expanding the blast radius of single host compromise. There may be a credential on that host that can be exchanged for more secrets, but audit logs can tell you whether it actually was, and you can revoke it. Secrets may still need to go to config files for third party stuff, but you can write your in-house applications to fetch secrets at runtime and hold them only in memory. That's less opportunity for compromise vs. both memory and disk. Also have heard that Linux's process address space isolation is less prone to vulnerabilities than user account separation or filesystem permissions. Not really sure how true that is.
LASR 6y ago
The real difference over a file is that you some intelligence(the manager) running that can offer all kinds of additional security functionality. A typical deployment might involve placing the manager on a secure host that has access to generate and rotate keys, for example. The manager can then configured to re-generate keys and vend them on-demand to instances that need require them. You can configure these keys with very limited access, and also make them expiring. The manager then becomes effectively a keystore that can never export master keys, but only vends out some limited-scope keys to other instances. Other instances would have to authenticate using some pre-configured host keys or even be authenticated directly though the cloud provider. If your instances are compromised, the worst someone can do is to get access to a limited-scope key that will expire. Hopefully you have other measures in place that would prevent and detect someone from just sitting on an instance and sucking up all your data and exporting them.
- mmm_grayons 6y ago
  Thanks, this makes a lot more sense and seems much more useful than the justifications I've heard others give. I appreciate it.

bvandewalle 6y ago

It makes sense at scale. If you are a company of two there are probably better solutions. At scale, you can very granularly define policies for each secret. When a secret is accessed, it is done so through a user or application identity. Each access is also logged.

scott00 6y ago
So then how do you manage the secret that authenticates an application's identity? And what good is the logging if after an application has the secret it can do whatever it wants with it?
- bvandewalle 6y ago
  if it is an instance on the cloud, GCP and AWS let you define ServiceAccounts that get populated on the Instance at boot time. you should only let the instance access the secret it requires.
  - rdslw 6y ago
    and how do you manage secrets that let you define that ServiceAccounts? As OP wrote, you did not solve it, just moved it to a different level.

closeparen 6y ago

In a monolithic application they're pretty close. In a microservices architecture, suppose you have 100 services and schedule 6 service containers per host. That is 94 services worth of secrets that don't need to be there, expanding the blast radius of single host compromise. There may be a credential on that host that can be exchanged for more secrets, but audit logs can tell you whether it actually was, and you can revoke it. Secrets may still need to go to config files for third party stuff, but you can write your in-house applications to fetch secrets at runtime and hold them only in memory. That's less opportunity for compromise vs. both memory and disk. Also have heard that Linux's process address space isolation is less prone to vulnerabilities than user account separation or filesystem permissions. Not really sure how true that is.

LASR 6y ago

The real difference over a file is that you some intelligence(the manager) running that can offer all kinds of additional security functionality. A typical deployment might involve placing the manager on a secure host that has access to generate and rotate keys, for example. The manager can then configured to re-generate keys and vend them on-demand to instances that need require them. You can configure these keys with very limited access, and also make them expiring. The manager then becomes effectively a keystore that can never export master keys, but only vends out some limited-scope keys to other instances. Other instances would have to authenticate using some pre-configured host keys or even be authenticated directly though the cloud provider. If your instances are compromised, the worst someone can do is to get access to a limited-scope key that will expire. Hopefully you have other measures in place that would prevent and detect someone from just sitting on an instance and sucking up all your data and exporting them.

mmm_grayons 6y ago
Thanks, this makes a lot more sense and seems much more useful than the justifications I've heard others give. I appreciate it.