[arnvald]

It's all cool as long as you keep all of this up to date, and that requires a lot of scrutiny and discipline.

Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.

[chrisjj]

> 3 different sources of truth about ownership

I see only 1.

Admin, access <> ownership.

[d4mi3n]

I always thought of this as authority, accountability, and responsibility of a thing. Ideally one group or person has all three. In practice you’ll have many entities with some combination of the three.

[Philip-J-Fry]

Isn't the point that this is the source of truth?

If someone needs access to a secret, you would implement it in this DSL and commit that to the system. A side effect would run on that which would grant access to that secret. When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.

[notpushkin]

From my experience, there is always a parallel process. But if you make the system painless enough, most of it will be in there, yeah.

> When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.

For this to work, you’d need to also rotate the secret, or ideally issue one for each person (so that others don’t have to update their configs).

...but sometimes you can’t reliably automatically rotate the secret, because they could have used it for something in production.