Stack Hardening
DevOps-grade defense across your entire stack.
DevOps teams and solo-ops who self-host and want to know they're doing it right.
You run the production stack. You use containers, a reverse proxy, a secrets manager (or — honestly — an `.env` file you know you should delete). The team ships, the stack holds, and every quarter someone asks "are we compliant with NIS2?" and the room goes quiet. This track is the afternoon where the room stops going quiet.
Docker, Nginx, Vault, RBAC, CI/CD — every item on this list has a default configuration that an attacker loves. The Stack Hardening track is a guided sprint through the exact controls that separate a team that ships fast from a team that ships fast AND sleeps through the night.
- M-001
Ship a non-root Dockerfile before it hits staging
Your Dockerfile runs as root + writes anywhere. Harden it: non-root user, read-only rootfs, HEALTHCHECK, scan with Trivy.
⏱️ 7 min⚡ 150 XP🎯 6 goalsLaunch → - M-002
Lock down Postgres before the audit team lands
Trust auth on the LAN, SSL off, every role superuser, no query log. Fix all four — without breaking the app.
⏱️ 10 min⚡ 180 XP🎯 8 goalsLaunch → - M-003
Stop the credential-stuffing wave on /login — without locking out users
/api/auth/login is taking 4000 req/min from rotating IPs. Define a rate-limit zone, apply it surgically, deny headless UAs. Validate against real traffic.
⏱️ 9 min⚡ 200 XP🎯 7 goalsLaunch → - M-004
Restore the nightly backup before the SLA breach hits
Primary db is corrupt at 03:14. Replica is lagged. Restore from nightly into a sidecar, verify schema + rows, sign off — without restoring directly to prod.
⏱️ 12 min⚡ 220 XP🎯 6 goalsLaunch → - M-005
Rotate the leaked API key without breaking a single client
API key leaked in a public Docker layer. 4 clients depend on it. Wrong order = production outage. Dual-write -> migrate -> drain -> retire.
⏱️ 13 min⚡ 240 XP🎯 8 goalsLaunch → - M-006
Default-deny the prod namespace without breaking ingress + worker traffic
Cluster-wide allow-everything is K8s default. Red-team probe in dev just reached /admin on prod/api-server. Apply default-deny + targeted allows. Wrong order = service breaks.
⏱️ 14 min⚡ 260 XP🎯 7 goalsLaunch → - M-007
Lock down the public /admin endpoint with IP allowlist + HTTP Basic Auth
12,000 brute-force attempts on /admin in 24 h. Add IP-based allow-list and HTTP Basic Auth to the nginx vhost — then verify a 403 from an unauthorized IP.
⏱️ 9 min⚡ 195 XP🎯 7 goalsLaunch → - M-008
Harden the docker-compose stack: drop root, remove socket, move secrets
Staging compose file has 5 critical issues: plain-text secrets, Docker socket mount, root user, no resource limits, mutable rootfs. Fix all five before prod.
⏱️ 10 min⚡ 210 XP🎯 6 goalsLaunch → - M-009
Secure Redis: bind restriction, requirepass, ACL, disable dangerous commands
Redis is on 0.0.0.0 with no auth. Pen-tester dumped all keys in seconds. Bind to localhost, set requirepass, disable FLUSHALL/DEBUG, create a least-privilege API ACL user.
⏱️ 11 min⚡ 230 XP🎯 6 goalsLaunch → - M-010
Kubernetes Pod Security: restrict capabilities & drop privileges
Your pod runs as root with NET_ADMIN/SYS_ADMIN. Harden it: drop privileged, remove capabilities, runAsNonRoot, readOnlyRootFilesystem, seccomp profile.
⏱️ 15 min⚡ 270 XP🎯 7 goalsLaunch → - M-011
AWS S3 Bucket Policy: restrict public access and enforce encryption
Your S3 bucket allows public read access with no encryption. Harden it: remove public access, restrict to IAM role, enforce encryption, block public ACLs.
⏱️ 12 min⚡ 250 XP🎯 6 goalsLaunch → - M-012
TLS Certificate Rotation: automate cert renewal before expiry
Your TLS certificate expires in 10 days. Automate renewal: certbot dry-run, cron job, monitoring alerts, verify new cert, test TLS handshake.
⏱️ 13 min⚡ 240 XP🎯 6 goalsLaunch → - M-013
PostgreSQL Row-Level Security: multi-tenant data isolation
Your multi-tenant PostgreSQL has no RLS. Enable RLS: create tenant isolation policy, admin bypass policy, test with different users, verify data isolation.
⏱️ 14 min⚡ 260 XP🎯 6 goalsLaunch → - M-014
GitHub Actions Hardening: secure CI/CD pipeline
Your CI/CD pipeline has no security controls. Harden it: add required reviewers, environment protection, secrets validation, branch protection rules.
⏱️ 15 min⚡ 270 XP🎯 6 goalsLaunch → - M-015
Prometheus Alerting: configure critical security alerts
Your Prometheus has only basic error rate alert. Configure comprehensive security alerting: brute-force attacks, certificate expiry, suspicious logins, high CPU.
⏱️ 14 min⚡ 250 XP🎯 6 goalsLaunch →
Concrete outcomes. No lecture notes.
- 01A Dockerfile that runs non-root, read-only, with signed images
- 02An Nginx config that rate-limits aggressive scrapers at the edge
- 03A Vault-backed secrets flow — zero credentials in git history
- 04RBAC so specific that every role audit takes 10 minutes, not 10 hours
- 05A CI/CD pipeline that runs the ClawGuru security check on every PR and fails the build on regression
- 06A written incident response runbook you can actually run at 3 AM
- ▸DevOps / SRE leads at 10–200 person companies
- ▸Solo-ops running multi-service self-hosted infra
- ▸Engineering managers preparing for NIS2 audit
- ▸Security engineers who inherited a legacy DevOps culture
Directly addresses NIS2 Article 21 technical controls (risk management, incident handling, supply chain security, encryption). Aligned with ENISA's self-hosted guidance and BSI-Grundschutz modules SYS.1, APP.4, and CON.3. Produces evidence artefacts you can attach to an audit response.
We had a NIS2 readiness assessment booked for a Tuesday. On the Monday evening we ran Stack Hardening. The auditor left 40 % faster than planned because the answers were already documented.
Defender II
Complete all Stack Hardening missions + the cross-track 'NIS2 audit response' capstone (ships with the track).
- ✓W3C Verifiable Credential — Defender II level
- ✓Invitation to the Defender Guild ops-focused channel
- ✓Discount on ClawGuru Pro (Stack Hardening graduates)
- ✓Listed as hardening-capable in the optional ClawGuru talent directory (if you opt in)
Questions we already got.
Is this production-ready guidance or just theory?+
Every mission produces working config. We ship the exact flags, headers, rules, and YAML. Copy them, test them, deploy them.
We're not on Docker/K8s. Relevant?+
~70 % of the content applies to any Linux stack (systemd services, nginx, secrets handling, RBAC, CI/CD). The Docker + K8s specifics are marked clearly — skip them if they don't apply.
Do you cover cloud-specific controls (AWS IAM, GCP, Azure)?+
Partially — but this track focuses on self-hosted. Cloud-specific hardening is the Auth & Identity track plus future provider-specific bonus missions.
How is this different from CIS Benchmarks?+
CIS is a checklist. Stack Hardening is a playable simulation of the exact config changes you'd make to satisfy CIS — with explanations an operator actually reads.
Weekly Security Report
Critical CVEs, fix guides, and hardening tips — free, every week.