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

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

### 2. Ein Docker-Netzwerk erstellen

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

I don't see any content after "INPUT:" in your message — the chunk to translate appears to be missing. Please re-send chunk 15 with the actual Markdown content included, and I'll translate it into German right away.```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

Für eine strengere Durchsetzung können Sie nftables-Regeln schichten, um Non-Proxy-Ausgangsverkehr zu blockieren, oder verwenden Sie
TPROXY für das Abfangen auf Kernel-Ebene. Siehe [Routing traffic to the
proxy](#routing-traffic-to-the-proxy) für Details zu jedem Ansatz.

## Warum iron-proxy?

|                          | iron-proxy                     | Squid                       | mitmproxy                 | Envoy                              |
| ------------------------ | ------------------------------ | --------------------------- | ------------------------- | ---------------------------------- |
| Default-Deny-Egress      | Integriert                     | Erfordert komplexe ACL-Konfiguration | Erfordert benutzerdefiniertes Scripting | Erfordert RBAC-/Filterkonfiguration |
| Secret-Injection         | Integriert                     | Nein                        | Nein                      | Nein                               |
| Strukturierte Audit-Protokollierung | Integriert, Traces pro Transformationsschritt | Einfache Zugriffsprotokolle | Plugin-basiert | Konfigurierbare Zugriffsprotokolle |
| Einrichtungskomplexität  | Einzelne Binärdatei + YAML     | Umfangreiche Konfigurationssprache | Python-Scripting | Komplexes YAML oder Control Plane  |

iron-proxy ist gezielt für eine Aufgabe entwickelt: die Kontrolle und Überwachung des ausgehenden Datenverkehrs (Egress) von nicht vertrauenswürdigen Workloads. Squid kann Default-Deny umsetzen, erfordert jedoch erhebliche ACL-Konfiguration und hat kein Konzept für Secret Injection. mitmproxy ist ein großartiges Debugging-Tool, aber nicht für die Durchsetzung im Produktionsbetrieb ausgelegt. Envoy ist ein Allzweck-Proxy, der so konfiguriert werden kann, dass er Teile davon übernimmt, aber das ist weitaus komplexer, als das Problem es erfordert.

## Wie es funktioniert

iron-proxy betreibt einen DNS-Server und einen HTTP/HTTPS-Proxy. Richten Sie den DNS Ihres Containers auf iron-proxy aus, und alle Hostnamen-Auflösungen werden auf die Proxy-IP aufgelöst, wodurch der Datenverkehr automatisch über den Proxy geleitet wird. Der Proxy beendet TLS (indem er spontan Blattzertifikate aus einer von Ihnen bereitgestellten CA erzeugt), führt die Anfrage durch eine geordnete Transformations-Pipeline, leitet sie an den Upstream weiter und führt die Antwort wieder durch die Pipeline.```
Container → DNS lookup → iron-proxy IP → TLS termination → transforms → upstream

### DNS

Standardmäßig wird alles zu `proxy_ip` aufgelöst, wodurch der Datenverkehr durch
den Proxy geleitet wird. Ausnahmen:

- **`passthrough`:** Glob-Muster, die an den OS-Resolver weitergeleitet werden (z. B.
  `*.internal.corp`). Datenverkehr zu diesen Hosts umgeht den Proxy vollständig.
- **`records`:** statische A- oder CNAME-Einträge. Höchste Priorität.

### Response-Retry-Handler

Setzen Sie `IRON_RESPONSE_RETRY_HANDLER_URL`,
`IRON_RESPONSE_RETRY_COMPLETE_URL`, `IRON_RESPONSE_RETRY_HANDLER_TOKEN`,
`IRON_RESPONSE_RETRY_HANDLER_SANDBOX_ID` sowie eine durch Kommas getrennte
`IRON_RESPONSE_RETRY_STATUSES`-Liste, um extern autorisierte Antwortwiederholungen
zu aktivieren. Der Autorisierungshandler empfängt das exakte Upstream-Schema, die Authority,
die Methode, den Pfad bzw. die Query, die Wiederholbarkeit, den Antwortstatus und die Antwortheader,
den Trace-Kontext sowie die Sandbox-Identität. Er kann Anforderungsheader plus eine Attempt-ID
für eine exakte Wiederholung zurückgeben. Der Abschlusshandler empfängt dann den
Wiederholungsstatus und die Antwortheader, die über `IRON_RESPONSE_RETRY_COMPLETION_HEADERS` ausgewählt werden;
standardmäßig ist dies `Payment-Receipt`.

Antwort-Bodies werden niemals an einen der beiden Handler gesendet, Ziele können nicht geändert werden,
und Verbindungs-/Framing-Header werden abgelehnt. Anforderungen über
`proxy.max_request_body_bytes` werden normal verarbeitet, aber als nicht wiederholbar markiert;
wenn eine Wiederholung angefordert wird, wird ihre ursprüngliche Antwort zurückgegeben. Auch bei
Handler-Fehlern bleibt die ursprüngliche Antwort erhalten. Handler-URLs müssen HTTPS verwenden, sofern es
sich nicht um Loopback handelt oder `IRON_RESPONSE_RETRY_HANDLER_ALLOW_HTTP=true` explizit für ein
vertrauenswürdiges internes Netzwerk konfiguriert ist. Weiterleitungen werden abgelehnt, und das Response-Retry-Token
muss unabhängig vom Control-Plane-Token konfiguriert werden. WebSocket- und gRPC-Anforderungen sowie
Streaming-Anforderungen mit unbekannter Länge umgehen die Response-Retry-Verarbeitung.

Wenn ein vertrauenswürdiger Handler innerhalb von `proxy.upstream_deny_cidrs` aufgelöst wird, setzen
Sie `IRON_RESPONSE_RETRY_HANDLER_ALLOW_CIDRS` auf eine durch Kommas getrennte Liste der
engen privaten CIDRs, die er verwenden darf. Diese Ausnahme gilt nur für die exakt
konfigurierten Authorize- und Complete-Endpunkte; normaler weitergeleiteter Datenverkehr unterliegt
weiterhin der vollständigen Upstream-Deny-Liste. Öffentliche, Loopback-, Link-Local- und Cloud-Metadaten-Bereiche
können über diese Einstellung nicht hinzugefügt werden.

### Allowlist

Default-Deny. Anforderungen müssen mindestens einem Domain-Glob oder einer CIDR entsprechen, um fortzufahren.
Nicht übereinstimmende Anforderungen erhalten ein `403 Forbidden`.

Domain-Muster verwenden Glob-Matching: `*.example.com` entspricht jeder Subdomain und
`example.com` selbst.

**Warnmodus:** Setzen Sie `warn: true`, um zu beobachten, was die Allowlist blockieren würde, ohne
sie tatsächlich durchzusetzen. Anforderungen, die abgelehnt würden, werden durchgelassen, aber
in der Transform-Trace mit `"action": "warn"` annotiert. Dies ist nützlich, um
neue Allowlist-Regeln einzuführen oder bestehenden Datenverkehr zu prüfen, bevor auf
Durchsetzung umgestellt wird.

### Annotieren

Erfasst HTTP-Anforderungsheader in Audit-Log-Annotationen basierend auf
Host-/Methoden-/Pfad-Regeln. Dies ist nützlich, um Audit-Logs mit
anforderungsspezifischem Kontext wie Request-IDs anzureichern, ohne den Proxy-Kern zu verändern.

Jede Annotationsgruppe gibt abzugleichende Regeln und zu erfassende Header an. Wenn eine
Anforderung einer beliebigen Regel in einer Gruppe entspricht, werden die angegebenen Header-Werte als
`header:<Name>`-Einträge in die Transform-Trace-Annotationen geschrieben. Nicht übereinstimmende
Anforderungen werden unverändert durchgereicht. Diese Transformation lehnt niemals Anforderungen ab.

> **Warnung:** Header-Werte werden im Klartext im Audit-Log ausgegeben. Protokollieren Sie
> nur Header, die sicher offengelegt werden können, wie Request-IDs oder Header, die
> Proxy-Secret-Tokens enthalten. Protokollieren Sie keine Header, die rohe Geheimnisse enthalten.```yaml
transforms:
  - name: annotate
    config:
      annotations:
        - rules:
            - host: "api.openai.com"
              methods: ["POST"]
              paths: ["/v1/*"]
          headers: ["x-request-id"]
        - rules:
            - host: "*.anthropic.com"
          headers: ["x-request-id"]

### Body-Erfassung

Zeichnet den dekodierten Request-Body übereinstimmender Anfragen auf und stellt ihn
im Audit-Log-Datensatz in einer `body_capture`-Gruppe bereit, die `request_body` und
`request_body_truncated` enthält. Nützlich, um die Payloads zu prüfen, die den
Proxy durchlaufen, z. B. die Prompts, die eine Sandbox an einen LLM-Anbieter sendet,
ohne den Upstream-Datenverkehr zu verändern.

Hosts, Methoden und Pfade werden mit derselben `rules`-Syntax wie `allowlist` und
`secrets` abgeglichen. `max_request_body_bytes` begrenzt, wie viel von jedem Body
erfasst wird; Bodies, die größer als die Grenze sind, werden auf das Präfix gekürzt
und `request_body_truncated` wird auf `true` gesetzt. Die Grenze beträgt standardmäßig
16 KiB und ist unabhängig von der globalen `proxy.max_request_body_bytes`-Begrenzung.
Diese Transformation ist rein beobachtend: Sie lehnt niemals eine Anfrage ab, und
Lesefehler des Bodys werden im Trace annotiert, anstatt die Anfrage fehlschlagen zu lassen.

Bei einer erfolgreichen Erfassung wird der Eintrag der Transformation in `request_transforms`
mit `captured_bytes` und `truncated` annotiert, sodass der Trace protokolliert, dass ein
Body erfasst wurde, ohne den Body selbst zu duplizieren.

Antwort-Bodies werden nicht erfasst. Streaming-Antworten (SSE) müssten vor dem
Weiterleiten vollständig gepuffert werden, was den Client aufhalten würde.

> **Warnung:** Erfasste Bodies werden im Klartext ins Audit-Log geschrieben. Wenn
> `secrets` mit `match_body: true` läuft, platziere `body_capture` *vor* `secrets`,
> damit das Audit-Log die Proxy-Tokens der Sandbox protokolliert statt der echten
> Anmeldedaten, die `secrets` in den Body einsetzt.```yaml
transforms:
  - name: body_capture
    config:
      max_request_body_bytes: 16384
      rules:
        - host: "api.anthropic.com"
          methods: ["POST"]
          paths: ["/v1/messages"]
        - host: "api.openai.com"
          methods: ["POST"]
          paths: ["/v1/chat/completions"]

Invarianten:

- Der Judge kann nur ablehnen. Er genehmigt nie eine Anfrage, die die statische Allowlist abgelehnt hätte. Statisches Deny gewinnt immer.
- Nicht passende Anfragen werden ignoriert: kein LLM-Aufruf, keine Audit-Anmerkungen.
- Bei LLM-Fehler, Timeout, offenem Circuit Breaker oder fehlerhafter Modellausgabe greift das konfigurierte `fallback`. `deny` blockiert die Anfrage (die empfohlene Standardeinstellung für die Produktion). `skip` überlässt den Rest der Pipeline; da iron-proxy standardmäßig Deny ist, werden nicht passende Anfragen weiterhin blockiert.

Pipeline-Reihenfolge mit der Secrets-Transformation:

- **Empfohlen:** Platzieren Sie den Judge **vor** der Secrets-Transformation. Der LLM-Anbieter sieht Proxy-Tokens, niemals die echten Anmeldeinformationen, auf die die Workload Zugriff hat.
- Alternativ kann der Judge nach den Secrets die exakte Wire-Form bewerten, die das System verlässt, allerdings werden dann echte Anmeldeinformationen an den LLM-Anbieter gesendet. Wählen Sie dies nur, wenn Ihr Bedrohungsmodell diesen Kompromiss akzeptiert.

Unterstützte Anbieter:

- **`anthropic`** (Messages-API). Verwendet `api_key_env`, `model`, optional `base_url` und `max_tokens`.
- **`openai`** (Chat-Completions-API). Gleiche Felder wie oben; setzen Sie `type: openai`, zeigen Sie mit `api_key_env` auf die Umgebungsvariable, die Ihren OpenAI-Schlüssel enthält, und wählen Sie ein Modell wie `gpt-5.4-nano`.

Audit-Ausgabe: Jede passende Anfrage fügt strukturierte Felder unter der Transform-Trace hinzu, einschließlich `judge.instance`, `judge.decision`, `judge.reason`, `judge.duration_ms`, `judge.input_tokens`, `judge.output_tokens`, `judge.fallback_applied` (wenn ein Fallback ausgelöst wird) und `judge.circuit_breaker_tripped` (wenn der Circuit Breaker offen ist).

Danksagung: Dank an Brex für ihr CrabTrap-Projekt (MIT-lizenziert), das dieses Design inspiriert hat.

## MCP-Richtlinie

iron-proxy unterstützt den [Streamable-HTTP-Transport von MCP](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports). Wenn eine Anfrage zu einem konfigurierten MCP-Server passt, parst der Proxy den JSON-RPC-Body, wendet eine Standard-Deny-Tool-Allowlist an und filtert `tools/list`-Antworten, sodass abgelehnte Tools den Agenten nie erreichen. SSE-Antworten werden pro Ereignis gefiltert, sodass langlebige MCP-Streams aktiv bleiben.

Dies ist eine vollwertige Proxy-Fähigkeit und keine Transformation: MCP-Antworten können offene SSE-Streams sein, die beliebige serverinitiierte Nachrichten übertragen, was nicht in den Request/Response-Transform-Vertrag passt.```yaml
mcp:
  # JSON-RPC error envelope returned to the agent on policy denial.
  # Defaults: code -32001, message "blocked by iron-proxy policy".
  error:
    code: -32001
    message: "blocked by iron-proxy policy"
  servers:
    - name: github                         # appears in audit as mcp.server
      rules:                               # standard host/method/path rules
        - host: "mcp.github.com"
          paths: ["/mcp", "/mcp/*"]
      tools:
        - name: "search_repositories"      # always allowed
        - name: "create_issue"
          when:                            # all clauses must hold; otherwise deny
            - path: "owner"                # dotted path against arguments
              equals: "ironsh"
            - path: "repo"
              in: ["iron-proxy", "tunis-v2"]
        # Anything not listed is denied (default-deny).

Credentials verwenden dieselben Secret-Quellen wie die `secrets`-Transformation. Sie sind standardmäßig erforderlich. Setzen Sie bei einem Credential `require: false`, um es zu überspringen, wenn es nicht verfügbar ist. Audit-Logs zeichnen die Route, die Upstream-URL und die Orte der Credential-Injektion auf, niemals jedoch die injizierten Credential-Werte.

Einschränkungen in v1:

- Nur der Streamable-HTTP-Transport wird unterstützt. Der ältere HTTP+SSE-Transport (getrennte `/messages`- und `/sse`-Endpunkte) wird nicht unterstützt.
- Ein JSON-RPC-Batch mit einem verweigerten Eintrag wird als gesamter Batch abgelehnt; das Weiterleiten von Teil-Batches wird nicht unterstützt.
- Ressourcen und Prompts werden nicht erzwungen. Agents können weiterhin `resources/list`, `resources/read` usw. ohne Policy-Filter aufrufen.

### Body-Limits

Transformationen, die Anforderungs-/Antwort-Bodys untersuchen oder weiterleiten (Secrets-Body-Matching,
gRPC-Transformationen), arbeiten mit gepufferten Bodys. Zwei globale Einstellungen steuern
die maximalen Puffergrößen:

- **`max_request_body_bytes`** (Standard: `1048576` / 1 MiB): begrenzt, wie viel vom
  Anforderungsbody für Transformationen gepuffert wird. Daten über dieses Limit hinaus werden
  aus Sicht der Transformation abgeschnitten, aber weiterhin an Upstream weitergeleitet.
- **`max_response_body_bytes`** (Standard: `0` / unbegrenzt): begrenzt, wie viel vom
  Antwortbody gepuffert wird. Setzen Sie den Wert auf `0`, um den vollständigen Body zu puffern –
  die richtige Standardeinstellung für die meisten Arbeitslasten (z. B. npm-Pakete, Modellgewichte).

Bodys werden inkrementell gepuffert, während Transformationen sie lesen, und zwischen
Pipeline-Stufen automatisch zurückgespult. Wenn eine Transformation den Body nicht liest, findet
keine Pufferung statt und der Body wird unverändert durchgestreamt.

### Tunnel-Listener (HTTP/CONNECT/SOCKS5)

Der Tunnel-Listener akzeptiert HTTP-Proxy-Anfragen in absoluter Form, HTTP-CONNECT-
und SOCKS5-Verbindungen auf einem dedizierten Port. Dies ist nützlich für Tools, die
Proxy-Konfiguration nativ über die Umgebungsvariablen `HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY`
oder SOCKS5-Einstellungen unterstützen, anstatt auf DNS-basiertes Routing
angewiesen zu sein.

Um ihn zu aktivieren, setzen Sie `tunnel_listen` unter `proxy`:```yaml
proxy:
  tunnel_listen: ":8080"

**Einfaches HTTP-Proxy-Beispiel:**```bash
curl -x http://172.20.0.2:8080 \
  http://httpbin.org/get

Sie können auch die Standard-Umgebungsvariablen setzen, sodass alle Tools
automatisch durch den Tunnel geleitet werden:```bash
export HTTP_PROXY=http://172.20.0.2:8080
export HTTPS_PROXY=http://172.20.0.2:8080
export ALL_PROXY=socks5h://172.20.0.2:8080

Einfach einzurichten, aber leicht zu umgehen: Die Workload kann IPs hartkodieren oder ihren
eigenen DNS-Resolver verwenden, um den Proxy vollständig zu umgehen.

### DNS + nftables-Egress-Firewall (erzwungen)

Legen Sie eine nftables-Firewall über das DNS-Routing. DNS lenkt den Datenverkehr weiterhin zum
Proxy, aber nftables stellt sicher, dass die Workload _nicht_ mit irgendetwas anderem kommunizieren kann,
selbst mit hartkodierten IPs.

Das Verzeichnis [`examples/nftables`](https://github.com/paradigmxyz/iron-proxy/blob/HEAD/examples/nftables/) enthält ein funktionierendes Setup.
Der Client-Container lädt die Firewall-Regeln beim Start, bevor er
Anwendungsdatenverkehr ausführt:

**nftables.conf** erlaubt Datenverkehr zum Proxy und verwirft alles andere:```
table ip iron {
  chain output {
    type filter hook output priority 0; policy drop;

    # allow loopback
    oif lo accept

    # allow traffic to the proxy itself (DNS + HTTP/HTTPS)
    ip daddr 172.20.0.2 tcp dport { 80, 443 } accept
    ip daddr 172.20.0.2 udp dport 53 accept

    # allow established/related (return traffic)
    ct state established,related accept

    # log and drop everything else
    log prefix "iron-proxy-drop: " drop
  }
}

In einer Produktionsumgebung würden Sie die Regeln in einem Entrypoint-Wrapper laden und dann
`exec` Ihren eigentlichen Prozess als Nicht-Root-Benutzer ohne `CAP_NET_ADMIN` ausführen.

### TPROXY (transparenter Proxy)

Für Umgebungen, in denen Sie die DNS des Workloads überhaupt nicht kontrollieren können, kann nftables
TPROXY den Datenverkehr auf Kernel-Ebene umleiten, ohne dass der Workload
irgendwie mitwirken muss. Dies fängt Pakete in der PREROUTING-Kette ab und reicht sie
direkt an iron-proxy weiter:```
table ip iron {
  chain prerouting {
    type filter hook prerouting priority mangle; policy accept;

    # redirect HTTP/HTTPS to iron-proxy via TPROXY
    tcp dport 80 tproxy to 172.20.0.2:80 meta mark set 1 accept
    tcp dport 443 tproxy to 172.20.0.2:443 meta mark set 1 accept
  }

  chain output {
    type route hook output priority mangle; policy accept;

    # mark locally-originated packets for policy routing
    tcp dport { 80, 443 } meta mark set 1
  }
}

**proxy.yaml** erlaubt `httpbin.org` und `icanhazip.com`, tauscht zwei Secrets aus:```yaml
transforms:
  - name: allowlist
    config:
      domains:
        - "httpbin.org"
        - "icanhazip.com"
      cidrs:
        - "172.20.0.0/24"

  - name: secrets
    config:
      secrets:
        - source:
            type: env
            var: OPENAI_API_KEY
          replace:
            proxy_value: "proxy-openai-abc123"
            match_headers: ["Authorization"]
            match_query: true # scan the query string
          rules:
            - host: "httpbin.org"

        - source:
            type: env
            var: INTERNAL_TOKEN
          proxy_value: "proxy-internal-tok"
          match_headers: [] # scan all headers
          rules:
            - host: "httpbin.org"

## Audit-Log-Format

Jede weitergeleitete Anfrage erzeugt einen strukturierten JSON-Protokolleintrag:```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"] }]
      }
    }
  ],
  "response_transforms": []
}

All configuration uses standard OTEL environment variables:

| Variable                       | Beschreibung                                             | Standard         |
| ------------------------------ | ------------------------------------------------------- | ---------------- |
| `OTEL_EXPORTER_OTLP_ENDPOINT` | OTLP-Collector-URL. Export deaktiviert ohne Wert.       | (deaktiviert)    |
| `OTEL_EXPORTER_OTLP_PROTOCOL` | `http/protobuf` oder `grpc`.                              | `http/protobuf`  |
| `OTEL_EXPORTER_OTLP_HEADERS`  | Kommagetrennte `key=value`-Paare für Auth-Header.       | (keine)          |
| `OTEL_SERVICE_NAME`            | Dienstname für alle Protokolldatensätze.                  | `iron-proxy`     |
| `OTEL_RESOURCE_ATTRIBUTES`    | Kommagetrennte `key=value`-Ressourcenattribute.          | (keine)          |

Wenn aktiviert, wird jedes Audit-Ereignis als OTEL-Protokolldatensatz zusammen mit den vorhandenen JSON-Stderr-Protokollen ausgegeben. Der Protokolldatensatz verwendet dasselbe Schema wie der JSON-Audit-Eintrag: `host`, `method`, `path`, `action`, `status_code`, `duration_ms` sowie die vollständigen `request_transforms`/`response_transforms`-Arrays mit Anmerkungen.

## Verwaltungs-API

iron-proxy kann optional eine authentifizierte HTTP-API für betriebliche Aufgaben bereitstellen. Derzeit stellt sie einen einzigen Endpunkt bereit, `POST /v1/reload`, der die YAML-Konfiguration von der Festplatte neu einliest und atomar eine frisch erstellte Transform-Pipeline austauscht. Die laufende Pipeline bleibt erhalten, falls die neue Konfiguration ungültig ist.

Der Verwaltungsserver ist standardmäßig deaktiviert. Um ihn zu aktivieren, fügen Sie Ihrer Konfiguration einen `management`-Block hinzu:```yaml
management:
  # Bind on loopback unless you front this with a private network or auth proxy:
  # /v1/reload can rebuild the entire transform pipeline.
  listen: "127.0.0.1:9092"
  # Env var that holds the bearer token. Defaults to IRON_MANAGEMENT_API_KEY.
  api_key_env: "IRON_MANAGEMENT_API_KEY"

## iron.sh

Benötigen Sie Vault/KMS-Secret-Backends, einen Kubernetes-Operator oder zentrales Policy-Management? [iron.sh](https://iron.sh) baut auf iron-proxy auf und bietet Enterprise-Funktionen für Teams, die dies in großem Umfang betreiben.

## Release-Signaturen verifizieren

Release-Artefakte enthalten ein signiertes Prüfsummen-Manifest:

- `checksums.txt`
- `checksums.txt.asc` (ASCII-armored abgetrennte Signatur)

Verwenden Sie den enthaltenen öffentlichen Schlüssel unter [`public-key.asc`](https://github.com/paradigmxyz/iron-proxy/blob/HEAD/public-key.asc) zur Verifizierung:```bash
# 1) Download release artifacts for a tag
TAG=vX.Y.Z
gh release download "$TAG" --pattern "checksums.txt" --pattern "checksums.txt.asc"

# 2) Import the project signing key
gpg --import public-key.asc

# 3) Verify the signature over checksums.txt
gpg --verify checksums.txt.asc checksums.txt