v1.3.17 — Geo-blocking + IP allowlist guide¶
Docs-only release. No code, no schema, no compose surface changes. Behaviour identical to v1.3.16.
Why¶
Operators migrating from Zoraxy / NPM / Traefik routinely look for the equivalent of two features those proxies surface as first-class UI knobs:
- Country blacklist (block all traffic from a list of jurisdictions)
- IP allowlist (host visible on public DNS / cert but reachable only from internal IPs)
argos does not have UI for either. The bundled CrowdSec sidecar already implements country-based blocking via decisions, and LAN-only access has three operational paths (firewall, custom CrowdSec scenario, or wait for the roadmap toggle). The recipes existed in scattered CrowdSec docs; v1.3.17 collects them on one operator-facing page.
What ships¶
docs/operations/access-control.md (new)¶
Sections:
- Country-based blocking (geo-blocking) -- the canonical
cscli decisions add --scope Country --value <ISO>command,--duration/--reason/--typeflags, list / delete commands, the ~15 s bouncer-poll propagation window, audit trail surface in the Threats tab. - IP allowlist (LAN-only access) -- three approaches in recommended order:
- Approach A: firewall at the router -- cleanest, leaves argos as a pure proxy + WAF + SSO layer, no feature dependency on argos. Requires a router with firewall rule support (UDM-Pro, OPNsense, OpenWrt, pfSense, ...). Not feasible on consumer ISP gateways that only expose port-forward toggles.
- Approach B: CrowdSec range whitelist via custom scenario -- possible but non-trivial; CrowdSec's acquisition pipeline is the wrong layer for "block by default". Documented as an escape hatch, not recommended.
- Approach C: wait for native per-host toggle -- on the roadmap. Implementation is straightforward (Caddy
@lanmatcher withremote_ipagainst RFC 1918 + loopback) but does not ship in this release.
- How access control interacts with AppSec -- explains the request-pipeline ordering: bouncer check first, AppSec second, reverse_proxy last. Geo-blocked requests never reach AppSec (saves rule-evaluation budget on traffic that was never going to land anyway).
- Migration cheat-sheet -- table mapping Zoraxy / NPM / Traefik features to argos equivalents: single-IP / range / country blacklist; country whitelist (no direct equivalent, with rationale); IP whitelist (the three approaches); user-agent block (existing CrowdSec scenario); path-based deny (existing per-host security rules).
Cross-links¶
docs/features/appsec.md-- "Related" section gains a pointer to the new access-control guide so operators reading about WAF rules can also find the bouncer-side decision recipe.docs/operations/troubleshooting.md-- two short new entries that hand off to the new guide:- "Why is my host reachable from the internet? (LAN-only intent)"
- "Traffic from a country I want blocked still reaches the host"
mkdocs.yml¶
New "Access control" entry under the Operations section, positioned between "Cert troubleshooting" and "upgrading" (operationally adjacent to the post-deploy hardening flow).
Sanitization¶
The new doc uses placeholder ISO codes (<ISO>, XX, YY, ZZ) and abstract <duration> / <reason> parameters throughout. No specific country codes, no operator-specific LAN ranges. RFC 1918 references are generic (192.0.2.0/24- style RFC 5737 example, or the abstract "RFC 1918" without naming the operator's actual subnet).
./scripts/check-no-personal-data.sh runs clean against the new content.
Verification¶
mkdocs build --strict-- passes; the new page renders cleanly, the cross-links resolve, the nav entry shows up between Cert troubleshooting and Upgrading../scripts/check-no-personal-data.sh-- exit 0, no operator data found.- Backend / frontend / migration / smoke -- not exercised (docs-only).
Files changed¶
docs/operations/access-control.md(new) -- the guide.docs/features/appsec.md-- one line added in Related.docs/operations/troubleshooting.md-- two short entries added in the Hosts/reverse-proxy section.mkdocs.yml-- nav entry.backend/cmd/argos/main.go-- version bump.frontend/package.json-- version bump.CHANGELOG.md-- this entry.docs/release-notes/v1.3.17.md-- this file.
Upgrade¶
The build will produce a new image solely for the version- string bake. No runtime behaviour changes; operators who deployed v1.3.16 can stay on it without losing functionality. The upgrade is meaningful only if the operator wants the embedded version string + the docs portal published with the new page.
Not changed¶
- No code paths in backend or frontend.
- No migrations, no env vars, no compose surface.
- Every v1.3.16 feature (preserve_host, AppSec block-mode CRS, WS transport versions, target health badges, CLI password reset, ...) unchanged.