Comment by maxxxxx | Hacker News Reader

Comment by maxxxxx | Hacker News Reader

Parent Full thread

Secret management can be a really infuriating problem. No matter what you do there never seems to be a good solution between dealing with employees who know passwords leaving, automated processes needing credentials and other business processes. It's one of the toughest problems I have ever seen without a good solution. At least not one that the business people will accept without complaining that it's too expensive or burdensome.

One of the benefits of using dynamic secrets is that access to say databases carry a short TTL. Vault manages the lifecycle of these credentials and will automatically revoke them once the defined lifecycle has expired. To gain access to credentials a user would authenticate to Vault with say LDAP, this access can be controlled centrally with a policy defining access to secrets assigned on an individual user or group level.

Should an individual leave an organisation then the credentials they have obtained from Vault to access a datastore would expire automatically, normal process would apply to remove them from LDAP and disable the ability to require further credentials.

There is always a process problem with managing secrets but dynamic secrets in Vault stops long-lived secrets and reduces unofficial password sharing.

Secret management tends to suffer from the logical holders of secrets (managers) not actually having the time or expertise in a lot of cases to deal with the implementation (or even understanding) of the process.

This. The lack of focus faced today from key custodians and the lack of undergoing continuous training to understand the different threats and keeping up-to-date with implementations is a gaping hole in this particular type of model. It's never a core competency, which is why the industry needs a different paradigm.

As in, "Job title: The Holder Of Keys"?

My solution has always been to treat such keys and secrets as financial instruments, and therefore prone to use only through direct processing - i.e. build/deploy environments have to have explicit requirements of allowing the finance guy to come in and type the codes needed to distribute to mass, general public .. but this has to be a managed expectation of dev tooling in general ..

It's hard to explain the need for this to business people unless your engineering management is very strongly supporting it.

we collect dongles as employee leaves.

What if the employee has "lost" their dongles?

I suppose you can deactivate it.

Reply on news.ycombinator.com