Rethink how we handle postgresql passwords in cookbooks
Summary
I know we are working on password vaults approach in parallel, but I want to make a simpler intermediate step here that will probably come in hand when we arrive at the vault approach.
In postgresql
cookbook, we require the user to pre-compute a hashed version of the password for sql_user_password
and sql_replication_password
, using MD5 algorithm (with the help of gitlab-ctl
CLI). I don't remember why we decide to go this route, but I assume it has something to do with not keeping the plaintext version of it.
I believe we have not succeeded in that area as we still need to provide the plaintext version for rails in : gitlab_rails['db_password']
. This also adds an extra step in configuring a new instance, because you not only have to generate a MD5 on the command line but you endup providing the plaintext version anyway.
For the sql_replication_password
there is now the extra step to also provide the plaintext version for patroni, as patroni requires the plain version to generate a pgpass
file (it seems it doesn't work with hashed version anyway).
This approach is not only inefficient as we can't reuse the password define before, but it's outdated/problematic as we can't upgrade users to the new SCRAM-SHA-256
.
Proposal
We should stop asking for a MD5 hashed version of the password as we can generate them anyways ourselves, and rely on the plaintext for everything.
There are two possible approaches we can take. We can use regexp to identify if provided sql_user_password
and sql_replication_password
look like md5 hashes or not (size and characters used), and based on that know if we can reuse that password in gitlab_rails['db_password']
or with patroni, and based on that know if we need to compute a hash ourselves.
Another posssible approach would be to create new fields all together: sql_user_plaintext_password
and sql_replication_plaintext_password
and deprecate the use of the old one.