Follow-ups to the 9 secret-hardening commits (each verified against
docs.docker.com / vendor docs; one outright new bug found and fixed):
- 11.6: eb5e4397 changed settings.py to a hard os.environ lookup but the
web service never receives POSTGRES_PASSWORD (only db does; DATABASE_URL
is set but never read) -> step-6 'docker compose up' crashed with
KeyError. Pass the var to web; harden the leftover literal password in
the 配置详解 snippet that contradicted the new guidance two lines down;
blank line after the inserted sentence (bold heading merged into the
paragraph); dev/prod table no longer claims dev uses 明文 passwords
- 11.8: FAQ still told readers to check passwords in .env after the same
file banned passwords in .env -> point at secrets/db_password.txt;
backup sidecar env vars updated to tiredofit/db-backup 4.x interface
(DB01_* + DB01_PASS_FILE + DB01_BACKUP_INTERVAL - the unprefixed DB_*
names are ignored by current :latest; verified against upstream README)
- demo/wordpress: compose now references secrets files that ship nowhere
-> add README with the creation commands from 11.8; demo/django: align
with the hardened 11.6 (env-injected password, passed to web too)
- 04_image multistage demos: go build without go.mod fails on module-mode
Go (reproduced by reviewer on go1.26) -> add 'go mod init helloworld'
matching the 7.17 doc pattern in all three Dockerfiles
- 21.7: init script reworked init-db.sql -> init-db.sh per the official
image's env-reading .sh hook - removes the baked 'secure_password' AND
the CREATE DATABASE myappdb collision with POSTGRES_DB that aborted
first-boot init (ON_ERROR_STOP); compose passes APP_DB_PASSWORD;
microservices init.sql mount annotated schema-only (POSTGRES_USER:
appuser would collide with CREATE USER); Dockerfile-redis healthcheck
now authenticates via REDISCLI_AUTH read from redis.conf (plain
redis-cli ping gets NOAUTH against requirepass - same class as the
compose sibling eb5e4397 already fixed); dev-container dev/dev creds
annotated local-only
- 19.3: Grafana admin password 'admin' sat directly under the newly added
security warning -> env-injected like the rest of the stack
The cAdvisor compose examples in 19.3.3 use `privileged: true`, which
contradicts the minimum-privilege / cap_drop=all guidance in chapter 18.
Add an explicit trade-off note before the first cAdvisor snippet
explaining the inconsistency and pointing to 18.4 for capability-based
hardening alternatives (cap_add: [SYS_ADMIN] + device_cgroup_rules
instead of full privileged mode).
This addresses the Round 1 review finding about pedagogical conflict
between the monitoring and security chapters.
yeasy