Feature: SSRF protection needs a configurable whitelist for local services

[Kaspre]

Summary

The built-in SSRF protection blocks all RFC 1918 private IPs, which makes it impossible to authorize requests to legitimate local services without disabling SSRF entirely.

Use Case

Running the sidecar on WSL2 with a local Ollama instance on the Windows host (172.30.192.1:11434). The host IP falls in the 172.16.0.0/12 range, so SSRF blocks it. The only upstream options are:

1. Disable SSRF entirely (SsrfProtection::disabled()) — loses all protection
2. Patch the source to add a whitelist — works but requires rebuilding for every change

A similar situation arises with any private-IP service: local databases, dev servers, other sidecars, etc.

Suggested Solution

Add a config-driven whitelist to SsrfProtection, either via:

• A CLI flag: --ssrf-allow 172.30.192.1:11434,127.0.0.1:9200
• A config file field: ssrf.allowed_endpoints = ["172.30.192.1:11434"]
• An environment variable: PREDICATE_SSRF_ALLOW=172.30.192.1:11434

The whitelist should be host:port specific (not just IP) to limit the exemption surface.

Our Workaround

We patched src/ssrf.rs to add a whitelisted_endpoints: Vec<String> field that checks host:port against a hardcoded list before running IP-range checks. Works well but requires a rebuild to change.

Minor Additional Notes

A few other things we noticed while working with the SSRF module:

• disabled() is fragile: Adding a new field to SsrfProtection requires updating disabled() manually (it doesn't derive from Default). Easy to miss.
• Glob ** directory matching footgun: In policy patterns, model-eval/** does not match model-eval itself — only its contents. This is correct per glob spec but is a common mistake when writing fs.list rules. A note in the policy docs would help.

[Kaspre]

Update: We improved our workaround — the whitelist is now loaded from the policy file rather than hardcoded in source.

We added an optional ssrf_whitelist field to the policy JSON:

{
  "ssrf_whitelist": ["172.30.192.1:11434", "127.0.0.1:8787"],
  "rules": [ ... ]
}

The policy loader (policy_loader.rs) extracts this array and passes it to SsrfProtection::with_whitelist() at startup. Changes only require editing the policy file and restarting the sidecar — no rebuild.

This is close to what we'd suggest as an upstream feature: a config-driven whitelist that lives alongside the policy rules. The ssrf_whitelist field is optional and defaults to an empty list (full SSRF enforcement) if omitted.

Patched files: src/ssrf.rs (whitelist check logic + with_whitelist() constructor), src/policy_loader.rs (extract field from JSON/YAML), src/main.rs (wire it up at startup).

[rcholic]

Update: We improved our workaround — the whitelist is now loaded from the policy file rather than hardcoded in source.

We added an optional ssrf_whitelist field to the policy JSON:

{
"ssrf_whitelist": ["172.30.192.1:11434", "127.0.0.1:8787"],
"rules": [ ... ]
}
The policy loader (policy_loader.rs) extracts this array and passes it to SsrfProtection::with_whitelist() at startup. Changes only require editing the policy file and restarting the sidecar — no rebuild.

This is close to what we'd suggest as an upstream feature: a config-driven whitelist that lives alongside the policy rules. The ssrf_whitelist field is optional and defaults to an empty list (full SSRF enforcement) if omitted.

Patched files: src/ssrf.rs (whitelist check logic + with_whitelist() constructor), src/policy_loader.rs (extract field from JSON/YAML), src/main.rs (wire it up at startup).

This is a fantastic architectural pivot. Scoping the SSRF exceptions directly to the policy file rather than a global sidecar config is significantly safer for multi-tenant environments. By tying it to the policy, the exception is strictly scoped to the specific agent that actually needs it, rather than punching a global network hole in the sidecar.

We're adopting this exact design for the upstream fix. We will:

1. Add the optional ssrf_whitelist array to the policy schema.
2. Update policy_loader.rs to extract it and pass it to SsrfProtection::with_whitelist().
3. Refactor disabled() so it isn't fragile against future struct additions.

I will also add that specific callout about the ** glob directory matching to the policy documentation—that is a classic footgun and a great catch.

@Kaspre, **Really appreciate your detailed write-up and the creative patch. PR #31 is being merged and the fix will be released in v0.7.1

[rcholic]

SSRF Whitelist for Local Services

• CLI Flag: --ssrf-allow <ENDPOINTS>

Usage:

# Allow local Ollama (WSL2) and Elasticsearch
./predicate-authorityd \
  --ssrf-allow 172.30.192.1:11434,127.0.0.1:9200 \
  --policy-file policy.json \
  run

Environment Variable:

export PREDICATE_SSRF_ALLOW="172.30.192.1:11434,127.0.0.1:9200"

TOML Config File:

[ssrf]
allowed_endpoints = ["172.30.192.1:11434", "127.0.0.1:9200"]

Policy File (JSON):

{
  "ssrf_whitelist": ["172.30.192.1:11434", "127.0.0.1:9200"],
  "rules": [...]
}

Policy File (YAML):

ssrf_whitelist:
  - "172.30.192.1:11434"
  - "127.0.0.1:9200"
rules:
  - ...

[rcholic]

Hi @Kaspre

Thanks again — I merged your SSRF whitelist approach into the latest release v0.7.1

The policy-file design was a strong improvement. If you’re open to it, I’d love to get your feedback on the hosted control plane we’re building around the sidecar (policy signing / fleet management / tenant control). Happy to give you early access and hear blunt feedback.

You can read more on the control plane features here:
https://predicatesystems.ai/docs/authority/audit-logging
https://predicatesystems.ai/docs/vault

[Kaspre]

Confirmed working in v0.7.1. The ssrf_whitelist field in policy JSON correctly allows our local Ollama host (172.30.192.1:11434) through SSRF protection. Verified via authorize endpoint — request allowed with matched rule. This replaces the two source patches (whitelist logic + SSRF re-enable) we had been maintaining since v0.6.7. Thank you!