iron-proxy

Das Problem

CI-Jobs, KI-Coding-Agents und sandboxed Container können beliebige ausgehende Anfragen stellen. Eine kompromittierte Abhängigkeit, eine Prompt-Injection oder ein bösartiger Build-Schritt kann Secrets exfiltrieren, nach Hause telefonieren oder eine Reverse Shell öffnen. Die meisten Teams haben null Sichtbarkeit darüber, was ihre Workloads verlässt, geschweige denn eine Möglichkeit, es zu stoppen.

Was iron-proxy macht

iron-proxy ist ein MITM-Egress-Proxy mit integriertem DNS-Server, der zwischen deiner nicht vertrauenswürdigen Workload und dem Internet sitzt. Er erzwingt Default-Deny an der Netzwerkgrenze, sodass die Workload nur Domains erreichen kann, die du explizit erlaubst. Echte Secrets gelangen nie in die Sandbox. Workloads verwenden Proxy-Tokens, und iron-proxy tauscht am Egress echte Credentials ein, sodass eine kompromittierte Workload nur ein Token exfiltrieren kann, das außerhalb des Proxys wertlos ist.

Einzelnes Binary. Einzelne YAML-Konfiguration.

• Default-Deny-Egress. Jede ausgehende Anfrage wird blockiert, es sei denn, das Ziel entspricht deiner Allowlist. Liste deine Domains und CIDRs auf, alles andere erhält ein 403.
• Upstream-IP-Denylist. Selbst wenn ein Host erlaubt ist, verweigert der Proxy den Verbindungsaufbau, wenn seine aufgelöste Adresse in ein verweigertes CIDR fällt — das schließt die SSRF/DNS-Rebinding-Lücke, bei der ein allowlisteter Hostname auf IMDS oder Loopback zeigt. Cloud-Metadata- Endpunkte (169.254.169.254, fd00:ec2::254 und fd20:ce::254) und Loopback sind standardmäßig verweigert; überschreibbar über proxy.upstream_deny_cidrs oder IRON_PROXY_UPSTREAM_DENY_CIDRS.
• Secret-Injection auf Grenzebene. Workloads senden Proxy-Tokens; iron-proxy ersetzt sie durch echte Secrets, bevor die Anfrage das Netzwerk verlässt. Wenn die Sandbox kompromittiert wird, erhält der Angreifer Tokens, die außerhalb des Proxys nutzlos sind.
• Audit-Trail pro Anfrage. Jede Anfrage wird als strukturiertes JSON mit dem vollständigen Ergebnis der Transform-Pipeline protokolliert: welche Secrets ausgetauscht wurden, welche Regeln übereinstimmten, was blockiert wurde und warum.
• Streaming-fähig. WebSocket-Upgrades und Server-Sent Events werden nativ geproxied. Keine spezielle Konfiguration für Agent-Workloads, die langlebige Verbindungen halten.
• Explizite Proxy-Unterstützung. Optionaler Tunnel-Listener für Tools, die nativ Proxy-Konfiguration über HTTP_PROXY, HTTPS_PROXY oder SOCKS5- Einstellungen unterstützen.
• PostgreSQL-MITM-Proxy. Optionaler Listener, der Clients gegen proxy-verwaltete Credentials authentifiziert, SET ROLE in die Upstream-Session injiziert und Client-Versuche, die Rolle zu ändern (SET ROLE, set_config('role', ...), DO-Blöcke usw.), über einen SQL-AST- Walk ablehnt. Kombiniert mit PostgreSQL Row-Level Security, um mandantenspezifische Datenisolation zu ermöglichen, wenn die Anwendung sich als gemeinsamer Service-Account-Benutzer verbindet. Erfordert, dass PgBouncer (falls verwendet) im Modus pool_mode = session läuft — Transaction- oder Statement-Pool-Modi binden Backends zwischen Queries stillschweigend neu und würden die Policy untergraben. Siehe docs.iron.sh für Details.

Gebaut für CI-Pipelines, GitHub Actions, KI-Agents (Claude Code, Cursor, Codex) und jede Umgebung, in der du Code ausführst, dem du nicht vollständig vertraust.

Installation

Docker-Images sind auf Docker Hub verfügbar, und vorgebaute Binaries für Linux/macOS (amd64/arm64) gibt es auf GitHub Releases.

Oder aus dem Quellcode bauen:```bash go build -o iron-proxy ./cmd/iron-proxy

## Schnellstart```bash
cd examples/docker-compose
docker compose up

Dies startet iron-proxy und einen Demo-Client, der fünf Anfragen durch den Proxy sendet. Prüfe die Logs, um erlaubte, blockierte und durch Secret-Rewriting veränderte Anfragen zu sehen:```bash docker compose logs proxy

Jede Anfrage erzeugt einen strukturierten JSON-Audit-Eintrag:```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"] }] }
    }
  ]
}

Abgelehnte Anfragen enthalten ein rejected_by-Feld und werden auf WARN-Ebene protokolliert. Siehe Audit-Log-Format für das vollständige Schema.

Produktive Nutzung

1. Eine CA generieren

iron-proxy beendet TLS, indem es Leaf-Zertifikate spontan generiert, die von einer von Ihnen bereitgestellten CA signiert werden. Client-Container müssen dieser CA vertrauen.```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. Ein Docker-Netzwerk erstellen

iron-proxy benötigt eine feste IP, damit Container ihr DNS darauf verweisen können:```bash
docker network create --subnet=172.20.0.0/24 iron-proxy

3. iron-proxy starten

Erstelle eine Env-Datei mit deinen Secrets (halte diese aus der Versionskontrolle heraus):```bash echo "OPENAI_API_KEY=sk-real-key" > .env

Ihre Zustimmung zur Verarbeitung Ihrer personenbezogenen Daten zum Zwecke der Bereitstellung der Dienste.```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. Container über den Proxy leiten

Der einfachste Ansatz ist DNS-basiertes Routing: Richte das DNS des Containers auf iron-proxy aus, und alle Hostname-Auflösungen werden auf die Proxy-IP aufgelöst, wodurch der Datenverkehr automatisch darüber geleitet wird:```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

Für eine stärkere Durchsetzung können Sie nftables-Regeln schichten, um Nicht-Proxy-Egress zu blockieren, oder TPROXY für die Interception auf Kernel-Ebene verwenden. Siehe [Routing traffic to the proxy](#routing-traffic-to-the-proxy) für Details zu jedem Ansatz.

## Warum iron-proxy?