iron-proxy

समस्या

CI जॉब्स, AI कोडिंग एजेंट और सैंडबॉक्स्ड कंटेनर मनमाने ढंग से आउटबाउंड अनुरोध कर सकते हैं। एक समझौता किया गया डिपेंडेंसी, एक प्रॉम्प्ट इंजेक्शन, या एक दुर्भावनापूर्ण बिल्ड स्टेप सीक्रेट्स को बाहर निकाल सकता है, घर से संपर्क कर सकता है, या रिवर्स शेल खोल सकता है। अधिकांश टीमों के पास इस बात की कोई दृश्यता नहीं होती कि उनके वर्कलोड से क्या बाहर जा रहा है, रोकने का तो सवाल ही नहीं उठता।

iron-proxy क्या करता है

iron-proxy एक MITM एग्रेस प्रॉक्सी है जिसमें अंतर्निहित DNS सर्वर होता है, जो आपके अविश्वसनीय वर्कलोड और इंटरनेट के बीच बैठता है। यह नेटवर्क सीमा पर default-deny लागू करता है, इसलिए वर्कलोड केवल उन्हीं डोमेन तक पहुँच सकता है जिन्हें आप स्पष्ट रूप से अनुमति देते हैं। असली सीक्रेट सैंडबॉक्स में कभी प्रवेश नहीं करते। वर्कलोड प्रॉक्सी टोकन का उपयोग करते हैं, और iron-proxy एग्रेस पर वास्तविक क्रेडेंशियल्स के साथ स्वैप करता है, जिसका अर्थ है कि एक समझौता किया गया वर्कलोड एक ऐसा टोकन exfiltrate कर सकता है जो प्रॉक्सी के बाहर बेकार है।

एक ही बाइनरी। एक ही YAML कॉन्फ़िग।

Default-deny एग्रेस। हर आउटबाउंड अनुरोध तब तक ब्लॉक किया जाता है जब तक कि गंतव्य आपकी allowlist से मेल न खाए। अपने डोमेन और CIDR सूचीबद्ध करें, बाकी सबको 403 मिलता है।
अपस्ट्रीम IP डेनी सूची। भले ही कोई होस्ट अनुमत हो, प्रॉक्सी उसे डायल करने से मना कर देता है यदि उसका रिज़ॉल्व्ड पता एक निषिद्ध CIDR के अंदर आता है — जिससे SSRF/DNS-rebinding का अंतर बंद हो जाता है जहाँ एक अनुमत होस्टनाम IMDS या loopback की ओर इशारा करता है। क्लाउड मेटाडेटा एंडपॉइंट्स (169.254.169.254, fd00:ec2::254, और fd20:ce::254) और loopback डिफ़ॉल्ट रूप से अस्वीकृत हैं; proxy.upstream_deny_cidrs या IRON_PROXY_UPSTREAM_DENY_CIDRS के माध्यम से ओवरराइड करें।
सीमा-स्तरीय सीक्रेट इंजेक्शन। वर्कलोड प्रॉक्सी टोकन भेजते हैं; iron-proxy अनुरोध के बाहर निकलने से पहले उन्हें वास्तविक सीक्रेट्स से बदल देता है। यदि सैंडबॉक्स से समझौता किया जाता है, तो हमलावर को ऐसे टोकन मिलते हैं जो प्रॉक्सी के बाहर बेकार हैं।
प्रति-अनुरोध ऑडिट ट्रेल। प्रत्येक अनुरोध को संरचित JSON के रूप में पूरे ट्रांसफ़ॉर्म पाइपलाइन परिणाम के साथ लॉग किया जाता है: कौन से सीक्रेट स्वैप किए गए, कौन से नियम मेल खाए, क्या ब्लॉक हुआ और क्यों।
स्ट्रीमिंग-जागरूक। WebSocket अपग्रेड और Server-Sent Events मूल रूप से प्रॉक्सी किए जाते हैं। लंबे समय तक चलने वाले कनेक्शन रखने वाले एजेंट वर्कलोड के लिए कोई विशेष कॉन्फ़िगरेशन आवश्यक नहीं है।
एक्सप्लिसिट प्रॉक्सी समर्थन। उन टूल्स के लिए वैकल्पिक टनल लिसनर जो मूल रूप से HTTP_PROXY, HTTPS_PROXY, या SOCKS5 सेटिंग्स के माध्यम से प्रॉक्सी कॉन्फ़िगरेशन का समर्थन करते हैं।
PostgreSQL MITM प्रॉक्सी। वैकल्पिक लिसनर जो प्रॉक्सी-प्रबंधित क्रेडेंशियल्स के विरुद्ध क्लाइंट्स को प्रमाणित करता है, अपस्ट्रीम सत्र पर SET ROLE इंजेक्ट करता है, और SQL AST वॉक के माध्यम से भूमिका को बदलने के क्लाइंट प्रयासों (SET ROLE, set_config('role', ...), DO ब्लॉक्स, आदि) को अस्वीकार करता है। PostgreSQL row-level security के साथ मिलकर, जब एप्लिकेशन साझा सेवा-खाता उपयोगकर्ता के रूप में कनेक्ट होता है, तो प्रति-टेनेंट डेटा अलगाव देता है। यदि (उपयोग किया जाता है) PgBouncer को pool_mode = session में चलाना आवश्यक है — ट्रांज़ैक्शन या स्टेटमेंट पूल मोड चुपचाप क्वेरीज़ के बीच बैकएंड्स को रीबाइंड कर देते हैं और नीति को विफल कर देंगे। विवरण के लिए docs.iron.sh देखें।

CI पाइपलाइनों, GitHub Actions, AI एजेंटों (Claude Code, Cursor, Codex), और किसी भी ऐसे वातावरण के लिए निर्मित, जहाँ आप ऐसा कोड चलाते हैं जिस पर आप पूरी तरह भरोसा नहीं करते।

ब्लॉक की गई exfiltration + सीक्रेट रीराइटिंग क्रिया में:

इंस्टॉलेशन

Docker इमेज Docker Hub पर उपलब्ध हैं और Linux/macOS (amd64/arm64) के लिए पहले से निर्मित बाइनरी GitHub Releases पर हैं।

या स्रोत से निर्माण करें:```bash go build -o iron-proxy ./cmd/iron-proxy

## त्वरित आरंभ```bash
cd examples/docker-compose
docker compose up

यह iron-proxy और एक डेमो क्लाइंट प्रारंभ करता है जो प्रॉक्सी के माध्यम से पाँच अनुरोध भेजता है। अनुमत, अवरुद्ध और गुप्त-पुनर्लिखित अनुरोधों को देखने के लिए लॉग जाँचें:```bash docker compose logs proxy

हर अनुरोध एक संरचित JSON ऑडिट प्रविष्टि उत्पन्न करता है:```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"] }] }
    }
  ]
}

अस्वीकृत अनुरोधों में rejected_by फ़ील्ड शामिल होता है और ये WARN स्तर पर लॉग होते हैं। देखें ऑडिट लॉग प्रारूप पूर्ण स्कीमा के लिए।

उत्पादन उपयोग

1. CA जनरेट करें

iron-proxy लीफ प्रमाणपत्रों को तुरंत उत्पन्न करके TLS समाप्त करता है, जिन पर आपके द्वारा प्रदान किए गए CA द्वारा हस्ताक्षर किए जाते हैं। क्लाइंट कंटेनरों को इस 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. एक Docker नेटवर्क बनाएं

iron-proxy को एक निश्चित IP की आवश्यकता होती है ताकि कंटेनर अपनी DNS को उस पर इंगित कर सकें:```bash
docker network create --subnet=172.20.0.0/24 iron-proxy

3. iron-proxy प्रारंभ करें

अपने सीक्रेट्स के साथ एक env फ़ाइल बनाएं (इसे वर्शन कंट्रोल से बाहर रखें):```bash echo "OPENAI_API_KEY=sk-real-key" > .env

I apologize, but I don't see any source text to translate in your input. The message ends with "INPUT:" followed by nothing.

Please provide the actual chunk 15 content so I can translate it into Hindi.```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. कंटेनरों को प्रॉक्सी के माध्यम से रूट करें

सबसे सरल तरीका DNS-आधारित रूटिंग है: कंटेनर के DNS को iron-proxy की ओर इंगित करें और सभी होस्टनेम लुकअप प्रॉक्सी IP पर हल हो जाएंगे, जिससे ट्रैफ़िक स्वचालित रूप से इसके माध्यम से रूट हो जाएगा:```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

For stronger enforcement, layer nftables rules to block non-proxy egress, or use
TPROXY for kernel-level interception. See [Routing traffic to the
proxy](#routing-traffic-to-the-proxy) for details on each approach.

## iron-proxy क्यों?

|                          | iron-proxy                     | Squid                       | mitmproxy                 | Envoy                              |
| ------------------------ | ------------------------------ | --------------------------- | ------------------------- | ---------------------------------- |
| Default-deny egress      | अंतर्निहित                     | जटिल ACL कॉन्फ़िगरेशन आवश्यक | कस्टम स्क्रिप्टिंग आवश्यक | RBAC/फ़िल्टर कॉन्फ़िगरेशन आवश्यक |
| Secret injection         | अंतर्निहित                     | नहीं                        | नहीं                      | नहीं                               |
| Structured audit logging | अंतर्निहित, प्रति-ट्रांसफ़ॉर्म ट्रेस | बेसिक एक्सेस लॉग           | प्लगइन-आधारित            | कॉन्फ़िगर करने योग्य एक्सेस लॉग   |
| Setup complexity         | एकल बाइनरी + YAML              | व्यापक कॉन्फ़िगरेशन भाषा   | Python स्क्रिप्टिंग       | जटिल YAML या कंट्रोल प्लेन        |

iron-proxy एक ही कार्य के लिए विशेष रूप से निर्मित है: अविश्वसनीय वर्कलोड से
ईग्रेस को नियंत्रित और ऑडिट करना। Squid डिफ़ॉल्ट-अस्वीकार कर सकता है, लेकिन इसके लिए
महत्वपूर्ण ACL कॉन्फ़िगरेशन की आवश्यकता होती है और इसमें सीक्रेट इंजेक्शन की कोई अवधारणा नहीं है।
mitmproxy एक बेहतरीन डीबगिंग टूल है, लेकिन इसे प्रोडक्शन प्रवर्तन के लिए डिज़ाइन नहीं किया गया है।
Envoy एक सामान्य-उद्देश्यीय प्रॉक्सी है जिसे इसका कुछ हिस्सा करने के लिए कॉन्फ़िगर किया जा सकता है,
लेकिन यह समस्या की आवश्यकता से कहीं अधिक जटिल है।

## यह कैसे काम करता है

iron-proxy एक DNS सर्वर और एक HTTP/HTTPS प्रॉक्सी चलाता है। अपने कंटेनर का DNS
iron-proxy पर इंगित करें और सभी होस्टनाम लुकअप प्रॉक्सी IP पर रिज़ॉल्व हो जाएंगे, जिससे ट्रैफ़िक
स्वचालित रूप से इसके माध्यम से रूट होगा। प्रॉक्सी TLS को समाप्त करता है (आपके द्वारा प्रदान किए गए
CA से लीफ सर्टिफिकेट तुरंत उत्पन्न करता है), अनुरोध को एक क्रमबद्ध ट्रांसफ़ॉर्म पाइपलाइन के माध्यम से
चलाता है, इसे अपस्ट्रीम को अग्रेषित करता है, और प्रतिक्रिया को वापस पाइपलाइन के माध्यम से चलाता है।```
Container → DNS lookup → iron-proxy IP → TLS termination → transforms → upstream

Transforms run in order. Built-in transforms:

Transform	What it does
`allowlist`	मिलान करने वाले domains/CIDRs के अनुरोधों की अनुमति देता है; बाकी सब कुछ अस्वीकार करता है (403)।
`secrets`

कॉन्फ़िगरेशन

iron-proxy एक single flag लेता है: -config path/to/config.yaml. पूरा स्वरूप यहाँ है (कॉपी-पेस्ट करने योग्य प्रारंभिक बिंदु के लिए iron-proxy.example.yaml देखें):```yaml dns: listen: ":53" proxy_ip: "10.16.0.1" # IP where iron-proxy is running (required) passthrough: # Domains forwarded to OS resolver - "*.internal.corp" - "metadata.google.internal" records: # Static DNS records (highest precedence) - name: "internal.example.com" type: A value: "10.0.0.5"

proxy: http_listen: ":80" https_listen: ":443" tunnel_listen: ":8080" # Optional CONNECT/SOCKS5 listener max_request_body_bytes: 1048576 # 1 MiB (default) max_response_body_bytes: 0 # uncapped (default)

tls: ca_cert: "/etc/iron-proxy/ca.crt" # Required ca_key: "/etc/iron-proxy/ca.key" # Required cert_cache_size: 1000 # LRU cache for generated leaf certs leaf_cert_expiry_hours: 72

transforms:

name: allowlist config: domains: - "api.openai.com" - "*.anthropic.com" cidrs: - "10.0.0.0/8"
name: secrets config: secrets: - source: type: env var: OPENAI_API_KEY # Env var holding the real secret proxy_value: "proxy-token-123" # Token the sandbox sends match_headers: ["Authorization"] match_body: false require: true # Reject requests without the proxy token rules: - host: "api.openai.com"

log: level: "info" # debug, info, warn, error

### DNS

डिफ़ॉल्ट रूप से सब कुछ `proxy_ip` पर रिज़ॉल्व होता है, जो ट्रैफ़िक को
प्रॉक्सी के माध्यम से रूट करता है। अपवाद:

- **`passthrough`:** OS रिज़ॉल्वर को अग्रेषित किए गए glob पैटर्न (जैसे,
  `*.internal.corp`)। इन होस्ट्स का ट्रैफ़िक प्रॉक्सी को पूरी तरह से बायपास करता है।
- **`records`:** स्थिर A या CNAME रिकॉर्ड। सर्वोच्च प्राथमिकता।

### रिस्पॉन्स रीट्राय हैंडलर

बाह्य रूप से अधिकृत रिस्पॉन्स रीट्राय सक्षम करने के लिए `IRON_RESPONSE_RETRY_HANDLER_URL`,
`IRON_RESPONSE_RETRY_COMPLETE_URL`, `IRON_RESPONSE_RETRY_HANDLER_TOKEN`,
`IRON_RESPONSE_RETRY_HANDLER_SANDBOX_ID` और अल्पविराम से अलग की गई
`IRON_RESPONSE_RETRY_STATUSES` सूची सेट करें। प्राधिकरण हैंडलर को सटीक अपस्ट्रीम स्कीम, प्राधिकार, विधि,
पथ/क्वेरी, रीप्ले योग्यता, रिस्पॉन्स स्थिति और हेडर, ट्रेस संदर्भ और
सैंडबॉक्स पहचान प्राप्त होती है। यह एक सटीक रीप्ले के लिए अनुरोध हेडर
और एक प्रयास आईडी लौटा सकता है। फिर पूर्णता हैंडलर को रीप्ले स्थिति और
`IRON_RESPONSE_RETRY_COMPLETION_HEADERS` द्वारा चयनित रिस्पॉन्स हेडर प्राप्त होते हैं, जो
डिफ़ॉल्ट रूप से `Payment-Receipt` है।

रिस्पॉन्स बॉडी कभी भी किसी हैंडलर को नहीं भेजी जाती, गंतव्य बदले नहीं जा सकते,
और कनेक्शन/फ्रेमिंग हेडर अस्वीकार कर दिए जाते हैं। `proxy.max_request_body_bytes` से अधिक के अनुरोध
सामान्य रूप से आगे बढ़ते हैं, लेकिन उन्हें गैर-रीप्ले योग्य चिह्नित किया जाता है;
यदि चुनौती दी जाती है, तो उनका मूल रिस्पॉन्स लौटाया जाता है। हैंडलर विफलताएँ भी
मूल रिस्पॉन्स को संरक्षित करती हैं। हैंडलर URL को HTTPS का उपयोग करना चाहिए, जब तक कि लूपबैक या
`IRON_RESPONSE_RETRY_HANDLER_ALLOW_HTTP=true` किसी विश्वसनीय आंतरिक नेटवर्क के लिए स्पष्ट रूप से कॉन्फ़िगर न किया गया हो।
रीडायरेक्ट अस्वीकार कर दिए जाते हैं, और रिस्पॉन्स रीट्राय टोकन को
कंट्रोल-प्लेन टोकन से स्वतंत्र रूप से कॉन्फ़िगर किया जाना चाहिए। WebSocket,
gRPC और अज्ञात-लंबाई वाले स्ट्रीमिंग अनुरोध रिस्पॉन्स रीट्राय हैंडलिंग को बायपास करते हैं।

जब कोई विश्वसनीय हैंडलर `proxy.upstream_deny_cidrs` के अंदर रिज़ॉल्व होता है, तो `IRON_RESPONSE_RETRY_HANDLER_ALLOW_CIDRS` को
उन संकीर्ण निजी CIDR की अल्पविराम से अलग की गई सूची पर सेट करें,
जिनका वह उपयोग कर सकता है। यह अपवाद केवल सटीक रूप से कॉन्फ़िगर किए गए
authorize और complete एंडपॉइंट्स पर लागू होता है; सामान्य प्रॉक्सी ट्रैफ़िक
पूर्ण अपस्ट्रीम अस्वीकृति सूची के अधीन रहता है। सार्वजनिक, लूपबैक, लिंक-लोकल और क्लाउड
मेटाडेटा रेंज को इस सेटिंग के माध्यम से नहीं जोड़ा जा सकता।

### अनुमति सूची

डिफ़ॉल्ट-अस्वीकृति। आगे बढ़ने के लिए अनुरोधों को कम से कम एक डोमेन glob या CIDR से मेल खाना चाहिए।
बेमेल अनुरोधों को `403 Forbidden` मिलता है।

डोमेन पैटर्न glob मिलान का उपयोग करते हैं: `*.example.com` किसी भी सबडोमेन और
स्वयं `example.com` से मेल खाता है।

**चेतावनी मोड:** यह देखने के लिए कि अनुमति सूची वास्तव में लागू किए बिना क्या ब्लॉक करेगी,
`warn: true` सेट करें। जिन अनुरोधों को अस्वीकार किया जाना होता, उन्हें अनुमति दी जाती है, लेकिन
ट्रांसफ़ॉर्म ट्रेस में `"action": "warn"` के साथ एनोटेट किया जाता है। यह नए अनुमति सूची नियमों को
रोल आउट करने या प्रवर्तन पर स्विच करने से पहले मौजूदा ट्रैफ़िक का ऑडिट करने के लिए
उपयोगी है।

### एनोटेट

होस्ट/विधि/पथ नियमों के आधार पर HTTP अनुरोध हेडर को ऑडिट लॉग एनोटेशन में कैप्चर करता है।
यह प्रॉक्सी कोर को संशोधित किए बिना ऑडिट लॉग को अनुरोध आईडी जैसे
अनुरोध-विशिष्ट संदर्भ से समृद्ध करने के लिए उपयोगी है।

प्रत्येक एनोटेशन समूह मिलान के लिए नियम और कैप्चर के लिए हेडर निर्दिष्ट करता है।
जब कोई अनुरोध किसी समूह के किसी भी नियम से मेल खाता है, तो निर्दिष्ट हेडर मान
ट्रांसफ़ॉर्म ट्रेस एनोटेशन में `header:<Name>` प्रविष्टियों के रूप में लिखे जाते हैं।
जो अनुरोध मेल नहीं खाते, वे अपरिवर्तित पास हो जाते हैं। यह ट्रांसफ़ॉर्म कभी भी अनुरोधों को अस्वीकार नहीं करता।

> **चेतावनी:** हेडर मान ऑडिट लॉग में सादे पाठ में जारी किए जाते हैं। केवल
> ऐसे हेडर लॉग करें जिन्हें उजागर करना सुरक्षित हो, जैसे अनुरोध आईडी या प्रॉक्सी के गुप्त टोकन
> वाले हेडर। ऐसे हेडर लॉग न करें जिनमें कच्चे रहस्य हों।```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"]

हैडर अनुमतिसूची (Header allowlist)

डिफ़ॉल्ट-अस्वीकार अनुरोध हैडर फ़िल्टर। कोई भी अनुरोध हैडर जिसका कैनोनिकल नाम कॉन्फ़िगर किए गए headers सूची में नहीं है, अनुरोध के अपस्ट्रीम जाने से पहले हटा दिया जाता है। ट्रैकिंग, फ़िंगरप्रिंटिंग, या आकस्मिक लीकेज हैडर (कुकीज़, आंतरिक सहसंबंध आईडी, X-Forwarded-*, आदि) को ब्लॉक करने के लिए उपयोगी है जिन्हें सैंडबॉक्स संलग्न कर सकता है।

प्रविष्टियों का मिलान कैनोनिकल हैडर नाम के विरुद्ध केस-असंवेदनशील रूप से किया जाता है। /.../ द्वारा सीमांकित पैटर्न (जैसे /^X-Trace-.*$/) केस-असंवेदनशील रेगुलर एक्सप्रेशन हैं, जो secrets ट्रांसफ़ॉर्म के match_headers सिंटैक्स को प्रतिबिंबित करते हैं।

वैकल्पिक rules अनुमतिसूची को विशिष्ट होस्ट/विधियों/पथों तक सीमित करते हैं। जब छोड़ दिया जाता है, तो अनुमतिसूची हर उस अनुरोध पर लागू होती है जो इस ट्रांसफ़ॉर्म तक पहुँचता है।

जब कम से कम एक हैडर हटा दिया जाता है, तो ट्रेस को stripped_headers के साथ एनोटेट किया जाता है जिसमें हटाए गए नामों की सूची होती है।

स्थान: header_allowlist को बाद में secrets के रखें (ताकि इंजेक्ट किए गए क्रेडेंशियल हटाए न जाएँ यदि वे अनुमतिसूची में नहीं हैं, आप उन्हें सूचीबद्ध कर सकते हैं) और बाद में annotate के (ताकि एनोटेशन मूल हैडर पढ़े)।```yaml transforms:

name: header_allowlist config: headers: - "Authorization" - "Content-Type" - "User-Agent" - "Accept" - "/^X-Trace-.*$/" rules: - host: "api.openai.com"

### बॉडी कैप्चर

मेल खाने वाले अनुरोधों के डिकोड किए गए अनुरोध बॉडी को रिकॉर्ड करता है और इसे ऑडिट लॉग रिकॉर्ड पर `body_capture` समूह में प्रस्तुत करता है, जिसमें `request_body` और `request_body_truncated` होते हैं। यह प्रॉक्सी से गुजरने वाले पेलोड्स की ऑडिटिंग के लिए उपयोगी है, जैसे कि सैंडबॉक्स किसी LLM प्रदाता को भेजे जाने वाले प्रॉम्प्ट, बिना अपस्ट्रीम ट्रैफ़िक को संशोधित किए।

होस्ट, विधियों और पथों का मिलान उसी `rules` सिंटैक्स से किया जाता है जिसका उपयोग `allowlist` और `secrets` के लिए होता है। `max_request_body_bytes` यह सीमा तय करता है कि प्रत्येक बॉडी का कितना हिस्सा कैप्चर किया जाता है; सीमा से बड़े बॉडी को उपसर्ग तक छोटा कर दिया जाता है और `request_body_truncated` को `true` पर सेट किया जाता है। यह सीमा डिफ़ॉल्ट रूप से 16 KiB है और वैश्विक `proxy.max_request_body_bytes` सीमा से स्वतंत्र है। यह ट्रांसफ़ॉर्म केवल अवलोकन के लिए है: यह किसी अनुरोध को कभी अस्वीकार नहीं करता, और बॉडी पढ़ने में त्रुटियाँ अनुरोध को विफल करने के बजाय ट्रेस पर एनोटेट की जाती हैं।

सफल कैप्चर पर, `request_transforms` में ट्रांसफ़ॉर्म की प्रविष्टि को `captured_bytes` और `truncated` के साथ एनोटेट किया जाता है ताकि ट्रेस यह रिकॉर्ड करे कि बॉडी कैप्चर हुई थी, बिना बॉडी की नकल किए।

प्रतिक्रिया बॉडी को कैप्चर नहीं किया जाता है। स्ट्रीमिंग प्रतिक्रियाओं (SSE) को आगे भेजने से पहले एंड-टू-एंड बफ़र किया जाना होगा, जिससे क्लाइंट ठहर जाएगा।

> **चेतावनी:** कैप्चर की गई बॉडी सादे पाठ में ऑडिट लॉग में लिखी जाती हैं। जब
> `secrets` `match_body: true` के साथ चलता है, तो `body_capture` को `secrets` से *पहले* रखें
> ताकि ऑडिट लॉग सैंडबॉक्स के प्रॉक्सी टोकन को रिकॉर्ड करे, न कि उन वास्तविक
> क्रेडेंशियल्स को जिन्हें `secrets` बॉडी में स्वैप करता है।```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"]

Secrets

The sandbox never holds real credentials. Instead:

Configure iron-proxy with the real secret source: environment variables, a file on disk, AWS Secrets Manager, AWS Systems Manager Parameter Store, 1Password (service account), or 1Password Connect.
Give the sandbox a proxy token (e.g., proxy-openai-abc123).
Configure the secrets transform to map proxy tokens to those sources.

iron-proxy scans outbound requests and replaces proxy tokens with the real values before forwarding upstream. You control where it looks:

match_headers: list of header names to scan. Empty list = all headers. Literal names are matched case-insensitively, but the casing you write is preserved when the header is forwarded upstream. Entries delimited by /.../ are compiled as case-insensitive regular expressions matched against canonical header names (e.g. /^x-.*-key$/).
match_body: scan the request body (buffered up to max_request_body_bytes).
match_query: scan the URL query string. Defaults to false; opt in for upstreams that expect the secret in a query parameter. Query strings often appear in access logs on either side of the proxy, so this is off by default.
match_path: scan the URL path. Defaults to false; opt in for upstreams like Telegram that embed the secret in the path (e.g. /bot<TOKEN>/sendMessage). URL paths often appear in access logs on either side of the proxy, so this is off by default.
require: when , requests to a matching host that do contain the proxy token are rejected with 403. This prevents a compromised workload from bypassing the secret-swap mechanism with alternative credentials. Default: .

Query parameters are always scanned.

Secret sources:

env: reads var from the proxy process environment. Fixed at process start — use file instead if you need to rotate the value on a running proxy.
file: reads the secret from path on disk. The file is re-read on every config reload (boot and each POST /v1/reload) and, when ttl is set, on cache expiry — so you can rotate a running proxy's secret by rewriting the file (atomically: write-temp + rename) and reloading, without a restart. The value is the exact file contents (no trimming), so the writer controls trailing whitespace. Optional ttl and failure_ttl are supported.
aws_sm: reads secret_id from AWS Secrets Manager. Optional region, ttl, and are supported.

Every source also accepts an optional json_key. When set, the resolved value is parsed as a JSON object and the single top-level string field at that key is extracted. Use it to pull one field out of a JSON secret.

ttl controls how long a successfully fetched value is cached before refresh (empty caches forever). failure_ttl controls how long a fetch error is cached before retrying; it defaults to 1m and is independent of ttl, so a long success TTL does not delay recovery from a transient backend outage.

Note: a bug in onepassword-sdk-go breaks builds with CGO_ENABLED=0, so iron-proxy pins a fork via a replace directive in go.mod until the fix lands upstream.

Judge

The judge transform calls an LLM to produce an allow/deny decision for requests that match its URL rules. Each entry under transforms: is an independent judge instance with its own natural-language policy, LLM backend, timeout, semaphore, and circuit breaker. Operators can deploy zero, one, or many judges with different prompts scoped to different rules.```yaml

name: judge config: name: "github-write-guard" # required; identifies the instance in audit logs fallback: "deny" # deny (default) | skip. No "allow" fallback ships in v1. timeout: "8s" # per-call LLM timeout max_concurrent: 100 # semaphore capacity; additional calls wait circuit_breaker: consecutive_failures: 5 cooldown: "10s" rules: # uses the same matcher as allowlist/secrets - host: "api.github.com" methods: ["POST", "PATCH", "DELETE", "PUT"] provider: type: "anthropic" # "anthropic" or "openai" model: "claude-haiku-4-5-20251001" api_key_env: "ANTHROPIC_API_KEY" max_tokens: 256 prompt: | Natural-language policy describing what is allowed for requests that match the rules above. Kept short and specific.

अपरिवर्तन:

- जज केवल अस्वीकार कर सकता है। यह किसी ऐसे अनुरोध को कभी स्वीकृत नहीं करता जिसे
  स्थैतिक अनुमतिसूची अस्वीकार कर देती। स्थैतिक अस्वीकृति हमेशा जीतती है।
- गैर-मेल खाने वाले अनुरोधों को अनदेखा किया जाता है: कोई LLM कॉल नहीं, कोई ऑडिट एनोटेशन नहीं।
- LLM त्रुटि, टाइमआउट, सर्किट-ब्रेकर खुला होने, या गलत मॉडल आउटपुट की स्थिति में,
  कॉन्फ़िगर किया गया `fallback` लागू होता है। `deny` अनुरोध को रोकता है (उत्पादन के लिए
  अनुशंसित डिफ़ॉल्ट)। `skip` निर्णय को पाइपलाइन के बाकी हिस्से पर छोड़ देता है; चूँकि
  iron-proxy डिफ़ॉल्ट-अस्वीकृति है, गैर-मेल खाने वाले अनुरोध अभी भी रोके जाते हैं।

सीक्रेट्स ट्रांसफ़ॉर्म के साथ पाइपलाइन क्रम:

- **अनुशंसित:** जज को सीक्रेट्स ट्रांसफ़ॉर्म से **पहले** रखें। LLM प्रदाता को
  प्रॉक्सी टोकन दिखते हैं, वास्तविक क्रेडेंशियल कभी नहीं जिन तक वर्कलोड की पहुँच है।
- वैकल्पिक रूप से, जज को सीक्रेट्स के बाद रखने से वह उस सटीक वायर फ़ॉर्म का
  मूल्यांकन कर सकता है जो बाहर जाएगा, जिसकी कीमत LLM प्रदाता को वास्तविक क्रेडेंशियल
  भेजना है। यह विकल्प केवल तभी चुनें यदि आपका थ्रेट मॉडल उस समझौते को स्वीकार करता है।

समर्थित प्रदाता:

- **`anthropic`** (Messages API). `api_key_env`, `model`, वैकल्पिक
  `base_url` और `max_tokens` का उपयोग करता है।
- **`openai`** (Chat Completions API). ऊपर के समान फ़ील्ड; `type: openai` सेट करें,
  `api_key_env` को अपनी OpenAI कुंजी रखने वाले env वेरिएबल की ओर इंगित करें, और
  `gpt-5.4-nano` जैसा मॉडल चुनें।

ऑडिट आउटपुट: प्रत्येक मेल खाने वाला अनुरोध ट्रांसफ़ॉर्म ट्रेस के अंतर्गत संरचित फ़ील्ड
जोड़ता है, जिनमें `judge.instance`, `judge.decision`, `judge.reason`,
`judge.duration_ms`, `judge.input_tokens`, `judge.output_tokens`,
`judge.fallback_applied` (जब फ़ॉलबैक लागू होता है), और
`judge.circuit_breaker_tripped` (जब ब्रेकर खुला होता है) शामिल हैं।

श्रेय: Brex को उनके CrabTrap प्रोजेक्ट (MIT-लाइसेंस) के लिए धन्यवाद, जिसने
इस डिज़ाइन को प्रभावित किया।

## MCP नीति

iron-proxy [MCP का Streamable HTTP ट्रांसपोर्ट](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) पर बात कर सकता है। जब कोई अनुरोध किसी कॉन्फ़िगर किए गए MCP सर्वर से मेल खाता है, तो प्रॉक्सी JSON-RPC बॉडी को पार्स करता है, एक डिफ़ॉल्ट-अस्वीकृति टूल अनुमतिसूची लागू करता है, और `tools/list` प्रतिक्रियाओं को फ़िल्टर करता है ताकि अस्वीकृत टूल एजेंट तक कभी न पहुँचें। SSE प्रतिक्रियाओं को प्रति-ईवेंट फ़िल्टर किया जाता है ताकि लंबे समय तक चलने वाले MCP स्ट्रीम सक्रिय रहें।

यह ट्रांसफ़ॉर्म के बजाय एक प्रथम-श्रेणी की प्रॉक्सी क्षमता है: MCP प्रतिक्रियाएँ असीमित SSE स्ट्रीम हो सकती हैं जो स्वेच्छित सर्वर-आरंभित संदेश ले जाती हैं, जो अनुरोध/प्रतिक्रिया ट्रांसफ़ॉर्म अनुबंध में फिट नहीं बैठतीं।```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).

Behavior:

tools/call प्रवर्तन। जो उपकरण सर्वर की tools सूची में नहीं हैं, या जिनके arguments किसी भी when खंड में विफल होते हैं, उनके कॉल upstream तक पहुँचे बिना अस्वीकार कर दिए जाते हैं। प्रॉक्सी कॉन्फ़िगर किए गए कोड और संदेश तथा अनुरोध के मूल id के साथ JSON-RPC त्रुटि प्रतिक्रिया लौटाता है, जिससे MCP क्लाइंट HTTP विफलता के बजाय एक सामान्य प्रोटोकॉल त्रुटि देखता है।
tools/list फ़िल्टरिंग। tools/list की प्रतिक्रियाओं से, एजेंट तक पहुँचने से पहले, allowlist पर नहीं होने वाले किसी भी उपकरण को हटा दिया जाता है। यह application/json और text/event-stream दोनों प्रतिक्रियाओं के लिए काम करता है; SSE फ़िल्टरिंग प्रति घटना कार्य करती है, जिससे स्ट्रीम पर हार्टबीट और अन्य संदेश बिना किसी बदलाव के गुज़र जाते हैं।
तर्क मिलान। प्रत्येक when खंड में एक डॉटेड path (जैसे arguments.repo, ) और इनमें से एक होता है: (कोई भी JSON स्केलर), (स्केलर की सूची), या (स्ट्रिंग मानों पर रेगेक्स)। खंड AND से जुड़ते हैं। को छोड़ देने पर उपकरण बिना शर्त अनुमति देता है।

पाइपलाइन क्रम: MCP इंटरसेप्टर transform पाइपलाइन के बाद चलता है, इसलिए allowlist अभी भी निर्धारित करता है कि किन होस्ट तक पहुँचा जा सकता है, और जब तक इंटरसेप्टर बॉडी का मूल्यांकन करता है, secrets पहले ही प्रॉक्सी टोकन बदल चुका होता है।

MCP Gateway

mcp_gateway MCP नीति द्वारा अनुरोध स्वीकार किए जाने के बाद क्लाइंट-फेसिंग MCP होस्ट को ठोस upstream सर्वरों तक रूट करता है। यह एजेंटों को स्थिर आंतरिक होस्ट कॉल करने देता है, जबकि iron-proxy वास्तविक upstream तक अग्रेषित करता है और ऐसे क्रेडेंशियल इंजेक्ट करता है जो कभी सैंडबॉक्स में प्रवेश नहीं करते।

गेटवे रूट केवल उन अनुरोधों पर लागू होते हैं जो किसी MCP सर्वर से मेल खाते हैं। MCP नीति अभी भी पहले उपकरण allowlist लागू करती है। यदि नीति किसी tools/call को अस्वीकार करती है, तो गेटवे रूट लागू नहीं होता और upstream तक नहीं पहुँचा जाता।```yaml mcp: servers: - name: github rules: - host: "github.mcp.local" paths: ["/mcp", "/mcp/*"] tools: - name: "search_repositories"

mcp_gateway: routes: - name: github rules: - host: "github.mcp.local" paths: ["/mcp", "/mcp/*"] upstream: "https://mcp.github.com/v1" credentials: - source: type: env var: GITHUB_MCP_TOKEN inject: header: Authorization formatter: "Bearer {{ .Value }}"

क्रेडेंशियल्स `secrets` ट्रांसफ़ॉर्म के समान सीक्रेट स्रोतों का उपयोग करते हैं। वे डिफ़ॉल्ट रूप से आवश्यक होते हैं। किसी क्रेडेंशियल पर `require: false` सेट करें ताकि अनुपलब्ध होने पर उसे छोड़ दिया जाए। ऑडिट लॉग रूट, अपस्ट्रीम URL, और क्रेडेंशियल इंजेक्शन स्थानों को रिकॉर्ड करते हैं, लेकिन इंजेक्ट किए गए क्रेडेंशियल मानों को कभी नहीं।

v1 में सीमाएँ:

- केवल Streamable HTTP ट्रांसपोर्ट समर्थित है। लीगेसी HTTP+SSE ट्रांसपोर्ट (अलग `/messages` और `/sse` एंडपॉइंट) समर्थित नहीं है।
- किसी भी अस्वीकृत प्रविष्टि वाला JSON-RPC बैच पूरे बैच के रूप में अस्वीकार कर दिया जाता है; आंशिक-बैच अग्रेषण समर्थित नहीं है।
- Resources और prompts लागू नहीं किए जाते हैं। एजेंट अभी भी पॉलिसी फ़िल्टरिंग के बिना `resources/list`, `resources/read`, आदि कॉल कर सकते हैं।

### बॉडी सीमाएँ

जो ट्रांसफ़ॉर्म अनुरोध/प्रतिक्रिया बॉडी का निरीक्षण या अग्रेषण करते हैं (secrets body
मिलान, gRPC ट्रांसफ़ॉर्म) बफ़र की गई बॉडी पर कार्य करते हैं। दो वैश्विक सेटिंग्स
अधिकतम बफ़र आकारों को नियंत्रित करती हैं:

- **`max_request_body_bytes`** (डिफ़ॉल्ट: `1048576` / 1 MiB): यह सीमित करता है कि
  ट्रांसफ़ॉर्म के लिए अनुरोध बॉडी का कितना हिस्सा बफ़र किया जाता है। इस सीमा से परे डेटा
  ट्रांसफ़ॉर्म के दृष्टिकोण से काट दिया जाता है, लेकिन फिर भी अपस्ट्रीम को अग्रेषित किया जाता है।
- **`max_response_body_bytes`** (डिफ़ॉल्ट: `0` / असीमित): यह सीमित करता है कि
  प्रतिक्रिया बॉडी का कितना हिस्सा बफ़र किया जाता है। पूरी प्रतिक्रिया बफ़र करने के लिए `0` सेट करें, जो
  अधिकांश वर्कलोड के लिए सही डिफ़ॉल्ट है (जैसे, npm पैकेज, मॉडल वेट)।

बॉडी को ट्रांसफ़ॉर्म द्वारा पढ़े जाने पर वृद्धिशील रूप से बफ़र किया जाता है, और स्वचालित रूप से
पाइपलाइन चरणों के बीच रीवाउंड किया जाता है। यदि कोई ट्रांसफ़ॉर्म बॉडी नहीं पढ़ता है, तो कोई
बफ़रिंग नहीं होती है और बॉडी बिना छुए स्ट्रीम होती रहती है।

### टनल लिसनर (HTTP/CONNECT/SOCKS5)

टनल लिसनर absolute-form HTTP प्रॉक्सी अनुरोध, HTTP CONNECT,
और SOCKS5 कनेक्शन एक समर्पित पोर्ट पर स्वीकार करता है। यह उन टूल्स के लिए उपयोगी है जो
`HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY` पर्यावरण चर या SOCKS5 सेटिंग्स के माध्यम से
प्रॉक्सी कॉन्फ़िगरेशन का मूल रूप से समर्थन करते हैं, बजाय DNS-आधारित
रूटिंग पर निर्भर रहने के।

इसे सक्षम करने के लिए, `proxy` के अंतर्गत `tunnel_listen` सेट करें:```yaml
proxy:
  tunnel_listen: ":8080"

जब इसे छोड़ दिया जाता है, तो टनल लिसनर अक्षम हो जाता है।

सभी प्रोटोकॉल नियमित HTTP/HTTPS अनुरोधों की तरह ही एक ही ट्रांसफ़ॉर्म पाइपलाइन से गुजरते हैं। एब्सोल्यूट-फॉर्म HTTP अनुरोध सामान्य HTTP प्रॉक्सी पथ द्वारा संभाले जाते हैं। CONNECT और SOCKS5 के लिए, प्रॉक्सी आपकी allowlist और secrets ट्रांसफ़ॉर्म के विरुद्ध एक सिंथेटिक CONNECT अनुरोध का मूल्यांकन करता है, इसलिए टनल कनेक्शन उसी डिफ़ॉल्ट-अस्वीकार नीति के अधीन होते हैं।

CONNECT या SOCKS5 हैंडशेक के बाद, प्रॉक्सी आंतरिक प्रोटोकॉल का पता लगाने के लिए पहले बाइट पर नज़र डालता है:

TLS (0x16): HTTPS लिसनर की तरह ही MITM करता है, तुरंत एक लीफ सर्टिफिकेट जनरेट करके ताकि ट्रांसफ़ॉर्म अनुरोध का निरीक्षण और पुनर्लेखन कर सकें।
Plain HTTP: अनुरोध को सीधे ट्रांसफ़ॉर्म पाइपलाइन के माध्यम से सर्व करता है।

HTTP CONNECT उदाहरण:```bash curl -x http://172.20.0.2:8080
--cacert /certs/ca.crt
https://httpbin.org/get

**सामान्य HTTP प्रॉक्सी उदाहरण:**```bash
curl -x http://172.20.0.2:8080 \
  http://httpbin.org/get

SOCKS5 उदाहरण:```bash curl --socks5-hostname 172.20.0.2:8080
--cacert /certs/ca.crt
https://httpbin.org/get

आप मानक पर्यावरण चर भी सेट कर सकते हैं ताकि सभी टूल्स स्वचालित रूप से सुरंग के माध्यम से रूट हो जाएं:```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

SOCKS5 कार्यान्वयन केवल no-auth का समर्थन करता है और IPv4, IPv6, तथा डोमेन नाम पता प्रकारों को स्वीकार करता है।

TLS

iron-proxy मौके पर लीफ प्रमाणपत्र उत्पन्न करता है, जिन पर आपके द्वारा प्रदान किए गए CA द्वारा हस्ताक्षर होते हैं। क्लाइंट कंटेनर को इस CA पर भरोसा करना चाहिए (इसे सिस्टम ट्रस्ट स्टोर में जोड़ें या इसे --cacert के माध्यम से पास करें)। प्रमाणपत्र SNI होस्टनाम के आधार पर LRU कैश में कैश किए जाते हैं।

प्रॉक्सी पर ट्रैफ़िक रूट करना

बढ़ते प्रवर्तन के साथ तीन दृष्टिकोण हैं।

DNS-आधारित (सरल)

कंटेनर का DNS iron-proxy की ओर इंगित करें। सभी लुकअप प्रॉक्सी IP पर हल होते हैं, इसलिए HTTP/HTTPS ट्रैफ़िक स्वाभाविक रूप से इसके माध्यम से प्रवाहित होता है। यही वह है जो Docker Compose उदाहरण उपयोग करता है:```yaml services: client: dns: - 172.20.0.2 # iron-proxy IP

सेट अप करना आसान है लेकिन बायपास करना भी आसान: वर्कलोड IPs को हार्डकोड कर सकता है या अपने
DNS resolver का उपयोग कर सकता है ताकि प्रॉक्सी को पूरी तरह से बायपास कर सके।

### DNS + nftables एग्रेस फ़ायरवॉल (प्रवर्तित)

DNS रूटिंग के ऊपर nftables फ़ायरवॉल की एक परत लगाएँ। DNS अभी भी ट्रैफ़िक को प्रॉक्सी की ओर मोड़ता है
लेकिन nftables यह सुनिश्चित करता है कि वर्कलोड किसी और चीज़ से बात _नहीं कर सकता_,
यहाँ तक कि हार्डकोडेड IPs के साथ भी।

[`examples/nftables`](https://github.com/paradigmxyz/iron-proxy/blob/HEAD/examples/nftables/) निर्देशिका में एक कार्यशील सेटअप है।
क्लाइंट कंटेनर स्टार्टअप पर फ़ायरवॉल नियम लोड करता है, किसी भी
एप्लिकेशन ट्रैफ़िक को चलाने से पहले:

**nftables.conf** प्रॉक्सी तक ट्रैफ़िक की अनुमति देता है, बाकी सब कुछ ड्रॉप कर देता है:```
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
  }
}

docker-compose.yml: क्लाइंट इमेज nftables पहले से इंस्टॉल के साथ बनाई गई है। entrypoint नियमों को लोड करता है, फिर डेमो चलाता है। CAP_NET_ADMIN नियमों को लोड करने के लिए आवश्यक है:```yaml services: proxy: # ... same as DNS example ... networks: demo: ipv4_address: 172.20.0.2

client: build: context: . dockerfile: Dockerfile.client # alpine + curl + nftables dns: - 172.20.0.2 cap_add: - NET_ADMIN volumes: - ./nftables.conf:/etc/nftables.conf:ro - certs:/certs:ro networks: demo: ipv4_address: 172.20.0.4

प्रोडक्शन सेटअप में आप नियमों को एक एंट्रीपॉइंट रैपर में लोड करेंगे और फिर
`exec` के माध्यम से अपनी वास्तविक प्रक्रिया को `CAP_NET_ADMIN` के बिना एक गैर-root उपयोगकर्ता के रूप में चलाएँगे।

### TPROXY (पारदर्शी प्रॉक्सी)

उन वातावरणों के लिए जहाँ आप वर्कलोड के DNS को बिल्कुल नियंत्रित नहीं कर सकते, nftables
TPROXY बिना वर्कलोड के किसी सहयोग के कर्नेल स्तर पर ट्रैफ़िक को पुनर्निर्देशित कर सकता है। यह PREROUTING श्रृंखला में पैकेटों को इंटरसेप्ट करता है और उन्हें सीधे iron-proxy को सौंप देता है:```
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
  }
}

इसके लिए चिह्नित पैकेट्स को स्थानीय सॉकेट तक रूट करने हेतु ip rule और ip route सेटअप आवश्यक है, साथ ही iron-proxy को IP_TRANSPARENT के साथ बाइंड होना चाहिए। यह सेटअप अधिक जटिल है, लेकिन यह सबसे मजबूत गारंटी प्रदान करता है कि ट्रैफ़िक प्रॉक्सी को बायपास नहीं कर सकता। TPROXY DNS स्तर से नीचे काम करता है, इसलिए यह हार्डकोडेड IPs, कस्टम रिज़ॉल्वर्स और वर्कलोड द्वारा आज़माई जाने वाली किसी भी अन्य चीज़ को पकड़ लेता है।

Docker Compose उदाहरण

examples/docker-compose डायरेक्टरी में एक कार्यशील सेटअप मौजूद है। मुख्य भाग:

docker-compose.yml: प्रॉक्सी और क्लाइंट एक साझा ब्रिज नेटवर्क पर हैं। वास्तविक सीक्रेट्स केवल प्रॉक्सी कंटेनर पर env vars के रूप में सेट किए जाते हैं:```yaml services: proxy: build: context: ../.. dockerfile: examples/docker-compose/Dockerfile environment: - OPENAI_API_KEY=sk-real-openai-key-do-not-share - INTERNAL_TOKEN=real-internal-secret-value volumes: - certs:/certs networks: demo: ipv4_address: 172.20.0.2

client: image: alpine:latest dns: - 172.20.0.2 # Point DNS at the proxy volumes: - certs:/certs:ro networks: demo: ipv4_address: 172.20.0.4

**proxy.yaml** `httpbin.org` और `icanhazip.com` को अनुमत सूची में डालता है, और दो गोपनीय जानकारियों की अदला-बदली करता है:```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"

क्लाइंट स्क्रिप्ट प्रत्येक व्यवहार को प्रदर्शित करने के लिए पाँच अनुरोध भेजती है:```bash

1. Allowed request

curl https://httpbin.org/get

2. Blocked request (not in allowlist)

curl https://example.com/

3. Secret swap: proxy token replaced with real key in Authorization header

curl -H "Authorization: Bearer proxy-openai-abc123" https://httpbin.org/headers

4. Secret swap: proxy token in custom header

curl -H "X-Internal: proxy-internal-tok" https://httpbin.org/headers

5. Secret swap: proxy token in query parameter

curl "https://httpbin.org/get?token=proxy-openai-abc123&q=hello"

## ऑडिट लॉग प्रारूप

प्रत्येक प्रॉक्सी अनुरोध एक संरचित JSON लॉग प्रविष्टि उत्पन्न करता है:```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": []
}

अस्वीकृत अनुरोधों में rejected_by फ़ील्ड शामिल होती है और वे WARN स्तर पर लॉग होते हैं।

OpenTelemetry निर्यात

ऑडिट इवेंट्स को OpenTelemetry संरचित लॉग रिकॉर्ड के रूप में निर्यात किया जा सकता है, ताकि Axiom, ClickHouse, या Logfire जैसे बैकएंड्स में ऑफ़लाइन विश्लेषण किया जा सके। सक्षम करने के लिए OTEL_EXPORTER_OTLP_ENDPOINT सेट करें:```bash docker run -d --name iron-proxy
-e OTEL_EXPORTER_OTLP_ENDPOINT=https://logfire-us.pydantic.dev
-e OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
-e OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer "
-e OTEL_SERVICE_NAME=iron-proxy
-e OTEL_RESOURCE_ATTRIBUTES="deployment.environment=staging" \

... other flags ...

ironsh/iron-proxy:latest -config /etc/iron-proxy/proxy.yaml

सभी कॉन्फ़िगरेशन मानक OTEL पर्यावरण चरों का उपयोग करता है:

| चर                                       | विवरण                                                            | डिफ़ॉल्ट          |
| ------------------------------ | ------------------------------------------------------- | ---------------- |
| `OTEL_EXPORTER_OTLP_ENDPOINT` | OTLP कलेक्टर URL। सेट न होने पर OTEL निर्यात अक्षम होता है। | (अक्षम)       |
| `OTEL_EXPORTER_OTLP_PROTOCOL` | `http/protobuf` या `grpc`।                              | `http/protobuf`  |
| `OTEL_EXPORTER_OTLP_HEADERS`  | प्रमाणीकरण हेडर के लिए अल्पविराम से अलग किए गए `key=value` जोड़े। | (कोई नहीं)       |
| `OTEL_SERVICE_NAME`            | सभी लॉग रिकॉर्ड से जुड़ा सेवा नाम।                         | `iron-proxy`     |
| `OTEL_RESOURCE_ATTRIBUTES`    | अल्पविराम से अलग किए गए `key=value` संसाधन विशेषताएँ।        | (कोई नहीं)       |

सक्षम होने पर, हर ऑडिट इवेंट मौजूदा JSON stderr लॉग के साथ-साथ एक OTEL लॉग रिकॉर्ड के रूप में उत्सर्जित होता है। लॉग रिकॉर्ड JSON ऑडिट प्रविष्टि के समान स्कीमा रखता है: `host`, `method`, `path`, `action`, `status_code`, `duration_ms`, और एनोटेशन के साथ पूर्ण `request_transforms`/`response_transforms` ऐरे।

## प्रबंधन API

iron-proxy वैकल्पिक रूप से परिचालन कार्यों के लिए एक प्रमाणित HTTP API उजागर कर सकता है। वर्तमान में यह एक एकल एंडपॉइंट, `POST /v1/reload`, प्रदान करता है जो डिस्क से YAML कॉन्फ़िगरेशन को दोबारा पढ़ता है और नवनिर्मित ट्रांसफ़ॉर्म पाइपलाइन को परमाणु रूप से स्वैप कर देता है। यदि नया कॉन्फ़िगरेशन अमान्य है तो चालू पाइपलाइन संरक्षित रखी जाती है।

प्रबंधन सर्वर डिफ़ॉल्ट रूप से अक्षम है। इसे सक्षम करने के लिए, अपनी कॉन्फ़िगरेशन में एक `management` ब्लॉक जोड़ें:```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"

केवल स्टैंडअलोन मोड — कंट्रोल-प्लेन प्रबंधित मोड के साथ असंगत।

चालू प्रॉक्सी को पुनः लोड करें:```bash curl -X POST http://127.0.0.1:9092/v1/reload
-H "Authorization: Bearer $IRON_MANAGEMENT_API_KEY"

## iron.sh

क्या आपको Vault/KMS सीक्रेट बैकएंड, Kubernetes ऑपरेटर, या केंद्रीकृत पॉलिसी
प्रबंधन की आवश्यकता है? [iron.sh](https://iron.sh) iron-proxy पर आधारित है, और एंटरप्राइज़
सुविधाएँ इसे बड़े पैमाने पर चलाने वाली टीमों के लिए।

## रिलीज़ हस्ताक्षर सत्यापित करें

रिलीज़ आर्टिफैक्ट्स में एक हस्ताक्षरित चेकसम मेनिफेस्ट शामिल होता है:

- `checksums.txt`
- `checksums.txt.asc` (ASCII-armored डिटैच्ड सिग्नेचर)

सत्यापित करने के लिए [`public-key.asc`](https://github.com/paradigmxyz/iron-proxy/blob/HEAD/public-key.asc) पर शामिल सार्वजनिक कुंजी का उपयोग करें:```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

यदि सत्यापन सफल होता है, तो GPG Matthew Slipper <[email protected]> से एक अच्छे हस्ताक्षर की सूचना देगा।

आप वैकल्पिक रूप से आयातित कुंजी फिंगरप्रिंट का निरीक्षण कर सकते हैं और सत्यापन से पहले पुष्टि कर सकते हैं कि यह आपके विश्वसनीय स्रोत से मेल खाता है।

हस्ताक्षरित चेकसम सूची के विरुद्ध किसी विशिष्ट बाइनरी को सत्यापित करने के लिए (उदाहरण: iron-proxy-linux-amd64):```bash shasum -a 256 iron-proxy-linux-amd64 | grep -F "$(grep -F 'iron-proxy-linux-amd64' checksums.txt | awk '{print $1}')"

iron-proxy

सबसे लोकप्रिय

iron-proxy

समस्या

iron-proxy क्या करता है

इंस्टॉलेशन

उत्पादन उपयोग

1. CA जनरेट करें

3. iron-proxy प्रारंभ करें

4. कंटेनरों को प्रॉक्सी के माध्यम से रूट करें

कॉन्फ़िगरेशन

हैडर अनुमतिसूची (Header allowlist)

Secrets

Judge

MCP Gateway

TLS

प्रॉक्सी पर ट्रैफ़िक रूट करना

DNS-आधारित (सरल)

Docker Compose उदाहरण

1. Allowed request

2. Blocked request (not in allowlist)

3. Secret swap: proxy token replaced with real key in Authorization header

4. Secret swap: proxy token in custom header

5. Secret swap: proxy token in query parameter

OpenTelemetry निर्यात

... other flags ...