dev/ declares this repo's GitRepository, the Kustomization that deploys ./kong, and its ExternalSecrets — but nothing watched dev/, so those files were applied once by hand and never re-read. Editing them in git changed nothing until someone remembered to kubectl apply, which is what silently swallowed the CONTROL_PLANE_REF_NAME rollout: correct in git for hours while the cluster still held the old value. Add the bootstrap Kustomization that watches ./dev and, living in ./dev, manages itself. This is what `flux bootstrap` would have created; flux-operator installs the controllers and no root. It sits in the domain namespace rather than flux-system, because sourceRef resolves in the Kustomization's own namespace and because this is the team's to own. Needs one kubectl apply to exist. That is the last one this repo needs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
customers-api
Kong routing/policy layer for the customers slice of
classic-models-api (see /Users/stephanetailland/git/classic-models-api),
split out per the DDD decomposition in ../kong-konnect-deployment-strategy.md.
The backend itself stays a single monolith — only Kong does the domain
split. Same role as ../catalog-api plays for catalog, structure
deliberately mirrored.
REST only for now (kong/rest/) — 8 routes covering
Customer plus its orders/payments sub-resources (cross-domain reads,
same backend). No MCP surface yet, unlike catalog-api — add one
(kong/mcp/, a mcp-customers Keycloak audience/client-scope, an entry in
dataplane-customers's JWT_AUDIENCE_WHITELIST) the same way if/when this
domain needs an MCP entry point.
| Route | Method | Backend path |
|---|---|---|
/customers/v1/customers/ |
GET, POST | /classic-models/api/v1/customers/ |
/customers/v1/customers/{customernumber}/ |
GET, PUT, PATCH, DELETE | /classic-models/api/v1/customers/{customernumber}/ |
/customers/v1/customers/{customernumber}/orders/ |
GET | /classic-models/api/v1/customers/{customernumber}/orders/ |
/customers/v1/customers/{customernumber}/payments/ |
GET | /classic-models/api/v1/customers/{customernumber}/payments/ |
Auth
openid-connect on the REST service, audience_required/token-exchange
target = classic-models-api (BACKEND_AUDIENCE). Unlike catalog-api,
there's no MCP hop minting an intermediate customers-api-audience token
today — a caller gets one directly via kong-token-exchange-broker
(customers-api-audience client scope, added there 2026-08-23) and calls
these routes with it; the REST-layer plugin then exchanges that token again
to classic-models-api before it reaches the backend, same second-hop
pattern as catalog-api's REST layer. IdP is the local Keycloak
(https://keycloak.sttlab.local/realms/classic-models) — see
../dataplane-customers/README.md and ../STATUS.md sections 15/16 for
why (platform-wide migration off the VPS Keycloak, not customers-specific).
consumer_claims/consumer_by map the JWT sub to a Kong Consumer for
per-consumer rate limiting, same as catalog-api.
Other policies
Per-consumer rate limiting, response caching (GET/HEAD), audit log
(http-log, endpoint still a placeholder — no real log collector in this
lab, same caveat as catalog-api).
Structure
Same three-piece dev/ layout as catalog-api: dev/gitrepository.yaml +
dev/flux-kustomization.yaml (deploys ./kong into the customers
namespace's dev environment, dependsOn dataplane-customers's Gateway
Kustomization), dev/externalsecret.yaml (git deploy key),
dev/token-exchange-broker-externalsecret.yaml (the broker's client
secret). kong/rest/ — service, routes, path-rewrites, auth/rate-
limit/cache/audit-log policies and their bindings.
Not deployed yet — blocked on one external step: the gitea repo
kong-customers-api.git this dev/gitrepository.yaml points at doesn't
exist (https://gitea.sttlab.eu/stt/kong-customers-api → 404 as of
2026-08-23). A dedicated deploy keypair was generated and stored in Vault
(kong-v2/customers-api/git-deploy-key) as if it did — once the repo
exists and that key is registered as its deploy key, this content needs to
be pushed to it, then dev/gitrepository.yaml + dev/flux-kustomization.yaml
- the two
dev/*externalsecret.yamlfiles applied to the cluster.kong-v2/customers-api/token-exchange-broker(the broker's client secret, copied from the live local Keycloak) is already stored in Vault and ready.