2 Commits

Author SHA1 Message Date
Stéphane Tailland eed8c3da3b refactor(realm): rename the token-exchange broker, drop the middleware's name
Every agent has to name this client in the audience scopes it requests, so the
one thing an agent could not avoid naming was the very thing it should know
nothing about. The gateway serving those URLs is replaceable; the contract
should not imply otherwise.

kong-token-exchange-broker becomes token-exchange-broker, same credential, same
behaviour. The rename was rolled out in order — new client alongside the old,
then the callers, then the gateways, then removal — so no call ever hit a realm
that had forgotten the name its caller was still using. Followed through the
client scope, the audience mappers, the fine-grained admin policy
allow-broker-client, and the roles map.

The Vault property keeps the old name. Renaming it there means re-issuing the
value to every gateway holding a copy, for no gain; the ExternalSecret maps it
to KC_SECRET_TOKEN_EXCHANGE_BROKER instead, so everything the cluster can see
is neutral.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 07:52:58 +02:00
Stéphane Tailland f9900a5fb9 Take the realm's client secrets and user passwords out of git
configmap-realm.yaml carried fourteen client secrets and five user
passwords in clear, in a tracked file. Five were there from its first
commit; I added the fourteenth yesterday by following the existing pattern
without questioning it. Making this file authoritative on every start did
not increase the exposure, but it did make the file the place those
secrets live for good — and it is inconsistent with the rest of the
estate, where infra-observability and kong-v2 both take theirs from Vault.

Keycloak resolves ${PLACEHOLDER} in a realm import file from the
environment, so the structure stays in git and the values move to Vault at
secrets/keycloak/classic-models-realm, reaching the import container
through External Secrets.

A store of its own, vault-keycloak, rather than reusing vault-kong-v2 or
vault-observability: each carries a policy scoped to its own path, so a
reader for one estate cannot see another's. Widening an existing policy
would have handed Kong's reader every client secret in the realm.

dataFrom.extract pulls the whole path, so adding a client means adding its
secret in Vault with no edit to the ExternalSecret.

Verified after the switch: the import logs "Realm 'classic-models' imported"
under OVERWRITE_EXISTING, and all three credential paths still work — the
broker's client_credentials, librechat with pm-user's password, and the
Catalogue agent's exchange reaching catalog-mcp with 200. Re-checked that
none of the nineteen original values appears anywhere in the file.

Note the values themselves were committed and are in this repo's history.
They are lab credentials behind a private CA with no real data, but they
should be rotated if that ever stops being true.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 10:13:40 +02:00