T

Stéphane Tailland e9997c360e feat(mcp): authorise tool-call parameters, not just the tool name

The ACL answers 'may this identity call create-product'. Nothing answered 'may
it call it with these arguments' — write authorises writing, not this
particular record. And the read cap counts calls, so one call asking for a
hundred thousand rows cost the same as one asking for ten.

The OPA plugin sends the decoded JSON-RPC body, so the decision point sees the
tool name and its arguments. The policy lives once in k8s-platform/opa and every
domain asks the same server.

Enforced at the gateway rather than in an agent, because an agent that has been
talked into something is the case this exists for.

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

2026-08-29 18:09:16 +02:00

dev

feat(mcp): cap read volume per caller identity

2026-08-29 18:05:48 +02:00

kong

feat(mcp): authorise tool-call parameters, not just the tool name

2026-08-29 18:09:16 +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.