tidaldb/k8s/cluster-gke-peach
jordan 2c25b6d375 docs(k8s): record the CA-copy coupling for the GKE overlay
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.
2026-09-15 22:13:30 -06:00
..
kustomization.yaml docs(k8s): record the CA-copy coupling for the GKE overlay 2026-09-15 22:13:30 -06:00