iron-proxy

Le problème

Les jobs CI, les agents de codage IA et les conteneurs sandboxés peuvent effectuer des requêtes sortantes arbitraires. Une dépendance compromise, une injection de prompt ou une étape de build malveillante peut exfiltrer des secrets, effectuer un phone home ou ouvrir un reverse shell. La plupart des équipes n'ont aucune visibilité sur ce qui sort de leurs workloads, et encore moins de moyen de l'arrêter.

Ce que fait iron-proxy

iron-proxy est un proxy de sortie MITM avec un serveur DNS intégré qui se place entre votre workload non fiable et Internet. Il applique une politique de refus par défaut à la frontière du réseau, de sorte que le workload ne peut atteindre que les domaines que vous autorisez explicitement. Les vrais secrets n'entrent jamais dans le sandbox. Les workloads utilisent des jetons de proxy, et iron-proxy substitue les vrais identifiants à la sortie, ce qui signifie qu'un workload compromis peut exfiltrer un jeton qui est sans valeur en dehors du proxy.

Un seul binaire. Une seule configuration YAML.

• Sortie en refus par défaut. Chaque requête sortante est bloquée sauf si la destination correspond à votre liste d'autorisation. Listez vos domaines et CIDR, tout le reste reçoit un 403.
• Liste de refus d'IP en amont. Même lorsqu'un hôte est autorisé, le proxy refuse de le contacter si son adresse résolue se trouve dans un CIDR refusé — comblant la faille SSRF/DNS-rebinding où un nom d'hôte autorisé pointe vers IMDS ou le loopback. Les points de terminaison de métadonnées cloud (169.254.169.254, fd00:ec2::254 et fd20:ce::254) et le loopback sont refusés par défaut ; remplacez cela via proxy.upstream_deny_cidrs ou IRON_PROXY_UPSTREAM_DENY_CIDRS.
• Injection de secrets au niveau de la frontière. Les workloads envoient des jetons de proxy ; iron-proxy les remplace par de vrais secrets avant que la requête ne parte. Si le sandbox est compromis, l'attaquant obtient des jetons inutiles en dehors du proxy.
• Piste d'audit par requête. Chaque requête est journalisée en JSON structuré avec le résultat complet du pipeline de transformation : quels secrets ont été échangés, quelles règles ont correspondu, ce qui a été bloqué et pourquoi.
• Compatible avec le streaming. Les upgrades WebSocket et les Server-Sent Events sont proxifiés nativement. Aucune configuration spéciale pour les workloads d'agents qui maintiennent des connexions de longue durée.
• Prise en charge explicite du proxy. Écouteur tunnel optionnel pour les outils qui prennent nativement en charge la configuration de proxy via HTTP_PROXY, HTTPS_PROXY ou les paramètres SOCKS5.
• Proxy MITM PostgreSQL. Écouteur optionnel qui authentifie les clients auprès d'identifiants gérés par le proxy, injecte SET ROLE sur la session en amont et rejette les tentatives du client de modifier le rôle (SET ROLE, set_config('role', ...), blocs DO, etc.) via un parcours d'AST SQL. S'associe à la sécurité au niveau des lignes de PostgreSQL pour offrir une isolation des données par locataire lorsque l'application se connecte en tant qu'utilisateur de compte de service partagé. Nécessite que PgBouncer (s'il est utilisé) fonctionne en pool_mode = session — les modes de pool transaction ou statement relient silencieusement les backends entre les requêtes et annuleraient la politique. Voir docs.iron.sh pour plus de détails.

Conçu pour les pipelines CI, GitHub Actions, les agents IA (Claude Code, Cursor, Codex) et tout environnement où vous exécutez du code auquel vous ne faites pas entièrement confiance.

Installation

Les images Docker sont disponibles sur Docker Hub et les binaires précompilés pour Linux/macOS (amd64/arm64) sont sur GitHub Releases.

Ou compilez depuis les sources :```bash go build -o iron-proxy ./cmd/iron-proxy

## Démarrage rapide```bash
cd examples/docker-compose
docker compose up

Ceci démarre iron-proxy et un client de démonstration qui envoie cinq requêtes à travers le proxy. Consultez les journaux pour voir les requêtes autorisées, bloquées et réécrites avec des secrets :```bash docker compose logs proxy

Chaque requête produit une entrée d'audit JSON structurée :```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"] }] }
    }
  ]
}

Les requêtes rejetées incluent un champ rejected_by et sont journalisées au niveau WARN. Voir Format du journal d'audit pour le schéma complet.

Utilisation en production

1. Générer une CA

iron-proxy termine le TLS en générant des certificats feuilles à la volée, signés par une CA que vous fournissez. Les conteneurs clients doivent faire confiance à cette 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. Créer un réseau Docker

iron-proxy a besoin d'une IP fixe afin que les conteneurs puissent pointer leur DNS vers lui :```bash
docker network create --subnet=172.20.0.0/24 iron-proxy

3. Démarrer iron-proxy

Créez un fichier env avec vos secrets (gardez-le hors du contrôle de version) :```bash echo "OPENAI_API_KEY=sk-real-key" > .env

| `-w, --wordlist` | Chemin vers le fichier de liste de mots |```bash
docker run -d --name iron-proxy \
  --network iron-proxy --ip 172.20.0.2 \
  -v $(pwd)/proxy.yaml:/etc/iron-proxy/proxy.yaml:ro \
  -v $(pwd)/certs/ca.crt:/etc/iron-proxy/ca.crt:ro \
  -v $(pwd)/certs/ca.key:/etc/iron-proxy/ca.key:ro \
  --env-file .env \
  ironsh/iron-proxy:latest -config /etc/iron-proxy/proxy.yaml

4. Router les conteneurs via le proxy

L'approche la plus simple est le routage basé sur le DNS : pointez le DNS du conteneur vers iron-proxy et toutes les résolutions de noms d'hôtes se résolvent vers l'IP du proxy, acheminant ainsi le trafic à travers celui-ci automatiquement :```bash docker run --rm
--network iron-proxy
--dns 172.20.0.2
-v $(pwd)/certs/ca.crt:/certs/ca.crt:ro
curlimages/curl --cacert /certs/ca.crt https://httpbin.org/get

Pour une application plus stricte, superposez des règles nftables pour bloquer l'egress hors proxy, ou utilisez
TPROXY pour une interception au niveau du noyau. Consultez [Acheminement du trafic vers le
proxy](#routing-traffic-to-the-proxy) pour plus de détails sur chaque approche.

## Pourquoi iron-proxy ?