🔐 Secrets
INTENDED vs LIVE
Intended: Vault + External Secrets Operator (ESO) as the only Kubernetes secret materializer (rules below).
Live (as of architecture/Nakama audit trail): production cutover is blocked on the single-node cluster (no Vault/ESO; storage class cannot satisfy HA Vault prerequisites).
Do not rotate away legacy Secrets or assume Vault is live until an authorized migration is verified. See Nakama multiplayer production blockers and the dated Nakama audit.
Policy / intended control plane: Secrets belong in Vault; ESO materializes them into Kubernetes Secrets for workloads.
Observed consumption: Deployments reference Kubernetes Secrets (e.g. Nakama secretKeyRef, LiveKit envFrom) — that proves Secret consumption, not that Vault/ESO sync is live.
Wiki pages cite source paths and keys, never secret values.
Rules
- Do not paste private tokens, database URLs, console passwords, or generated secrets into content.
- Client-safe config uses
PUBLIC_*values only. - TLS ingresses use the existing
funday-tls-certsecret. - Server-side keys stay server-side; do not commit plain Kubernetes
Secretresources in GitOps. - Follow rotation runbooks when compromised: update the backing service credentials natively, sync Vault, wait for ESO (
SecretSynced=True), and rotate dependencies one by one.
Source: funday/funday-codex.yml env, tls, and service sections.
GitOps pointers
- Vault Argo app:
gitops/argocd-apps/vault-app.yaml - ESO Argo app:
gitops/argocd-apps/external-secrets-app.yaml - Vault ESO auth policy ConfigMap:
gitops/infrastructure/base/vault/vault-eso-auth.yaml
Bootstrap Prerequisites
The vault-eso-auth ConfigMap provides policy content for ESO integration. After Vault initialization and unsealing, administrators must explicitly apply these policies and enable the Kubernetes auth backend. GitOps does not automatically execute Vault CLI configuration; it expects the policies mapped in eso-role to be active.
Proof links (SD18)
| Claim class | Proof |
|---|---|
| Intended Vault app | gitops/argocd-apps/vault-app.yaml |
| Intended ESO app | gitops/argocd-apps/external-secrets-app.yaml |
| Policy bootstrap (manual) | gitops/infrastructure/base/vault/vault-eso-auth.yaml |
| Workloads consume K8s Secrets | gitops/platform/base/nakama/deployment.yaml (secretKeyRef / envFrom) |
| Live readiness still gated | Nakama multiplayer Operational Truth |
Live evidence (SD23)
Captured 2026-07-21T12:18:38Z via KUBECONFIG=~/.kube/config (host kubeconfig; /etc/rancher/k3s/k3s.yaml is root-only).
| Observation | Live result |
|---|---|
| Vault workload / ns | Absent — no Vault pods/deploys/ns; no Vault CRDs |
| External Secrets Operator | Absent — no ESO pods; no externalsecrets CRD |
| Argo CD apps API | Absent — no argocd ns; applications.argoproj.io not served |
| Intended GitOps still on disk | gitops/argocd-apps/vault-app.yaml, external-secrets-app.yaml exist (desired state, not live) |
| Nakama Secret consumption | deploy/nakama in funday-platform uses secretKeyRef (e.g. LiveKit keys from Secret livekit-keys) — proves K8s Secret use, not Vault/ESO sync |
Conclusion: LIVE matches the prior cutover caution — do not rotate as if Vault/ESO were materializing secrets. Re-check after any Vault/ESO/Argo install.