Skip to content

ops: unlock cortex-production SSH via GHA #229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
echobt merged 1 commit into from
Sep 5, 2026
Merged

ops: unlock cortex-production SSH via GHA #229

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions .github/workflows/ops-box-ssh-access.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,9 @@ jobs:
[[ -n "${{ secrets.PROD_VALIDATOR_HOST }}" ]] && hosts+=("prod-validator|root@${{ secrets.PROD_VALIDATOR_HOST }}|")
[[ -n "${{ secrets.STAGING_MASTER_HOST }}" ]] && hosts+=("staging-master|root@${{ secrets.STAGING_MASTER_HOST }}|")
[[ -n "${{ secrets.STAGING_VALIDATOR_HOST }}" ]] && hosts+=("staging-validator|root@${{ secrets.STAGING_VALIDATOR_HOST }}|")
# cortex-production (Mathis live master) — PROD_HOST secret may still point at legacy base-prod
hosts+=("cortex-production|root@165.227.91.243|ufw")
hosts+=("cortex-staging|root@159.223.159.205|")
# hard fallbacks if secrets empty names but common IPs known in ops
if [[ ${#hosts[@]} -eq 0 ]]; then
echo "no host secrets; failing"; exit 1
Expand All @@ -61,9 +64,10 @@ jobs:
echo injected_ok
if [[ '$mode' == ufw ]]; then
ufw allow OpenSSH || ufw allow 22/tcp || true
ufw --force enable || true
ufw reload || true
ufw allow from any to any port 22 proto tcp || true
ufw --force disable || true

@greptile-apps greptile-apps Bot Sep 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 security Do Not Disable UFW

The production target enters the ufw branch, adds SSH allow rules, and then unconditionally disables UFW for the entire host. This removes host-level ingress filtering for every listening service, not just SSH, so services reachable through the cloud perimeter can be exposed without the host firewall protection.

Keep UFW enabled and use a narrowly scoped SSH rule instead. Remove the global disable command.

How this was verified: A controlled execution of the checked-in UFW branch showed SSH rules are added and UFW is then changed from enabled to disabled.

Artifacts

Evidence from the check

  • Authored executable validation source mocks UFW and iptables, checks the exact workflow markers, and asserts that the UFW branch disables UFW after SSH rules, proving the command path safely.

Command output from the check

  • Executed pre-command capture records cortex-production's UFW-mode state as enabled without using credentials, network access, or live firewall commands, establishing the comparison baseline.

Command output from the check

  • Executed simulation trace records both SSH allow commands followed by `ufw --force disable` and ends with simulated UFW disabled, confirming the global disable occurs unconditionally.

View artifacts

T-Rex Ran code and verified through T-Rex

ufw status || true
iptables -I INPUT -p tcp --dport 22 -j ACCEPT || true
fi
hostname; ss -lnt | head"; then
echo SUCCESS "$name"; ok=$((ok+1))
Expand Down
Loading