On Fri, 2023-10-06 at 14:26 -0500, Nathan Bossart wrote:
> I guess it's more of the latter. Perhaps one potential use case
> would be
> short-lived credentials that are created on demand. Such a password
> might
> only be valid for something like 15 minutes, and many users might
> have the
> ability to request a password for the database role. I don't know
> whether
> there is a ton of demand for such a use case, and it might already be
> solvable by just creating separate roles. In any case, if there's
> general
> agreement that we only want to target the rotation use case, that's
> fine by
> me.
The basic problem, as I see it, is: how do we keep users from
accidentally dropping the wrong password? Generated unique names or
numbers don't solve that problem. Auto-incrementing or a created-at
timestamp solves it in the sense that you can at least look at a system
view and see if there's a newer one, but it's a little awkward. A
validity period is a good fit if all passwords have a validity period
and we don't change it, but gets awkward otherwise.
I'm also worried about two kinds of clutter:
* old passwords not being garbage-collected
* the identifier of the current password always changing (perhaps fine
if it'a a "created at" ID?)
Regards,
Jeff Davis
