Every address the plugin publishes hands out, or acts on, the connection
string that opens a database, and that string carries the PostgreSQL
password the plugin holds. Register now returns on a Config that is not
Enabled, so /v1/cloud-sql and /v1/meta are addresses an unconfigured
process does not answer at rather than addresses it refuses at.
Opt in with CLOUD_SQL_ENABLED=true, the way bootnode and calendar opt in:
an Enabled field, a ConfigFromEnv that reads it, and a Register that
returns early without it.
ConnectionString supplies require for a database that states no mode. The
create path wrote a mode of its own beside it and wrote disable, so a
handed-out connection string turned TLS off. It writes none now, and the
default is the only answer.
Every address under /v1/cloud-sql and /v1/meta answers about one org's
database, and a database is reached with the password that opens it. So
the org is the one the door resolved from the verified credential —
published on the event by whichever door read it, an IAM token over JWKS
or an IAM key — and a request that carries none is refused before a
handler runs.
The rule is stated once per group, so a route added to either group
inherits it, and each handler asks the same question again for the value:
the list filters on that org, the routes taking {id} check the row belongs
to it, and create files the row under it rather than under whatever the
body said.
The meta proxy forwards on the connection that opens ONE database, so
every statement postgres-meta runs runs inside that database. An org with
no database of its own gets that answer; the admin connection opens every
database on the server and is lent to nobody.
Co-authored-by: Hanzo Dev <[email protected]>
zeekay
