The guide tells an operator to put the same S3 credentials in two places:
The S3 credentials must match config/seaweedfs/s3-config.json - update both the .env and that file to the same values, or document storage won't authenticate.
deploy/.env is gitignored, so the copy there is safe. deploy/config/seaweedfs/s3-config.json is tracked, so the copy there is a real secret sitting in the working tree of a git repo, one git commit -a away from being published and then living in history forever.
This is not hypothetical. Following the documented steps to bring the stack up locally, I had a generated key sitting in that tracked file within minutes, and it was caught by a secret scan rather than by anything in the workflow. It happens to have been caught before any commit, but nothing in the repo would have stopped it.
The shipped placeholder (change-me-s3-secret) makes it worse in a quiet way: an operator who edits .env but forgets this file gets a stack that authenticates fine against the committed placeholder, so the "secret" protecting document storage is a value published in the repository.
Worth considering: render the SeaweedFS config at start from $S3_ACCESS_KEY / $S3_SECRET_KEY into a gitignored path - the stack already has a one-shot init-perms service that could do it - and keep only a template in git. That removes the second copy entirely and makes .env the single source, which is what the rest of the stack already assumes.
The guide tells an operator to put the same S3 credentials in two places:
deploy/.envis gitignored, so the copy there is safe.deploy/config/seaweedfs/s3-config.jsonis tracked, so the copy there is a real secret sitting in the working tree of a git repo, onegit commit -aaway from being published and then living in history forever.This is not hypothetical. Following the documented steps to bring the stack up locally, I had a generated key sitting in that tracked file within minutes, and it was caught by a secret scan rather than by anything in the workflow. It happens to have been caught before any commit, but nothing in the repo would have stopped it.
The shipped placeholder (
change-me-s3-secret) makes it worse in a quiet way: an operator who edits.envbut forgets this file gets a stack that authenticates fine against the committed placeholder, so the "secret" protecting document storage is a value published in the repository.Worth considering: render the SeaweedFS config at start from
$S3_ACCESS_KEY/$S3_SECRET_KEYinto a gitignored path - the stack already has a one-shotinit-permsservice that could do it - and keep only a template in git. That removes the second copy entirely and makes.envthe single source, which is what the rest of the stack already assumes.