Centralis has shipped the OAuth 2.1 authorization server since b194603, but
prod ran with none of it configured, so the connector could only offer a
bearer token. buildOAuth() needs a Google client AND a team list; this adds
both, plus the Workspace domain.
CENTRALIS_TEAM is an allowlist of addresses, not a domain or group rule --
a rule keyed on the domain grants production reads to anyone who can get an
address in it, and the group equivalent moves that authority to whoever
administers the group. Four addresses, listed:
emi.g owner jin.j owner
klaudia.j member violet.g member
Roles are real gates. owner is everything, including run_on_host, secrets_*,
promote and SQL writes; member is the estate's reads plus the writes that
become PRs. Identity is re-resolved from this value on every request rather
than trusted from the token, so removing a line and restarting revokes
someone at once.
The audit subjects these derive to -- emi.g, jin.j -- deliberately differ
from the CENTRALIS_TOKENS subjects emi and jin. The token registry is for
machines now, so a distinct subject is what makes an audit line answer
whether a person or a cron job did something.
CENTRALIS_GOOGLE_HOSTED_DOMAIN is set because every address is in the
Workspace. It is checked server-side as well as hinted to Google, so it
narrows who can reach the allowlist; it never populates it.
Verified before commit: the vault renders 13 keys that survive
`set -a; . <file>` byte-for-byte, and the rendered CENTRALIS_TEAM parses to
exactly the four members and capabilities above.
a981729417