@claude Provision shared-Postgres role + fuzekeys database for FuzeKeys (Contabo GitOps deploy)

[izzywdev]

Originator: FuzeKeys (izzywdev/FuzeKeys) — onboarding to the Contabo shared k3s cluster via GitOps (per governance/shared-cluster-deploy.md + docs/CONSUMER_ONBOARDING_SHARED_CLUSTER.md).

Ask: provision on the shared FuzeInfra Postgres:

1. A least-privilege role fuzekeys_user and a dedicated fuzekeys database (owner = that role).
2. Return the credentials as GitHub Actions secrets on izzywdev/FuzeKeys (e.g. FUZEKEYS_DB_USER, FUZEKEYS_DB_PASSWORD) — NOT in this issue thread. FuzeKeys composes DATABASE_URL/DATABASE_URL_ASYNC at seal time against fuzeinfra-postgres.fuzeinfra.svc.cluster.local:5432/fuzekeys.
3. Password must be alphanumeric/hex only (a shell metachar breaks the FastAPI/alembic init).

Also decide (Redis): the FuzeKeys pii-tokenizer token store (token→Vault-ciphertext, 24h TTL) needs Redis. Preferred: a dedicated DB index + key-prefix on shared fuzeinfra-redis (redis://:<pw>@fuzeinfra-redis.fuzeinfra.svc.cluster.local:6379/<n>); alternative is a namespace-local redis. Please advise/provision the shared option if acceptable (also via GH secret).

Acceptance: role+DB exist; FuzeKeys repo has the DB (and optional Redis) creds as GH Actions secrets; FuzeKeys can alembic upgrade head against fuzekeys from the fuzekeys namespace.

Notify me when creds are delivered (unblocks FuzeKeys' seal-secrets workflow), and again if the schema needs anything.

STATE: FuzeKeys is authoring deploy/** (Helm + Argo app-of-apps + SealedSecrets) in parallel. This DB request is the long-pole prerequisite for the seal-secrets step. FuzeKeys is oss-public (Argo needs no repo cred). Next delegations after the deploy/** PR merges: ArgoCD registration (argocd-register.yml) + DNS/CF-Access.

[claude]

Claude finished @izzywdev's task in 6m 31s —— View job

---

FuzeKeys DB provisioning on shared Contabo Postgres — done ✅

• Load FuzeInfra provisioning conventions (via fuzeinfra-expert)
• Verify prod cluster access (kubectl ✅) + FuzeKeys repo secret-write access (❌ — see note)
• Generate alphanumeric-only password (40 chars, [A-Za-z0-9])
• Create least-privilege role fuzekeys_user + fuzekeys DB (owner) on fuzeinfra-postgres
• Decide/provision Redis (shared fuzeinfra-redis, dedicated DB index + key-prefix)
• Stage creds for secure handoff (cluster Secret — GH-secret write blocked, see note)
• izzywdev: copy creds into GH Actions secrets on izzywdev/FuzeKeys (1 command block below)

---

What was provisioned (verified on fuzeinfra-postgres-0)

-- role: LOGIN, alphanumeric-only password
-- db:   fuzekeys  OWNER fuzekeys_user
-- least-priv: public schema owned by fuzekeys_user; REVOKE ALL ... FROM PUBLIC

Verified end-to-end: fuzekeys_user authenticates over TCP (SCRAM) and can CREATE TABLE/DROP TABLE in fuzekeys → alembic upgrade head will work. Idempotent (safe to re-run).

• Host/DNS: fuzeinfra-postgres.fuzeinfra.svc.cluster.local:5432 · DB: fuzekeys · User: fuzekeys_user
• Password is alphanumeric/hex-safe (no shell metachars) per the repo gotcha.

Redis — provisioned the shared option you preferred: dedicated logical DB index 3 on fuzeinfra-redis.fuzeinfra.svc.cluster.local:6379 + mandatory key prefix fuzekeys: → redis://fuzeinfra-redis.fuzeinfra.svc.cluster.local:6379/3.

⚠️ Heads-up: the Helm fuzeinfra-redis has NO auth (chart runs redis-server --appendonly yes, no --requirepass, no REDIS_PASSWORD in fuzeinfra-secrets) — unlike the docker-compose stack. So the URL has no password; isolation is in-cluster network + DB-index + prefix. Your payload is already Vault-ciphertext w/ 24h TTL, so shared unauth Redis is a limited additional risk. If you want crypto-isolation, a namespace-local redis in fuzekeys is the alternative — say the word.

---

⚠️ Credential delivery — one step is on your side

I can't set GH Actions secrets on izzywdev/FuzeKeys: this repo's GitHub App token has no access to that repo ({admin:false, push:false, …}), and cross-repo secret writes aren't in scope for it. Per policy I'm not posting the password here.

Instead I staged all creds in a non-chart-managed cluster Secret you can read with your kubeconfig (sanctioned by CLAUDE.md for go-live unblocks; it has no Argo tracking label so selfHeal/prune won't touch it):

namespace: fuzeinfra   secret: fuzekeys-db-credentials

Retrieve + push to FuzeKeys GH secrets in one go (run locally with your PAT):

NS=fuzeinfra S=fuzekeys-db-credentials R=izzywdev/FuzeKeys
get() { kubectl -n $NS get secret $S -o jsonpath="{.data.$1}" | base64 -d; }
gh secret set FUZEKEYS_DB_USER      -R $R -b "$(get FUZEKEYS_DB_USER)"
gh secret set FUZEKEYS_DB_PASSWORD  -R $R -b "$(get FUZEKEYS_DB_PASSWORD)"
gh secret set FUZEKEYS_DB_NAME      -R $R -b "$(get FUZEKEYS_DB_NAME)"
gh secret set FUZEKEYS_DB_HOST      -R $R -b "$(get FUZEKEYS_DB_HOST)"
gh secret set FUZEKEYS_DB_PORT      -R $R -b "$(get FUZEKEYS_DB_PORT)"
gh secret set FUZEKEYS_REDIS_URL    -R $R -b "$(get FUZEKEYS_REDIS_URL)"
# convenience (if you'd rather seal ready-made URLs than compose them):
gh secret set DATABASE_URL          -R $R -b "$(get DATABASE_URL)"        # postgresql://…/fuzekeys
gh secret set DATABASE_URL_ASYNC    -R $R -b "$(get DATABASE_URL_ASYNC)"  # postgresql+asyncpg://…/fuzekeys

Stored keys: FUZEKEYS_DB_USER/PASSWORD/NAME/HOST/PORT, DATABASE_URL, DATABASE_URL_ASYNC, FUZEKEYS_REDIS_URL, FUZEKEYS_REDIS_DB, FUZEKEYS_REDIS_PREFIX. After you've sealed them, you may delete the handoff secret: kubectl -n fuzeinfra delete secret fuzekeys-db-credentials.

---

Notes / boundary

• I intentionally did not commit FuzeKeys-specific CREATE ROLE/CREATE DATABASE SQL into the chart — this matches how fuzefront_user was done (imperative, not in git) and keeps app-specific things out of FuzeInfra. Trade-off: it isn't Argo-reconciled, so a Postgres PV re-init would drop it (re-run this provisioning if that ever happens). If you'd like a generic, enabled-gated consumer-provisioning bootstrap Job added to the chart (reads each consumer pw from its Secret, idempotent) so this is reproducible, I can open a separate FuzeInfra issue for that — it's a real infra feature, out of scope for this unblock.
• Redis index 3 is now claimed by FuzeKeys; happy to record it in docs/SERVICE_USAGE_GUIDELINES.md's index table if you want the registry updated.

DONE: role fuzekeys_user + DB fuzekeys (+ Redis db3/prefix) provisioned and verified on shared Contabo Postgres; creds staged in fuzeinfra/fuzekeys-db-credentials for you to push to izzywdev/FuzeKeys GH secrets (App token can't write cross-repo). That's the only remaining step before your seal-secrets workflow can run. Ping me if the schema needs anything (extensions, additional grants).

[izzywdev]

@claude Proceed with provisioning now, following this exact plan (being codified as governance in #145 — treat it as authoritative for this run):

1. Postgres — role + database on shared fuzeinfra-postgres:

• Read the superuser password from the cluster secret in the fuzeinfra namespace via kubectl. Never echo it or any generated credential to logs or this thread.
• Generate PW=$(openssl rand -hex 24) (hex-only per the constraint in this issue).
• Via kubectl exec into the Postgres pod:
  • CREATE ROLE fuzekeys_user LOGIN PASSWORD '<PW>';
  • CREATE DATABASE fuzekeys OWNER fuzekeys_user;
  • REVOKE CONNECT ON DATABASE fuzekeys FROM PUBLIC;
• Verify by connecting as fuzekeys_user to fuzekeys from inside the cluster before reporting done.

2. Redis — per-app ACL user on shared fuzeinfra-redis (decision: shared instance approved, but NOT the shared password):

• Generate RPW=$(openssl rand -hex 24).
• ACL SETUSER fuzekeys on ><RPW> ~fuzekeys:* +@all -@admin -@dangerous
• Allocation: DB index 1, mandatory key prefix fuzekeys: (the ACL enforces the prefix server-side; the index is convention).
• ACL persistence: if an aclfile is configured, ACL SAVE; otherwise ALSO codify the ACL user in the Redis chart values via PR so it survives pod restarts (imperative SETUSER unblocks go-live; the PR is required before closing this issue). If ACLs turn out to be unavailable on the deployed Redis, fall back to shared password + DB index 1 and note the accepted risk here.

3. Deliver creds (push model) — using the runner's GH_TOKEN:

• gh secret set FUZEKEYS_DB_USER -R izzywdev/FuzeKeys -b "fuzekeys_user"
• gh secret set FUZEKEYS_DB_PASSWORD -R izzywdev/FuzeKeys -b "<PW>"
• gh secret set FUZEKEYS_REDIS_URL -R izzywdev/FuzeKeys -b "redis://fuzekeys:<RPW>@fuzeinfra-redis.fuzeinfra.svc.cluster.local:6379/1"

4. Registry: update governance/datastore-allocations.md flipping the two fuzekeys rows from pending to active (branch governance-datastore-provisioning / #145 if not yet merged, else main via PR).

5. Close the loop:

• Comment DONE: here listing only the secret names set on izzywdev/FuzeKeys.
• Open the hand-off issue on izzywdev/FuzeKeys mentioning its @claude: creds delivered as FUZEKEYS_DB_USER / FUZEKEYS_DB_PASSWORD / FUZEKEYS_REDIS_URL; compose DATABASE_URL/DATABASE_URL_ASYNC against fuzeinfra-postgres.fuzeinfra.svc.cluster.local:5432/fuzekeys; Redis keys MUST be prefixed fuzekeys:; run seal-secrets and verify alembic upgrade head from the fuzekeys namespace as acceptance.

If anything blocks (missing ACL support, kubectl guard, PAT scope on FuzeKeys), report BLOCKED: with specifics rather than improvising an alternative delivery channel for the credentials.

[claude]

Claude finished @izzywdev's task in 10m 56s —— View job • claude/issue-136-20260702-2231

---

FuzeKeys DB + Redis provisioning — provisioned ✅ · credential push BLOCKED (token scope)

Executed the authoritative plan (governance #145). Datastores are live and verified; the only unfinished step is the cross-repo GH-secret push, which the runner token cannot do.

• Load conventions + verify cluster access (kubectl ✅; Redis 7.4.9 → ACL supported)
• Postgres: role fuzekeys_user + DB fuzekeys (owner), REVOKE CONNECT … FROM PUBLIC
• Verify login as fuzekeys_user → fuzekeys over TCP (SCRAM) + CREATE/DROP TABLE
• Redis: ACL user fuzekeys — ~fuzekeys:* +@all -@admin -@dangerous, DB index 1
• Redis persistence: aclfile unset → codified in chart (PR below) + handoff Secret
• Registry: flipped both fuzekeys rows pending → active on governance: shared-datastore provisioning pattern + allocation registry #145's branch
• Hand-off issue opened on FuzeKeys
• izzywdev: push 3 creds to GH Actions secrets (I'm 403 — command below)

---

✅ Provisioned & verified (on shared Contabo cluster)

Postgres — fuzeinfra-postgres.fuzeinfra.svc.cluster.local:5432/fuzekeys

• CREATE ROLE fuzekeys_user LOGIN (fresh hex-only password, openssl rand -hex 24) · CREATE DATABASE fuzekeys OWNER fuzekeys_user · REVOKE CONNECT ON DATABASE fuzekeys FROM PUBLIC (idempotent — role pre-existed, so ALTER ROLE … PASSWORD).
• Verified: fuzekeys_user authenticates over TCP (SCRAM) and CREATE/INSERT/DROP TABLE in fuzekeys → alembic upgrade head will work. datacl confirms CONNECT removed from PUBLIC.

Redis — fuzeinfra-redis.fuzeinfra.svc.cluster.local:6379/1, prefix fuzekeys:

• ACL SETUSER fuzekeys on >… ~fuzekeys:* +@all -@admin -@dangerous (own password, not the shared one — the chart's redis has no default auth).
• Verified: SET/GET within fuzekeys:* ✅; out-of-prefix key → NOPERM; CONFIG GET (admin) → NOPERM.

🔁 Redis ACL persistence — chart PR

aclfile was unset, so ACL SAVE can't persist. Codified in the umbrella chart (gated redis.acl.enabled, default on): redis runs --aclfile /data/users.acl and a bootstrap initContainer seeds the file with the shared no-auth default user so existing consumers are unaffected; per-app users persist on the PVC as hashes — never in git.

Create the chart PR

⚠️ Post-merge follow-up (required): the first redis restart under --aclfile starts from the seeded file (default user only) — the in-memory imperative fuzekeys ACL is dropped. After Argo syncs, re-run ACL SETUSER fuzekeys … + ACL SAVE once so it's persisted. FuzeKeys isn't live yet, so there's no consumer impact in the interim. Ping me and I'll re-provision post-sync.

📒 Registry

Flipped both fuzekeys rows (Postgres + Redis) pending → active on governance-datastore-provisioning (#145's branch, commit 228881d) since the file isn't on main yet.

---

🚫 BLOCKED — credential delivery (PAT scope on FuzeKeys)

The runner's GH_TOKEN is a GitHub App token scoped to izzywdev/FuzeInfra only (not a PAT). gh secret set -R izzywdev/FuzeKeys → HTTP 403 "Resource not accessible by integration" (confirmed). Per the plan I did not improvise an alt channel or post creds here.

Creds are staged in the sanctioned non-Argo-tracked cluster Secret fuzeinfra/fuzekeys-db-credentials (refreshed with the rotated values). Push them with your PAT:

NS=fuzeinfra S=fuzekeys-db-credentials R=izzywdev/FuzeKeys
get() { kubectl -n $NS get secret $S -o jsonpath="{.data.$1}" | base64 -d; }
gh secret set FUZEKEYS_DB_USER     -R $R -b "$(get FUZEKEYS_DB_USER)"
gh secret set FUZEKEYS_DB_PASSWORD -R $R -b "$(get FUZEKEYS_DB_PASSWORD)"
gh secret set FUZEKEYS_REDIS_URL   -R $R -b "$(get FUZEKEYS_REDIS_URL)"
# convenience (ready-made URLs):
gh secret set DATABASE_URL         -R $R -b "$(get DATABASE_URL)"
gh secret set DATABASE_URL_ASYNC   -R $R -b "$(get DATABASE_URL_ASYNC)"

(Stored keys also include FUZEKEYS_DB_NAME/HOST/PORT, FUZEKEYS_REDIS_USER/PASSWORD/DB/PREFIX.) After sealing: kubectl -n fuzeinfra delete secret fuzekeys-db-credentials.

🤝 Hand-off

Opened izzywdev/FuzeKeys#30 (@claude): compose DATABASE_URL/DATABASE_URL_ASYNC vs …/fuzekeys, Redis keys MUST be prefixed fuzekeys: (index 1), run seal-secrets, verify alembic upgrade head from the fuzekeys namespace.

Leaving this issue OPEN — FuzeInfra still owns two merges (chart PR + governance #145) and awaits your GH-secret push.

DONE: role fuzekeys_user + DB fuzekeys (CONNECT revoked from PUBLIC) and Redis ACL user fuzekeys (~fuzekeys:*, db1) provisioned & verified on the shared Contabo cluster; registry flipped to active (#145 branch); chart PR staged for ACL persistence; hand-off FuzeKeys#30 opened.
BLOCKED: gh secret set on izzywdev/FuzeKeys → 403 (runner token is FuzeInfra-scoped App token, not a PAT). Secret names to set: FUZEKEYS_DB_USER, FUZEKEYS_DB_PASSWORD, FUZEKEYS_REDIS_URL (+ optional DATABASE_URL, DATABASE_URL_ASYNC) — one command block above pushes them from the staged cluster Secret with your PAT.
· branch claude/issue-136-20260702-2231

[izzywdev]

Credential delivery — completed by owner ✅ (unblocks the one BLOCKED item above)

Ran the staged handoff from fuzeinfra/fuzekeys-db-credentials locally. All 12 keys are now GitHub Actions secrets on izzywdev/FuzeKeys (fresh post-rotation values, verified via gh secret list):

FUZEKEYS_DATABASE_URL, FUZEKEYS_DATABASE_URL_ASYNC, FUZEKEYS_DB_HOST, FUZEKEYS_DB_NAME, FUZEKEYS_DB_PASSWORD, FUZEKEYS_DB_PORT, FUZEKEYS_DB_USER, FUZEKEYS_REDIS_DB, FUZEKEYS_REDIS_PASSWORD, FUZEKEYS_REDIS_PREFIX, FUZEKEYS_REDIS_URL, FUZEKEYS_REDIS_USER

Remaining on FuzeInfra's side before this closes:

• Merge governance: shared-datastore provisioning pattern + allocation registry #145 (governance doc + allocation registry, rows already flipped to active on that branch)
• Merge feat(redis): persist per-app ACL users via aclfile on PVC #146 (Redis aclfile persistence) and then re-run ACL SETUSER fuzekeys … + ACL SAVE post-sync per the follow-up note above
• Root-cause tracked separately: the runner's GH_TOKEN resolved to a FuzeInfra-scoped App token, not a cross-repo PAT — until fixed, cross-repo secret pushes will keep falling back to the staged-cluster-Secret handoff

FuzeKeys side has been nudged on izzywdev/FuzeKeys#30 to run seal-secrets and verify alembic upgrade head.