hq/01-RESEARCH/016-how-a-credential-can-be-rotated/01-the-providers.md

01 — The providers

Read from the catalogue's main branch: each provider's provisioner adapter (create, remove), the client functions they call, and each definition's own credentials. The provisioner harness in mesh-sdk calls create for a consumer when its contribution appears or changes, and after the provisioner restarts, and remove when the contribution goes. Its record of what was applied is kept in memory.

The credential providers

login is the consumer's derived identity, which the adapter receives as as (ADR 0049).

provider	the consumer's resource is named	remove destroys	create re-applies the password	two secrets on one login	two logins on one resource
postgres	a database named login, owned by the role login	the database and the role	yes, ALTER ROLE … PASSWORD when the role exists	no: a role has one password	yes, both as members of one role that owns the database. Not done today
mssql	a database named login, with the login mapped into it	the database and the login	yes, ALTER LOGIN … WITH PASSWORD	no: a login has one password	yes, two logins mapped to users in db_owner. Not done today
mongodb	a database named login, with a user holding dbOwner	the database and the user	yes, updateUser with the new password	no: a user has one credential	yes, two users with dbOwner on one database. Not done today
redis	the key prefix login: on an ACL user named login	the user, not its keys	yes: ACL SETUSER … reset … >password replaces all of them	yes: an ACL user holds several passwords, added with > and removed with <. Today's reset discards all but the new one	yes, two users on one key prefix, once the prefix is not the login
minio	a bucket derived from login, and a service account whose access key is login	the access key and the bucket	yes, by removing the access key and adding it again	no, but an access key is the login: a second key is a second login	yes, two service accounts with one bucket policy. The access key is capped at 20 characters
lavinmq	a virtual host named login, and a user named login with permissions on it	the virtual host and the user	yes, the user is written again with the password	no: a user has one password	yes, permissions for two users on one virtual host
mosquitto	a client named login, with a role named for it on the topic prefix login/#	the client and its role	yes, the password is set when the client exists	no: a client has one password	yes, two clients holding one role, once the prefix is not the login. An MQTT client identifier still has to be unique per connection
gitea (npm)	a user named login on a team of an organisation that owns every package	the user; packages survive, because the organisation owns them	yes, the user's password is set on every run	no for the password; a user can hold several access tokens	yes, trivially: a second member of the same team

The other providers

provider	answers with	credential
umami	a website, found by its public name	none. The site id it makes has no way back to the consumer today
cloudflare-dns	a public name derived from login	none handed to the consumer; its own API token is an operator value
showcase	a route	none
mesh-vault	custody: it records and withdraws sealed values in a ledger	it holds secrets; it makes none today

Each provider's own administrative credential

provider	identity	how the backend takes it
postgres	a fixed superuser	from a file only at first initialisation. Afterwards the file is read by the provisioner to connect, and changing it changes nothing in the database
mssql	sa	from the environment at first setup. The image documents no file form, and the definition records that as a declared exception
mongodb	a fixed root	from a file only at first initialisation, when the data directory is empty
redis	the default user	from requirepass in a configuration the mesh renders, read when the server starts
minio	a fixed root user	from a file, read when the server starts
lavinmq	a fixed admin name	from the module's own secret, which its provisioner connects with
mosquitto	a fixed admin client	from the module's own secret, which its provisioner connects with; the broker's dynamic-security file holds it

Every provider module also has its own bus account, an own secret, read at start.

What the table shows

1. Every credential provider already rotates in place. All eight re-apply the password on the same login each time create runs. The controller's rotate command relies on that: it replaces the credential in the inventory and sends both ends in one push. Its own comments state the window, between the provider applying and the consumer restarting, in which the consumer cannot authenticate.
2. Seven of eight name the consumer's resource after its login. Only gitea separates them, because an organisation owns the packages. A second login therefore has no resource of its own to reach, and cannot share the first one's without the adapter granting it.
3. Five of eight destroy the resource when they remove the login. These are postgres, mssql, mongodb, minio and lavinmq. In today's adapters, retire a login and delete the consumer's data are one call. This is the fault the first overlap draft would have triggered.
4. Only redis holds two passwords on one login, and gitea through tokens rather than its password. A rotation built on two secrets per login would work for one provider out of eight.
5. Every backend can give two logins the same rights over one resource. Group roles in postgres, database roles in mssql and mongodb, permissions in lavinmq, a shared role in mosquitto, a shared policy in minio, a shared key prefix in redis, a shared team in gitea. No adapter does it today.
6. The administrative credentials have one party and a fixed name. The provider module is both the one that applies the credential and the only one that reads it. In postgres, mongodb and mssql, a new value only takes effect through a command run with the old value. A restart changes nothing.
7. A consumer's identity is already the resource's name. The login is derived from the assignment, which is a module on a node, so the current login and "the consumer" are the same string today. A second login would need a new name. The resource can keep the one it has.