[jameshart]

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 you could have a process that creates an entirely new user just for that session, with a random password - and, bonus, only the permissions that that particular client needs.

If that secret gets compromised, no biggie - you can destroy that user account and the credential will never work again.

Secret rotation is a related approach, but again - if your rotation frequency is ‘quarterly’ rather than ‘hourly’, is there a good reason for that, or have you again just assumed secrets are expensive?

[nine_k]

I agree with the idea of cheap, disposable, fine-grained secrets.

With databases in particular the problem is that a connection is a relatively expensive thing which takes noticeable time to establish. Hence connection pooling, and the need for all sessions of a particular class to share credentials.

[hbrn]

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.

[feoren]

> In theory any time a system needs access to that database you could have a process that creates an entirely new user just for that session, with a random password

But doesn't that process just become the new login method? Doesn't that process need its own secrets to have the (much greater) authority to make new users? Doesn't compromising this process give you much more power than compromising one system would have?

[jameshart]

Right, secret management schemes do have a tendency to feel like ‘but wait, who holds the keys to get hold of the key?’ - it has to be turtles all the way down, right?

Except it turns out not. Secret issuance schemes like this let you move trust boundaries around, they don’t absolutely require all powerful admin systems to exist, and they also let you layer secret schemes on top of more robust trust relationship systems like IAM.

One common pattern is that higher trust ‘control plane’ systems create ephemeral lower trust process instances (eg for autoscaling) - and so patterns like this allow those control planes to bootstrap the child systems with their own unique, cheap, minimally permissioned credentials.

Yes the control plane is a juicier higher priv target. But that’s already the case.