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>
48 lines
2.1 KiB
YAML
48 lines
2.1 KiB
YAML
# sourceRef points at the GitRepository "k8s-platform" (created once,
|
|
# flux-system) — any domain's Kustomization can reference this same
|
|
# object, no monorepo: k8s-platform and dataplane-payments stay two
|
|
# separate repos, `path` below is relative to the root of whichever repo
|
|
# `sourceRef` names.
|
|
apiVersion: kustomize.toolkit.fluxcd.io/v1
|
|
kind: Kustomization
|
|
metadata:
|
|
name: payments-dev-api-gateway
|
|
namespace: payments
|
|
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:
|
|
# Domain-specific non-sensitive values inline — no separate ConfigMap to
|
|
# forget to re-apply after an edit. Inline substitute always wins over
|
|
# substituteFrom regardless of order, so this still overrides
|
|
# dataplane-template-defaults where needed.
|
|
substitute:
|
|
NAME: payments-dev
|
|
NAMESPACE: payments
|
|
HOSTNAME: payments-dev.sttlab.local
|
|
# Cluster-wide defaults only — the Konnect PAT is NOT handled via
|
|
# substitute/substituteFrom at all: that mechanism requires the source
|
|
# Secret to sit in flux-system (same namespace as this Kustomization),
|
|
# which put a live copy of the real PAT in a shared, broadly-readable
|
|
# namespace. Rejected. The real konnect-auth Secret is materialized
|
|
# directly into the payments namespace instead (externalsecret.yaml, via
|
|
# External Secrets Operator + Vault) — never passes through flux-system.
|
|
substituteFrom:
|
|
- kind: ConfigMap
|
|
name: dataplane-template-defaults
|
|
# CONTROL_PLANE_ID comes from Vault via ESO instead of being hardcoded
|
|
# here: a new Konnect org then needs no edit in this repo. Not a secret —
|
|
# the id is visible in the Konnect UI URL — so flux-system is fine for it,
|
|
# unlike the token.
|
|
- kind: Secret
|
|
name: payments-dev-control-plane
|