iron-proxy

Il problema

I job di CI, gli agenti di coding AI e i container in sandbox possono effettuare richieste in uscita arbitrarie. Una dipendenza compromessa, un prompt injection o uno step di build malevolo possono esfiltrare segreti, contattare casa o aprire una reverse shell. La maggior parte dei team non ha alcuna visibilità su ciò che esce dai propri workload, figuriamoci un modo per fermarlo.

Cosa fa iron-proxy

iron-proxy è un proxy egress MITM con un server DNS integrato che si colloca tra il tuo workload non attendibile e internet. Applica il default-deny al confine della rete, così il workload può raggiungere solo i domini che autorizzi esplicitamente. I segreti reali non entrano mai nella sandbox. I workload usano proxy token, e iron-proxy sostituisce le credenziali reali in uscita, il che significa che un workload compromesso può esfiltrare un token che è inutile al di fuori del proxy.

Binario singolo. Configurazione YAML singola.

• Egress default-deny. Ogni richiesta in uscita viene bloccata a meno che la destinazione corrisponda alla tua allowlist. Elenca i tuoi domini e CIDR, tutto il resto riceve un 403.
• Deny list degli IP upstream. Anche quando un host è consentito, il proxy rifiuta di contattarlo se il suo indirizzo risolto ricade all'interno di un CIDR negato — chiudendo la falla SSRF/DNS-rebinding in cui un hostname in allowlist punta a IMDS o al loopback. Gli endpoint di metadata cloud (169.254.169.254, fd00:ec2::254 e fd20:ce::254) e il loopback sono negati per impostazione predefinita; puoi sovrascrivere tramite proxy.upstream_deny_cidrs o IRON_PROXY_UPSTREAM_DENY_CIDRS.
• Iniezione di segreti a livello di confine. I workload inviano proxy token; iron-proxy li sostituisce con i segreti reali prima che la richiesta esca. Se la sandbox viene compromessa, l'attaccante ottiene token inutili al di fuori del proxy.
• Audit trail per richiesta. Ogni richiesta viene registrata come JSON strutturato con il risultato completo della pipeline di trasformazione: quali segreti sono stati scambiati, quali regole hanno corrisposto, cosa è stato bloccato e perché.
• Consapevole dello streaming. Gli upgrade WebSocket e i Server-Sent Events vengono proxati nativamente. Nessuna configurazione speciale per i workload degli agenti che mantengono connessioni a lunga durata.
• Supporto esplicito al proxy. Listener tunnel opzionale per strumenti che supportano nativamente la configurazione del proxy tramite HTTP_PROXY, HTTPS_PROXY o impostazioni SOCKS5.
• Proxy MITM PostgreSQL. Listener opzionale che autentica i client tramite credenziali gestite dal proxy, inietta SET ROLE sulla sessione upstream e rifiuta i tentativi del client di modificare il ruolo (SET ROLE, set_config('role', ...), blocchi DO, ecc.) tramite un walk dell'AST SQL. Si abbina alla row-level security di PostgreSQL per fornire isolamento dei dati per tenant quando l'applicazione si connette come utente service-account condiviso. Richiede che PgBouncer (se utilizzato) sia eseguito in pool_mode = session — le modalità di pooling transaction o statement riassociano silenziosamente i backend tra le query e vanificherebbero la policy. Vedi docs.iron.sh per i dettagli.

Pensato per pipeline CI, GitHub Actions, agenti AI (Claude Code, Cursor, Codex) e qualsiasi ambiente in cui esegui codice di cui non ti fidi completamente.

Installazione

Le immagini Docker sono disponibili su Docker Hub e i binari precompilati per Linux/macOS (amd64/arm64) sono su GitHub Releases.

Oppure compila dai sorgenti:```bash go build -o iron-proxy ./cmd/iron-proxy

## Avvio rapido```bash
cd examples/docker-compose
docker compose up

Questo avvia iron-proxy e un client demo che invia cinque richieste attraverso il proxy. Controlla i log per vedere le richieste consentite, bloccate e con segreti riscritti:```bash docker compose logs proxy

Ogni richiesta produce una voce di audit JSON strutturata:```json
{
  "host": "httpbin.org",
  "method": "GET",
  "path": "/headers",
  "action": "allow",
  "status_code": 200,
  "duration_ms": 142,
  "request_transforms": [
    { "name": "allowlist", "action": "continue" },
    {
      "name": "secrets",
      "action": "continue",
      "annotations": { "swapped": [{ "secret": "OPENAI_API_KEY", "locations": ["header:Authorization"] }] }
    }
  ]
}

Le richieste rifiutate includono un campo rejected_by e vengono registrate a livello WARN. Consulta Formato del registro di audit per lo schema completo.

Utilizzo in produzione

1. Generare una CA

iron-proxy termina il TLS generando certificati foglia al volo, firmati da una CA che fornisci tu. I container client devono considerare attendibile questa CA.```bash mkdir -p certs openssl genrsa -out certs/ca.key 4096 openssl req -x509 -new -nodes
-key certs/ca.key
-sha256 -days 3650
-subj "/CN=iron-proxy CA"
-addext "basicConstraints=critical,CA:TRUE"
-addext "keyUsage=critical,keyCertSign"
-out certs/ca.crt

### 2. Creare una rete Docker

iron-proxy necessita di un IP fisso in modo che i container possano puntare il loro DNS ad esso:```bash
docker network create --subnet=172.20.0.0/24 iron-proxy

3. Avvia iron-proxy