Stéphane Tailland
c07e3c5f1d
The gateway and policies Kustomizations sat in flux-system, and so did the Secret carrying the control-plane id. Neither was a governance decision: postBuild.substituteFrom resolves only in the Kustomization's own namespace, dataplane-template-defaults existed only in flux-system, so everything that needed it had to live there too — in a namespace the feature team has no access to. The team could not touch its own gateway. k8s-platform now places that ConfigMap in every domain namespace, so the constraint is gone. Move both Kustomizations and the control-plane ExternalSecret into the domain namespace; the id no longer transits a shared namespace either. sourceRef gets an explicit namespace: flux-system, because it resolves in the Kustomization's own namespace and k8s-platform is not there. Naming it beats duplicating the source per domain, and the split is the point — templates belong to the platform, the Kustomization consuming them belongs to the team. Verified on catalog first: without this the moved objects report "GitRepository k8s-platform not found". Adds the GitRepository this repo never had, reusing the domain's existing deploy key; that key was verified to read the dataplane repositories, which also means it is not scoped to one repo. And the bootstrap Kustomization watching ./dev/api-gateway, so all of it reconciles from git from now on. Migration is not a patch: a namespace is immutable, so these objects are deleted and recreated. Deleting a Kustomization with prune enabled would take its Gateway, GatewayConfiguration and mirror CR with it, so prune is turned off on the old objects first and the new ones adopt what is already running. Done that way on catalog with no pod restart and no Kong entity lost. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dataplane-payments
Layer 2 (Gateway infrastructure) for the payments bounded context
(domain team: payments) — one Control Plane per environment, referenced by
ID (created manually in Konnect for now, never recreated here:
dc3b2a36-e2ad-4da1-a142-022d0ce6d94e for dev).
Same gateway-kustomization.yaml / externalsecret.yaml /
policies-kustomization.yaml three-file pattern as dataplane-catalog and
dataplane-customers — see dataplane-catalog/README.md for the full
explanation of each file's role, identical here, not repeated. Actual
resource template lives in ../k8s-platform/dataplane-template/ and
../k8s-platform/dataplane-globalpolicy-template/, this repo only holds
what's specific to dev/api-gateway/.
IdP: https://keycloak.sttlab.local/realms/classic-models (local
in-cluster Keycloak), same platform-wide default as catalog/customers
— see ../STATUS.md sections 15/16. JWT_AUDIENCE_WHITELIST is
["payments-api"] only so far; no payments-api Keycloak client/audience
scope exists yet either (Layer 3 not built) — that whitelist entry is
forward-looking, matches nothing real yet.
Only dev/ is real. staging/api-gateway/ and prod/api-gateway/
still hold the original TODO placeholder files, not converted, not
deployed, no Control Plane created for them yet.
This is Layer 2 (Gateway infrastructure) only — no API is actually
reachable through it. Gateway payments-dev: Programmed: True,
DataPlane pod running, TLS cert issued, DNS entry added to
coredns-custom (same manual per-domain step documented in
../STATUS.md section 17 — not automatic). Smoke-tested: 404 (Gateway
answers, nothing routed — correct, expected). No Layer 3 repo
(../payments-api) exists yet; when it does, follow ../customers-api's
structure as the reference, not ../catalog-api's (customers is the more
recently corrected/simpler pattern — REST-only until an MCP layer is
actually needed, single merged MCP route if one is added — see
../STATUS.md section 18 for why).
Self-service pipeline (../konnect-platform generating this content
automatically) does not exist yet — still a stub per ../STATUS.md.
Everything here is hand-maintained.