Stéphane Tailland
3c5025ee52
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 to catalog. The id no longer transits a shared namespace either, which was a compromise this repo documented rather than liked. Adds the GitRepository this repo never had — its Kustomizations point at k8s-platform for templates, and nothing needed to read the repo that declares them, because those declarations were applied by hand. It reuses the domain's existing deploy key rather than minting one; verified that the key reads this repository. Worth knowing what that implies: the key is not scoped to a single repo, so the isolation its per-repo name suggests does not exist. And the bootstrap Kustomization that watches ./dev/api-gateway, so all of it reconciles from git from now on. Migration is not a patch: a namespace is immutable, so the existing objects have to be deleted and recreated. Deleting a Kustomization with prune enabled would take its Gateway, GatewayConfiguration and mirror CR with it, so prune has to be turned off on the old objects first, then the new ones adopt what is already running. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
43 lines
1.9 KiB
YAML
43 lines
1.9 KiB
YAML
# sourceRef points at the GitRepository "k8s-platform" (created once,
|
|
# flux-system, see ../../../k8s-platform/flux/gitrepository.yaml) — any
|
|
# domain's Kustomization can reference this same object, no monorepo:
|
|
# k8s-platform and dataplane-catalog 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: catalog-dev-api-gateway
|
|
namespace: catalog
|
|
spec:
|
|
interval: 10m
|
|
sourceRef:
|
|
kind: GitRepository
|
|
name: k8s-platform
|
|
path: ./dataplane-template
|
|
prune: true
|
|
postBuild:
|
|
# Domain-specific non-sensitive values inline — no separate ConfigMap to
|
|
# forget to re-apply after an edit (bit us twice already). Inline
|
|
# substitute always wins over substituteFrom regardless of order, so
|
|
# this still overrides dataplane-template-defaults where needed.
|
|
substitute:
|
|
NAME: catalog-dev
|
|
NAMESPACE: catalog
|
|
HOSTNAME: catalog-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 catalog 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. Both this
|
|
# Secret and this Kustomization are in the domain namespace now, so the
|
|
# id no longer has to pass through flux-system to be substitutable.
|
|
- kind: Secret
|
|
name: catalog-dev-control-plane
|