Phase 5 of 7
Security Hardening
Turn the stack into a hardened, least-privilege runtime with policy and secrets discipline.
Overview
Apply image hardening and runtime controls so security defaults are explicit by design, not just documented in comments.
What to build
Deliverables
Advance only when these outputs exist in your code or compose definitions.
- Harden Dockerfiles with explicit tags, non-root users, and minimal package surfaces
- Use Docker secrets in production-oriented compose wiring
- Implement backend/frontend network isolation and service-level access control
- Add vulnerability and misconfiguration scanning scripts
- Apply container security options, rate limiting, and TLS path readiness
Done when
Success criteria
These are acceptance indicators, not a checklist to start from.
- No privileged or root-run application containers in default mode
- Secrets are not committed in compose/environment files
- Database service remains non-public by network design
- Security scans identify and track HIGH/CRITICAL findings
- API rate limits are active and enforceable
- TLS is defined for deployment path
Verification
Testing and validation
Run these in order. Confirm each result before moving to the next step.
-
./scripts/security-scan.sh`./scripts/security-scan.sh`
-
docker compose exec api ps auxto validate runtime user
-
docker compose exec api env | grep -i passwordshould not leak secrets
-
Validate API rate limiting with burst request test
-
Run Docker Bench Security command path with documented command