Password rotation

[marceloneppel]

Issue

• Database charms should enable the human operator to rotate any system user (users that are need for the correct operation of the charm and/or the workload, like a superuser, a replication user, etc.) password.

Solution

• Create an action to set system users passwords and propagate that password to all the other units.

Context

• Users created through relations (legacy or new relations) are not covered by this mechanism. Those users will have the password rotated after a sequence of a broken relation and a new relation being established.
• When updating a password using the set-password action, that password need to be update in the Patroni configuration (which also needs to be reloaded). The configuration is reloaded in the leader unit first and later on the other units (through relation changed event; that event already handles Patroni configuration changes and its reload process). There is no downtime in that processes.
• Pebble service environment variables like PATRONI_REPLICATION_USERNAME and PATRONI_SUPERUSER_PASSWORD were moved to the configuration file to make it possible to update and reload them. Other variables should be moved to there in the future.
• The new integration test from tests/integration/test_password_rotation.py rotate the two system users password and checks that they are correctly updated in all the units (which is checked after restarting Patroni; it would trigger an connection error in the Patroni process if the password is not updated).

Testing

• Unit and integration tests were updated based in the new actions.
• Additional unit and integration tests were added to validate the password rotation mechanism.

Release Notes

• Add password rotation mechanism for all system users (users used by the charm/workload and that were not created through relations).

[paulomach]

lgtm

[paulomach]

lgtm

[shayancanonical]

the set_password action has no password params defined

[marceloneppel]

Good catch! Fixed on 4be4ed0.

[paulomach]

lgtm