fix(security): fail closed on unset database and Redis credentials - #1644
fix(security): fail closed on unset database and Redis credentials#1644FenjuFu wants to merge 2 commits into
Conversation
The compose stack shipped default PostgreSQL (spark123) and MySQL (root123)
superuser passwords through ${VAR:-default} fallbacks, and .env.example set
those same values, so the documented `cp .env.example .env` deployment path
started with well-known credentials.
Convert every database-credential reference to the ${VAR:?message} fail-fast
form, mirroring the existing MinIO/OSS preflight, and blank the shipped values
in .env.example so the stack refuses to start until the operator provides a
strong, unique password.
Signed-off-by: FenjuFu <92919259+FenjuFu@users.noreply.github.com>
The bundled Redis enabled --requirepass only when REDIS_PASSWORD was
non-empty, and .env.example shipped the weak value `123`, so the documented
`cp .env.example .env` deployment ran Redis with a well-known password (or
with none, if the operator cleared it) on the shared network.
Make the password mandatory: the redis command and every consumer now use the
${VAR:?message} fail-fast form, and .env.example ships REDIS_PASSWORD empty so
the stack refuses to start until the operator sets a strong, unique value.
Signed-off-by: FenjuFu <92919259+FenjuFu@users.noreply.github.com>
Verification / validation notes for reviewersThis change is configuration-only ( What was checked
Why both files change together The Compose Scope note Database + Redis credentials are covered here. The service-to-service auth secrets ( |
|
该做法会增加用户的部署复杂度,建议提供初始化密码,用户根据需要修改;https://github.com/iflytek/astron-agent/security/advisories/GHSA-mh3w-4q3f-2fg5 报告中提到的其他问题,基本已修复; |
|
此 PR我先关闭 |
What
The bundled compose stack shipped well-known default credentials that the documented
cp .env.example .envdeployment path used verbatim:spark123and MySQL superuserroot123, via${VAR:-default}fallbacks in compose plus the same values set in.env.example.--requirepassonly whenREDIS_PASSWORDwas non-empty, and.env.exampleshipped the weak value123— so the default deployment ran Redis with a known password (or none, if the operator cleared it).This aligns those credentials with the fail-fast preflight already used for MinIO/OSS.
Changes
docker/astronAgent/docker-compose.yamlPOSTGRES_PASSWORD,MYSQL_ROOT_PASSWORD,MYSQL_PASSWORD,DATABASE_PASSWORD):${VAR:-weak-default}→${VAR:?message}.redis-server --requirepass ${REDIS_PASSWORD:?…}(password mandatory, no longer conditional), and every consumer'sREDIS_PASSWORDreference is fail-fast.docker/astronAgent/.env.examplePOSTGRES_PASSWORD/MYSQL_ROOT_PASSWORD/REDIS_PASSWORD(with a short comment, same style as the MinIO block), and drop the:-root123fallbacks from the chainedMYSQL_PASSWORD/DATABASE_PASSWORD.Why change both files
The compose
${VAR:-default}fallback only triggers when the variable is unset. Because.env.exampleset the weak values explicitly, changing compose alone would have no effect on the default deployment — both files must change together.Validation
docker-compose.yamlremains valid YAML (16 services parse).docker compose upwith the guidance message; a set value resolves normally.Out of scope (follow-up, needs coordination)
Service-to-service auth secrets (
APP_AUTH_API_KEY/APP_AUTH_SECRET,COMMON_API_SECRET,TENANT_KEY/TENANT_SECRET) still carry placeholder defaults. These are validated by thecore-tenantservice against provisioned key data, so making the client side fail-fast requires updating the tenant-side provisioning in lockstep; converting them here would break the default deployment. Left for a coordinated follow-up.WORKFLOW_INTERNAL_API_KEYintentionally keeps its placeholder default — the auth layer treats the placeholder as "not configured" and returns 503, so it is already fail-closed.