ops: GHA inject box SSH pubkey + ufw prod - #228
Conversation
Greptile SummarySummary
These issues must be resolved before merging. Confidence Score: 0/5Not safe to merge: the workflow can cause a production connectivity outage, silently accept incomplete infrastructure changes, and exposes a privileged credential path to mutable action code. Executed checks reproduced firewall error masking and partial host-rollout success, confirmed mixed-environment SSH key selection, verified required production ports, and verified the mutable checkout-to-token path. Files Needing Attention: .github/workflows/ops-box-ssh-access.yml
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| ufw allow OpenSSH || ufw allow 22/tcp || true | ||
| ufw --force enable || true |
There was a problem hiding this comment.
If the production host uses UFW's default-deny incoming policy, this workflow enables UFW after allowing only SSH. The production master serves traffic on ports 80, 443, and 8080, so dispatching it can block the public gateway and validator connection, causing a production outage.
Artifacts
- The authored Bash script checks the exact workflow UFW commands and the repository's production port requirements; it encodes the narrow supplied finding.
- The captured repository excerpts show the SSH-only UFW enablement, production port publishing, Caddy HTTPS contract, and DigitalOcean firewall rules; they establish the compared static state.
- The executed validation script exits 0 after confirming SSH-only host-UFW setup alongside required production ports 80, 443, and 8080; the supplied finding is supported.
- A minimal authored Bash harness stubs UFW failures and executes the workflow-equivalent remote command, ending with the finding that masked failures produce host success.
- The executed harness output shows all mocked UFW operations exit 42 yet the current block reports SUCCESS, while the fail-closed comparison reports FAIL, ending with the finding that errors are masked.
- The captured changed-file inspection shows `|| true` at lines 63-66 and the subsequent SUCCESS branch at lines 68-69, ending with the finding that the workflow can report a host successful after UFW failure.
| ufw allow OpenSSH || ufw allow 22/tcp || true | ||
| ufw --force enable || true | ||
| ufw reload || true | ||
| ufw status || true |
There was a problem hiding this comment.
Every UFW operation suppresses failures with || true. A missing UFW installation or failed allow, enable, reload, or status command still lets the SSH block report the host as successful, so the workflow can finish green without creating the requested firewall access.
Artifacts
- The authored Bash script checks the exact workflow UFW commands and the repository's production port requirements; it encodes the narrow supplied finding.
- The captured repository excerpts show the SSH-only UFW enablement, production port publishing, Caddy HTTPS contract, and DigitalOcean firewall rules; they establish the compared static state.
- The executed validation script exits 0 after confirming SSH-only host-UFW setup alongside required production ports 80, 443, and 8080; the supplied finding is supported.
- A minimal authored Bash harness stubs UFW failures and executes the workflow-equivalent remote command, ending with the finding that masked failures produce host success.
- The executed harness output shows all mocked UFW operations exit 42 yet the current block reports SUCCESS, while the fail-closed comparison reports FAIL, ending with the finding that errors are masked.
- The captured changed-file inspection shows `|| true` at lines 63-66 and the subsequent SUCCESS branch at lines 68-69, ending with the finding that the workflow can report a host successful after UFW failure.
| - name: Install SSH key | ||
| run: | | ||
| set -euo pipefail | ||
| KEY="${{ secrets.PROD_SSH_KEY || secrets.STAGING_SSH_KEY }}" |
There was a problem hiding this comment.
When both credentials are configured, this selects PROD_SSH_KEY once and uses it for every target, including the staging hosts. The staging deployment uses STAGING_SSH_KEY separately, so staging hosts that accept only their scoped key cannot receive the box key and firewall update.
Artifacts
- The authored shell validator asserts the exact workflow definitions and runs fixture key selection plus host-loop expansion, showing the test method.
- The executed staging-only fixture selects STAGING_SSH_KEY and emits attempts solely for the two staging hosts, establishing the scoped baseline.
- The executed mixed fixture selects PROD_SSH_KEY and emits attempts for both production and staging hosts, proving the credential-target mismatch.
| echo "::endgroup::" | ||
| done | ||
| echo "ok_hosts=$ok" | ||
| test "$ok" -gt 0 |
There was a problem hiding this comment.
The final assertion requires only one successful target. If another host rejects the SSH key or its update fails, the workflow still succeeds after updating a different host, silently leaving the rollout incomplete.
Artifacts
- Minimal Bash harness simulating one successful and one failed target while applying the workflow's exact final predicate; it tests that partial success is accepted.
- Captured execution of the harness from `/home/user/repo`, showing one success, one failure, and an overall exit code of 0; the workflow condition permits partial rollout.
- Captured numbered workflow excerpt showing the success counter, failure branch, and `test "$ok" -gt 0` at line 76; the condition only requires one successful host.
| runs-on: ubuntu-latest | ||
| timeout-minutes: 20 | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
This workflow resolves actions/checkout@v4 through a mutable tag before it runs the checked-out do-firewall action with the DigitalOcean token. If the tag is repointed or compromised, altered checkout behavior can replace the local firewall action before it receives that privileged token.
How this was verified: The workflow checks out through
actions/checkout@v4before passingDIGITALOCEAN_TOKENto the checked-out firewall action.
Artifacts
- The authored Bash script checks the workflow ordering and composite-action token path; it is the executable proof used for this validation.
- Captured execution output records lines 18, 32, 35, 41, and 65 and exits successfully, confirming the supplied security proof.
1 participant
Injects box@cursor pubkey via deploy SSH secrets; ufw allow 22 on prod master. workflow_dispatch only.