The Current Secrets Rotation Process Is Broken

21–22 of 22 posts

Re: The Current Secrets Rotation Process Is Broken

#21

Post by lumberjack24 » Fri, Jan 20, 2023, 11:09 AM UTC

kgeist wrote: post #5

hbrn wrote: post #4

What's sad is that despite it's current state, secret management has still managed to turn into a cargo cult. It's a "best practice" that people blindly implement without thinking. But secrets are next to useless if they are: - not used to limit number of people that have access to them (it is quite typical in small teams to give everybody access to production, which essentially gives you access to keys) - not regula…

>And rotation is hard: a lot of systems still don't support multiple keys, so rotation has to be very carefully tied to some form of blue-green deployment Oh just today I found out the previous team stored all secrets in git in multiple repositories, and now I need to rotate them all. They encrypted them eventually with sops but did not rotate them so you can find everything in git history. The only solution I can co…

Hey, maybe try running a GitGuardian [1] scan on all those repositories to look for hardcoded secrets. GitGuardian can also test in some cases if the secrets are valid or not, meaning you have to revoke and rotate them asap. I hope this helps.

[1] https://www.gitguardian.com/monitor-internal-repositories-fo...

Disclaimer: I work for GitGuardian.

Re: The Current Secrets Rotation Process Is Broken

#22

Post by hbrn » Fri, Jan 20, 2023, 4:14 PM UTC

jameshart wrote: post #10

hbrn wrote: post #4

What's sad is that despite it's current state, secret management has still managed to turn into a cargo cult. It's a "best practice" that people blindly implement without thinking. But secrets are next to useless if they are: - not used to limit number of people that have access to them (it is quite typical in small teams to give everybody access to production, which essentially gives you access to keys) - not regula…

So much practice around secrets and identity is oriented around assuming secrets are expensive . Like, people will set up a database and create ‘the database user’, with its one password which now needs to be used by all the systems that access that database. To maximize security you need to treat secrets as being cheap . In fact they need to be disposable . In theory any time a system needs access to that database y…

Right, secrets are a means to an end: giving one entity access to another.

> To maximize security you need to treat secrets as being cheap. In fact they need to be disposable.

Maybe even take it one step further: secrets are invisible implementation detail.

It does come with it's own challenges, of course, and there are no widely adopted standards. You can use something like IAM within AWS, but IAM can't give your apps access to Stripe, for example.

Post reply on HN