jordan/tidaldb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(k8s): record the CA-copy coupling for the GKE overlay

Browse Source 
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.
This commit is contained in:
jordan 2026-09-15 22:13:30 -06:00
parent 19316227c5
commit 2c25b6d375
1 changed files with 25 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
k8s/cluster-gke-peach/kustomization.yaml
View File

@ -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