jfraeys/infra
Watch
1
0
Fork
You've already forked infra
 0
Code Issues 21 Pull requests 8 Projects Releases Packages Wiki Activity Actions

feat(ci): run the production-only hardening checks after the staging deploy #86

Merged
jfraeys merged 1 commit from jfraeys/fix/post-deploy-hardening-checks into main 2026-10-12 23:15:13 -04:00
Conversation 0 Commits 1 Files changed 3 +28 -9
jfraeys commented 2026-10-12 22:49:07 -04:00
Owner
Copy link

validate-hardening skips its '(production only)' checks on staging hosts because it runs before the deploy, when auditd and Docker's daemon.json do not exist yet, so those settings were never verified on a deployed result.

  • playbooks/validate-hardening.yml: the 7 checks (auditd running, auditd docker_socket/sudoers rules on services and auditd on web, daemon.json present, live-restore, no-new-privileges) now also run when -e validate_post_deploy=true. The nginx check stays production-only (nginx comes from the app's role, which staging does not deploy without an app repo).
  • staging.sh: run_full_check runs a second pass with validate_post_deploy=true after both deploys, before the connectivity check.
  • docs/staging-parity.md updated.

Heads-up: this makes the pipeline fail if staging really lacks one of these settings (e.g. auditd rules). That would be a real finding about a fresh install, not a flaky check; the first staging run after merge decides.

Plan: L6 of the loose-ends track.

🤖 Generated with Claude Code

validate-hardening skips its '(production only)' checks on staging hosts because it runs before the deploy, when auditd and Docker's daemon.json do not exist yet, so those settings were never verified on a deployed result. - playbooks/validate-hardening.yml: the 7 checks (auditd running, auditd docker_socket/sudoers rules on services and auditd on web, daemon.json present, live-restore, no-new-privileges) now also run when -e validate_post_deploy=true. The nginx check stays production-only (nginx comes from the app's role, which staging does not deploy without an app repo). - staging.sh: run_full_check runs a second pass with validate_post_deploy=true after both deploys, before the connectivity check. - docs/staging-parity.md updated. Heads-up: this makes the pipeline fail if staging really lacks one of these settings (e.g. auditd rules). That would be a real finding about a fresh install, not a flaky check; the first staging run after merge decides. Plan: L6 of the loose-ends track. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
feat(ci): run the production-only hardening checks after the staging deploy
All checks were successful
Lint / lint (pull_request) Successful in 1m30s
Details
Secret scan / scan (pull_request) Successful in 19s
Details
d854fea9ae
 
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jfraeys/infra!86
No description provided.