T

Stéphane Tailland 3b20b0a35b Revert stream-binding approach: merge GET into the single MCP route instead

The second ai-mcp-proxy binding (added to fix the GET/SSE 502 loop)
created a second runtime plugin instance with the same tool config,
which ai-mcp-proxy's own duplicate-name detection caught: all three
tools (list-customers/get-customer/create-customer) fell back to
auto-generated names across both instances. Confirmed via dataplane
pod logs right after applying the previous fix.

Real fix: one KongRoute for all three MCP HTTP methods (GET/POST/
DELETE) instead of two, one ai-mcp-proxy binding instead of two.
ai-mcp-proxy already tolerates multi-method routes (same "skips
method selection" notice the existing POST+DELETE route already
produces) — extending to GET is the same class of thing, not new
risk, and there is now exactly one plugin instance so no duplicate
tool names.

2026-08-23 15:39:27 +02:00

dev

Addition of MCP server

2026-08-23 15:00:57 +02:00

kong

Revert stream-binding approach: merge GET into the single MCP route instead

2026-08-23 15:39:27 +02:00

.gitignore

first commit

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

README.md

Build customers-api REST layer (Layer 3), mirroring catalog-api

2026-08-23 14:34:47 +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 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.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.