web-arm: replace powersync pg_hba trust rule with scram password (ADR-0012 follow-up) #336

New issue

Open

opened 2026-08-14 12:35:19 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-08-14 12:35:19 +02:00

Owner

hosts/web-arm/modules/powersync/default.nix authenticates the powersync container to host PG14 with a passwordless trust rule scoped to db+role+subnet:

host powersync_storage powersync_storage 10.89.0.0/24 trust

The module itself documents the condition for hardening: 'a generated-password + scram rule is the documented hardening follow-up (ADR-0012) should a second container ever join v6egress.' The planned central OneCLI deployment on web-arm is that second container, so the condition is now met: any container on the v6egress bridge can currently obtain full read/write on powersync's bucket-storage DB without credentials.

Fix per the documented follow-up:

Generate a password for the powersync_storage role, store it in web-arm's sops (hosts/web-arm/secrets.sops.yaml) — operator adds the secret value.
Inject it into the container's storage DSN via the existing sops template / environment mechanism (the service.yaml storage uri currently hardcodes a 'notsecret' placeholder).
Replace the trust line with scram-sha-256 for that db+role+subnet.

Blast radius today is powersync's DB only (the rule matches exactly that db+role pair; other DBs fall through to defaults and are refused), so this is hardening, not an active incident.

hosts/web-arm/modules/powersync/default.nix authenticates the powersync container to host PG14 with a passwordless trust rule scoped to db+role+subnet: host powersync_storage powersync_storage 10.89.0.0/24 trust The module itself documents the condition for hardening: 'a generated-password + scram rule is the documented hardening follow-up (ADR-0012) should a second container ever join v6egress.' The planned central OneCLI deployment on web-arm is that second container, so the condition is now met: any container on the v6egress bridge can currently obtain full read/write on powersync's bucket-storage DB without credentials. Fix per the documented follow-up: - Generate a password for the powersync_storage role, store it in web-arm's sops (hosts/web-arm/secrets.sops.yaml) — operator adds the secret value. - Inject it into the container's storage DSN via the existing sops template / environment mechanism (the service.yaml storage uri currently hardcodes a 'notsecret' placeholder). - Replace the trust line with scram-sha-256 for that db+role+subnet. Blast radius today is powersync's DB only (the rule matches exactly that db+role pair; other DBs fall through to defaults and are refused), so this is hardening, not an active incident.

dominik.polakovics added the

needs-triage

label

2026-08-14 12:35:19 +02:00

dominik.polakovics referenced this issue

2026-08-14 12:38:28 +02:00

web-arm: central OneCLI credential gateway (container + host PG14, WireGuard-only exposure, borg-backed) #337

dominik.polakovics referenced this issue

2026-08-14 13:19:43 +02:00

feat(web-arm): central OneCLI credential gateway, WireGuard-only #339

dominik.polakovics referenced this issue

2026-08-14 21:50:08 +02:00