‏iron-proxy: پروکسی امنیتی برای محیط‌های غیرقابل اعتماد

CI جاب‌ها، ایجنت‌های AI مثل Claude Code یا Cursor، و کانتینرهای ایزوله‌شده می‌تونن درخواست‌های دلخواه به اینترنت بزنن. یه دپندنسی آلوده، یه prompt injection، یا یه build step مخرب می‌تونه سِکرت‌ها رو exfiltrate کنه یا یه reverse shell باز کنه. iron-proxy دقیقاً برای حل این مشکل ساخته شده: یه پروکسی MITM که جلوی خروجی ناخواسته رو می‌گیره.

iron-proxy یه DNS server داخلی داره و بین workload و اینترنت می‌شینه. وقتی DNS کانتینر رو به iron-proxy اشاره بدی، همه درخواست‌ها از طریقش رد می‌شن. پروکسی TLS رو terminate می‌کنه (گواهی موقت از CA خودت صادر می‌کنه)، درخواست رو از یه pipeline ترنسفورم رد می‌کنه، و بعد به upstream می‌فرسته. کل این فرایند در یه binary تکی با یه فایل YAML کانفیگ انجام می‌شه.

مهم‌ترین قابلیت‌ها اینان: default-deny egress (هر چیزی که در allowlist نباشه ۴۰۳ می‌گیره)، secret injection (workload فقط یه proxy token داره؛ iron-proxy اون رو با سِکرت واقعی عوض می‌کنه)، و upstream IP deny list (حتی اگه دامنه‌ای allowlist باشه ولی به IMDS یا loopback resolve بشه، بلاک می‌شه). این آخری جلوی حملات SSRF و DNS rebinding رو می‌گیره.

هر درخواست یه audit log ساختاریافته JSON تولید می‌کنه که نشون می‌ده کدوم سِکرت‌ها swap شدن، کدوم rule اجرا شد، و چرا چیزی بلاک شد:

{
  "host": "httpbin.org",
  "action": "allow",
  "status_code": 200,
  "request_transforms": [
    { "name": "allowlist", "action": "continue" },
    {
      "name": "secrets",
      "action": "continue",
      "annotations": { "swapped": [{ "secret": "OPENAI_API_KEY", "locations": ["header:Authorization"] }] }
    }
  ]
}

کانفیگ YAML شامل بخش‌های dns، proxy، tls، و transforms می‌شه. ترنسفورم‌ها به‌ترتیب اجرا می‌شن و هر کدوم یه کار مشخص دارن: allowlist درخواست‌ها رو فیلتر می‌کنه، secrets سِکرت‌ها رو swap می‌کنه، body_capture بدنه درخواست رو برای آدیت ضبط می‌کنه (مثلاً prompt‌هایی که به LLM می‌ره)، و header_allowlist هدرهای اضافه رو قبل از ارسال به upstream حذف می‌کنه.

یه ویژگی پیشرفته‌تر، ترنسفورم judge هست که یه LLM رو برای تصمیم‌گیری allow/deny صدا می‌زنه. مثلاً می‌شه به Github API یه judge وصل کرد که فقط درخواست‌های POST/DELETE رو با یه پرامپت سیاست‌محور بررسی کنه. judge فقط می‌تونه deny کنه — هرگز یه درخواستی که allowlist استاتیک رد کرده رو pass نمی‌کنه. iron-proxy همچنین یه PostgreSQL MITM proxy اختیاری داره که SET ROLE رو inject می‌کنه و از دستکاری role توسط کلاینت جلوگیری می‌کنه؛ مناسب برای ایزولاسیون داده‌های per-tenant.

نکات کلیدی:

• default-deny: هر درخواست خروجی که در allowlist نباشه بلاک می‌شه
• workloadها هیچ‌وقت سِکرت واقعی نمی‌بینن؛ فقط proxy token داری که خارج از پروکسی بی‌ارزشه
• جلوی SSRF و DNS rebinding رو با upstream IP deny list می‌گیره
• هر درخواست با جزئیات کامل transform pipeline لاگ می‌شه
• از WebSocket، SSE، CONNECT و SOCKS5 پشتیبانی می‌کنه
• منابع سِکرت: env var، AWS Secrets Manager، AWS SSM، 1Password، و token broker
• ترنسفورم judge امکان بررسی درخواست‌ها توسط LLM رو می‌ده