jochen
942ebe350f
Overlap as drafted in 0113 would have deleted consumer data: seven of eight providers name the resource after the login and five drop it on remove. Rotation is now undecided in 0113 and to-be 27, pending the survey. Also: a requirement naming a seat resolves to its holder, a person chooses among remaining candidates at assignment, the controller's secrets are requirements of its definition, genesis seals to the control-node key, and moving the vault or broker is break-glass.
72 lines
6.6 KiB
Markdown
72 lines
6.6 KiB
Markdown
# 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](../../02-DECISIONS/0049-a-consumers-identity-fits-the-tightest-backend.md)).
|
|
|
|
| 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.
|