What happens
bin/init-db.js logs the resolved connection string verbatim at startup:
{"level":30,...,"module":"init-db","database":"keryx","postgresUrl":"postgres://user:<url-encoded-password>@host:5432/db?ssl=true","msg":"ensuring database exists"}
Deployments that run init-db as an initContainer (as recommended for the 0.7.0 DDL) ship this line — password included — to whatever log pipeline scrapes pod stdout (Loki/CloudWatch/Datadog/...). We hit this today on our staging rollout of 0.7.0: the database password is now sitting in our log store and has to be rotated.
Expected
Redact credentials before logging, e.g. log url.host + url.pathname only, or replace the password component with ***:
const safe = new URL(postgresUrl); safe.password = safe.password ? '***' : '';
log.info({ postgresUrl: safe.toString(), database }, 'ensuring database exists')
Same consideration applies anywhere else a connection URL is logged (worker/server startup paths log host-only today, which is good — init-db is the outlier).
Version
@y/hub 0.7.0 (bin/init-db.js, the ensuring database exists log site).
What happens
bin/init-db.jslogs the resolved connection string verbatim at startup:Deployments that run init-db as an initContainer (as recommended for the 0.7.0 DDL) ship this line — password included — to whatever log pipeline scrapes pod stdout (Loki/CloudWatch/Datadog/...). We hit this today on our staging rollout of 0.7.0: the database password is now sitting in our log store and has to be rotated.
Expected
Redact credentials before logging, e.g. log
url.host+url.pathnameonly, or replace the password component with***:Same consideration applies anywhere else a connection URL is logged (worker/server startup paths log host-only today, which is good — init-db is the outlier).
Version
@y/hub 0.7.0 (
bin/init-db.js, theensuring database existslog site).