Move the gateway entrypoints into the domain namespace

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>

dev/api-gateway/bootstrap-kustomization.yaml

@@ -0,0 +1,24 @@
+# Watches ./dev/api-gateway so the entrypoints in it — the GitRepository above,
+# the gateway and policies Kustomizations, the ExternalSecrets — reconcile from
+# git instead of waiting on a kubectl apply. Lives in that directory, so it
+# manages itself.
+#
+# In the workforce namespace, not flux-system. The gateway Kustomizations sat in
+# flux-system only because postBuild.substituteFrom reads a ConfigMap from its
+# own namespace and dataplane-template-defaults existed nowhere else. That
+# ConfigMap is now in every domain namespace, so the constraint is gone and the
+# team can own its own gateway.
+#
+# Apply once with kubectl. That is the last manual apply this repo needs.
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: dataplane-workforce-dev-bootstrap
+  namespace: workforce
+spec:
+  interval: 10m
+  sourceRef:
+    kind: GitRepository
+    name: dataplane-workforce-dev
+  path: ./dev/api-gateway
+  prune: true

dev/api-gateway/externalsecret-control-plane.yaml

@@ -1,3 +1,8 @@
+# Moved out of flux-system with the Kustomization that reads it. It only ever
+# lived there because postBuild.substituteFrom resolves in the Kustomization's
+# own namespace, and that Kustomization had to be in flux-system to reach
+# dataplane-template-defaults. Both now sit in the domain namespace, so the
+# control-plane id no longer transits a shared namespace at all.
 # The Control Plane id, delivered to flux-system so gateway-kustomization.yaml
 # can substitute it instead of carrying a hardcoded UUID.
 #
@@ -13,7 +18,7 @@ apiVersion: external-secrets.io/v1
 kind: ExternalSecret
 metadata:
   name: workforce-dev-control-plane
-  namespace: flux-system
+  namespace: workforce
 spec:
   refreshInterval: 1h
   secretStoreRef:

dev/api-gateway/gateway-kustomization.yaml

@@ -2,12 +2,17 @@ apiVersion: kustomize.toolkit.fluxcd.io/v1
 kind: Kustomization
 metadata:
   name: workforce-dev-api-gateway
-  namespace: flux-system
+  namespace: workforce
 spec:
   interval: 10m
   sourceRef:
     kind: GitRepository
     name: k8s-platform
+    # k8s-platform lives in flux-system: the templates are the platform's,
+    # this Kustomization is the team's. sourceRef resolves in the
+    # Kustomization's own namespace unless told otherwise, hence the
+    # explicit namespace rather than a copy of the source per domain.
+    namespace: flux-system
   path: ./dataplane-template
   prune: true
   postBuild:

dev/api-gateway/gitrepository.yaml

@@ -0,0 +1,20 @@
+# This repo, as a source Flux can read. It had none: its Kustomizations point at
+# k8s-platform for the templates, and nothing ever needed to read the repo that
+# declares them — because those declarations were applied by hand.
+#
+# Reuses the domain's existing deploy key rather than minting a new one, having
+# verified that key reads the dataplane repositories. Worth knowing what that
+# implies: the key is not scoped to a single repository, so the isolation its
+# per-repo name suggests does not exist.
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: GitRepository
+metadata:
+  name: dataplane-workforce-dev
+  namespace: workforce
+spec:
+  interval: 5m
+  url: ssh://git@gitea.sttlab.eu:2222/stt/kong-dataplane-workforce.git
+  secretRef:
+    name: workforce-api-git-auth
+  ref:
+    branch: main

dev/api-gateway/policies-kustomization.yaml

@@ -2,12 +2,17 @@ apiVersion: kustomize.toolkit.fluxcd.io/v1
 kind: Kustomization
 metadata:
   name: workforce-dev-api-gateway-policies
-  namespace: flux-system
+  namespace: workforce
 spec:
   interval: 10m
   sourceRef:
     kind: GitRepository
     name: k8s-platform
+    # k8s-platform lives in flux-system: the templates are the platform's,
+    # this Kustomization is the team's. sourceRef resolves in the
+    # Kustomization's own namespace unless told otherwise, hence the
+    # explicit namespace rather than a copy of the source per domain.
+    namespace: flux-system
   path: ./dataplane-globalpolicy-template
   prune: true
   postBuild: