T

Stéphane Tailland 63d2d90107 refactor(mcp): generate the tool definitions from the spec

Produced by k8s-platform/tools/generate-mcp-tools.py: deck file openapi2mcp
does the conversion, and the wrapper re-injects the five things Kong's
generator cannot emit — per-tool ACLs, the MCP behavioural annotations, the
response schemas the plugin uses for structuredOutput, the real upstream host,
and JSON-only request bodies. Each is a documented gap; see
k8s-platform/MCP-TOOL-GENERATION.md.

tools-policy.yaml carries the ACLs and doubles as the allow-list: an operation
becomes a tool only if the policy names it. Kong would otherwise expose every
operation in the spec, DELETE included, and can express no authorization at all
from a bearer-token spec — silently, exit 0, no warning.

Same tools as before, same ACLs. What changed: query parameters are now
declared and callable, each tool carries its response schema so calls return
structured content instead of raw JSON, and request bodies are no longer
tripled across three identical content types.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-29 08:48:38 +02:00

dev

refactor: rename the token-exchange broker to drop the middleware's name

2026-08-29 07:40:06 +02:00

kong

refactor(mcp): generate the tool definitions from the spec

2026-08-29 08:48:38 +02:00

.gitignore

first commit

2026-08-23 14:39:25 +02:00

openapi.yaml

Add the OpenAPI spec for the customers domain

2026-08-26 18:28:25 +02:00

README.md

docs: follow the token-exchange broker rename

2026-08-29 07:52:56 +02:00

README.md

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 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.yaml files 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.