From 2c25b6d375082585ea406616b77dadeca5d02a01 Mon Sep 17 00:00:00 2001 From: jordan Date: Tue, 15 Sep 2026 22:13:30 -0600 Subject: [PATCH] docs(k8s): record the CA-copy coupling for the GKE overlay MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The consumer needs the cluster's CA and Secrets do not cross namespaces, so ca.crt has to be copied into peach's namespace. A copied certificate deserves suspicion — k3s-fleet's own history records an incident where the expired central SDLC wildcard was copied manually and never renewed into its consumer namespaces — so the numbers are written down rather than assumed: tidaldb-cluster-ca 87600h (10y), renewBefore 8760h (1y), isCA tidaldb-cluster-tls 2160h (90d), renewBefore 720h (30d) The 90-day LEAF is what rotates, roughly every 60 days, and it rotates under this same root, so the copied CA keeps verifying it with no attention. The fleet incident was an expiring leaf; this is a decade-lived root. The coupling that actually bites is recreation, not expiry: the root is self-signed and minted fresh on first apply, so destroying and re-applying the namespace invalidates every copy at once and every consumer request then fails TLS with nothing visibly wrong on either side. Recorded as a mandatory step of any recreate. --- k8s/cluster-gke-peach/kustomization.yaml | 25 ++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/k8s/cluster-gke-peach/kustomization.yaml b/k8s/cluster-gke-peach/kustomization.yaml index 518934b..30e0d80 100644 --- a/k8s/cluster-gke-peach/kustomization.yaml +++ b/k8s/cluster-gke-peach/kustomization.yaml @@ -84,6 +84,31 @@ # reports a mode other than `standalone`. That guard existed BECAUSE of the # context-dropping bug; relax it in the same change that repoints the URL, not # before, so a stale image cannot be adopted silently. +# +# The consumer also needs the CA, because `:9500` serves TLS from the cluster's +# OWN cert-manager root and no public root can verify it. Kubernetes Secrets do +# not cross namespaces, so `ca.crt` from `tidaldb-cluster-ca` has to be copied +# into the consumer's namespace (peach reads it via +# `TidalClient::from_env_with_ca`). +# +# A copied certificate deserves suspicion — k3s-fleet's own history records an +# incident where "the expired central SDLC wildcard had been copied manually +# and never renewed into its consumer namespaces". This copy is materially +# different and the numbers are why: +# +# tidaldb-cluster-ca duration 87600h (10y), renewBefore 8760h (1y) isCA +# tidaldb-cluster-tls duration 2160h (90d), renewBefore 720h (30d) +# +# The 90-day LEAF is what rotates, roughly every 60 days, and it rotates UNDER +# this same root — so the copied CA keeps verifying it and needs no attention. +# The fleet incident was an expiring leaf; this is a decade-lived root. +# +# The coupling that DOES bite is recreation, not expiry: `tidaldb-cluster-ca` is +# self-signed and generated fresh on first apply, so destroying and re-applying +# this namespace mints a NEW root and every copy goes stale at once — every +# consumer request then fails TLS verification with nothing wrong on either +# side. Treat "refresh the CA copy" as a mandatory step of any recreate, and +# prefer `kubectl rollout restart` over deleting the namespace. apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization