User Management
Readyset keeps its own set of users that are allowed to authenticate with it. That set has two stages in its life: it is seeded from command-line flags the very first time a deployment starts, and from then on you manage it with SQL against a running Readyset, with no restart and no dropped connections.
Bootstrap on the first startup
On a deployment's first startup, Readyset seeds the allowed-users set from two places:
- The user in
--upstream-db-url, so the credentials Readyset already has can also be used to connect to it. --allowed-users(envALLOWED_USERS), a comma-separated list ofusername:passwordpairs.
readyset --upstream-db-url postgresql://readyset:<password>@db.internal/app \
--allowed-users 'alice:<password>,bob:<password>'That start accepts readyset, alice, and bob.
Seeding happens once. Readyset then stores the set and reads it from
storage on every later start, so editing --allowed-users or pointing
--upstream-db-url at a different user has no effect on who may
authenticate. After the first startup, use the commands below.
Managing users at runtime
Connect to Readyset as any allowed user and run:
ALTER READYSET ADD USER 'carol' PASSWORD 'carolpw';
ALTER READYSET MODIFY USER 'carol' PASSWORD 'rotatedpw';
ALTER READYSET DROP USER 'carol';Each command is stored before it returns, so it survives restarts, and takes effect on the next connection attempt: an added user can connect right away, a rotated password is required immediately, and a dropped user is refused. A dropped or rotated user's connections that are already open are not closed; the change applies when they reconnect.
ADD USER fails if the user
already exists;
MODIFY USER and
DROP USER fail if it does not.
The user derived from --upstream-db-url cannot be modified or dropped, since
that identity backs Readyset's own connection to your database. All three
commands require
authentication to be enabled, so they are
unavailable under --allow-unauthenticated-connections.
A user in Readyset also needs to exist in your database with the same
password. Readyset opens each session's connection to your database with
that session's own credentials, so ALTER READYSET ADD USER is a companion
to a CREATE USER upstream, not a replacement for it.
Listing the current users
The readyset.users system view lists
the usernames that may authenticate right now, including runtime changes.
Passwords are never exposed.
SELECT "user" FROM readyset.users;user is a reserved word in PostgreSQL, so quote the column there; on MySQL
SELECT user FROM readyset.users works unquoted.
How it fits with the rest of Readyset
Authentication verifies each connection
against this set, whichever method the client protocol negotiates. On MySQL,
caching_sha2_password keeps a per-user fast-auth digest; MODIFY USER and
DROP USER clear it as part of the change, so a rotated password cannot be
bypassed by a client that authenticated earlier.
Cache authorization decides which users
are served from a cache, by asking your database what each of them is allowed
to read. ADD USER and MODIFY USER schedule that check for the new user, so
they start getting cache hits as soon as their privileges are confirmed;
DROP USER forgets them. Until then their queries are simply proxied to your
database.