iron-proxy

문제

CI 작업, AI 코딩 에이전트, 샌드박스 컨테이너는 임의의 아웃바운드 요청을 보낼 수 있습니다. 침해된 의존성, 프롬프트 인젝션, 또는 악의적인 빌드 단계는 시크릿을 유출하거나, 외부로 신호를 보내거나, 리버스 셸을 열 수 있습니다. 대부분의 팀은 자신의 워크로드에서 무엇이 나가는지에 대한 가시성이 전혀 없으며, 이를 막을 방법조차 없습니다.

iron-proxy가 하는 일

iron-proxy는 내장 DNS 서버를 갖춘 MITM 이그레스 프록시로, 신뢰할 수 없는 워크로드와 인터넷 사이에 위치합니다. 네트워크 경계에서 기본 거부(default-deny)를 적용하므로, 워크로드는 명시적으로 허용한 도메인에만 접근할 수 있습니다. 실제 시크릿은 샌드박스에 절대 들어가지 않습니다. 워크로드는 프록시 토큰을 사용하고, iron-proxy가 이그레스 시점에 실제 자격 증명으로 교체하므로, 침해된 워크로드가 유출할 수 있는 것은 프록시 외부에서는 무용지물인 토큰뿐입니다.

단일 바이너리. 단일 YAML 설정.

• 기본 거부 이그레스. 모든 아웃바운드 요청은 목적지가 허용 목록과 일치하지 않으면 차단됩니다. 도메인과 CIDR을 나열하면, 그 외 모든 것은 403을 받습니다.
• 업스트림 IP 거부 목록. 호스트가 허용되더라도, 확인된 주소가 거부된 CIDR 내에 있으면 프록시는 연결을 거부합니다. 이는 허용 목록에 있는 호스트 이름이 IMDS나 루프백을 가리키는 SSRF/DNS 리바인딩 격차를 막습니다. 클라우드 메타데이터 엔드포인트(169.254.169.254, fd00:ec2::254, fd20:ce::254)와 루프백은 기본적으로 거부되며, 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 행 수준 보안과 결합하여 테넌트별 데이터 격리를 제공합니다. PgBouncer를 사용하는 경우 pool_mode = session으로 실행해야 합니다 — 트랜잭션 또는 문장 풀 모드는 쿼리 사이에 백엔드를 조용히 재바인딩하여 정책을 무력화합니다. 자세한 내용은 docs.iron.sh를 참조하세요.

CI 파이프라인, GitHub Actions, AI 에이전트(Claude Code, Cursor, Codex), 그리고 완전히 신뢰하지 않는 코드를 실행하는 모든 환경을 위해 만들어졌습니다.

설치

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는 사용자가 제공한 CA로 서명된 리프 인증서를 즉석에서 생성하여 TLS를 종료합니다. 클라이언트 컨테이너는 이 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는 컨테이너가 DNS를 가리킬 수 있도록 고정 IP가 필요합니다:```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

## 주요 기능