Stéphane Tailland
b0e8cf8796
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-customers
Layer 2 (Gateway infrastructure) for the customers bounded context (domain team: customers) — one Control Plane per environment, referenced by ID (created manually in Konnect for now, never recreated here).
This repo does NOT hold KonnectAPIAuthConfiguration/GatewayConfiguration/
Gateway/Certificate YAML directly. The actual resource template (one
copy, covering every domain/environment) lives in
../k8s-platform/dataplane-template/, ${VAR}-parameterized. This repo
only holds what's specific to one <env>/<gateway-type>/ — same
gateway-kustomization.yaml / externalsecret.yaml / policies-kustomization.yaml
three-file pattern as dataplane-catalog (see that repo's README for the
full explanation of each file's role — identical here, not repeated).
IdP: the openid-connect policy's OIDC_ISSUER (in
dev/api-gateway/policies-kustomization.yaml) points at the local
in-cluster Keycloak (ns keycloak, https://keycloak.sttlab.local/realms/classic-models,
deployed 2026-08-23 — config-as-code source in the separate infra-keycloak
repo). Not a customers-specific choice: catalog/classic-models-api/
librechat were migrated to the same local Keycloak the same day (see
../STATUS.md section 15) — the old VPS Keycloak (keycloak.sttlab.eu) is
being phased out platform-wide, customers was just built against the
local one from the start rather than migrated later. The
dataplane-template-defaults ConfigMap's cluster-wide OIDC_ISSUER default
still hasn't been updated to match (still the stale VPS value) — every
domain currently overrides past it individually; see ../STATUS.md
section 16 for that gap.
Only dev/ is real. staging/api-gateway/ and prod/api-gateway/
still hold the original TODO placeholder files (dataplane.yaml,
konnectextension.yaml) from before this pattern existed — 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 yet. The Layer 3 repo (../customers-api, the
KongService/KongRoute/plugin definitions that would route real traffic
to the backend, same role as ../catalog-api plays for catalog) is
still just two # TODO placeholder files, not deployed — kubectl get kongservice,kongroute -n customers returns nothing. A request to
customers-dev.sttlab.local would 404, not route anywhere.
Self-service pipeline (../konnect-platform generating this content
automatically) does not exist yet — still a stub per ../STATUS.md.
Everything here is hand-maintained, same as dataplane-catalog.