iron-proxy

O problema

Jobs de CI, agentes de codificação com IA e contêineres em sandbox podem fazer requisições de saída arbitrárias. Uma dependência comprometida, uma injeção de prompt ou uma etapa de build maliciosa pode exfiltrar segredos, fazer chamadas para casa ou abrir um reverse shell. A maioria das equipes não tem nenhuma visibilidade sobre o que está saindo de suas cargas de trabalho, muito menos alguma forma de impedir isso.

O que o iron-proxy faz

O iron-proxy é um proxy de saída MITM com um servidor DNS integrado que fica entre sua carga de trabalho não confiável e a internet. Ele aplica negação por padrão no limite da rede, de modo que a carga de trabalho só pode alcançar domínios que você permitir explicitamente. Segredos reais nunca entram no sandbox. As cargas de trabalho usam tokens de proxy, e o iron-proxy substitui por credenciais reais na saída, o que significa que uma carga de trabalho comprometida pode exfiltrar um token que é inútil fora do proxy.

Binário único. Configuração YAML única.

• Saída com negação por padrão. Toda requisição de saída é bloqueada a menos que o destino corresponda à sua allowlist. Liste seus domínios e CIDRs; todo o resto recebe um 403.
• Lista de negação de IP upstream. Mesmo quando um host é permitido, o proxy se recusa a discá-lo se seu endereço resolvido estiver dentro de um CIDR negado — fechando a brecha de SSRF/DNS-rebinding em que um hostname permitido aponta para IMDS ou loopback. Endpoints de metadados de nuvem (169.254.169.254, fd00:ec2::254 e fd20:ce::254) e loopback são negados por padrão; substitua via proxy.upstream_deny_cidrs ou IRON_PROXY_UPSTREAM_DENY_CIDRS.
• Injeção de segredos no limite. As cargas de trabalho enviam tokens de proxy; o iron-proxy os substitui por segredos reais antes que a requisição saia. Se o sandbox for comprometido, o atacante obtém tokens que são inúteis fora do proxy.
• Trilha de auditoria por requisição. Toda requisição é registrada como JSON estruturado com o resultado completo do pipeline de transformação: quais segredos foram trocados, quais regras corresponderam, o que foi bloqueado e por quê.
• Ciente de streaming. Upgrades de WebSocket e Server-Sent Events são proxiados nativamente. Nenhuma configuração especial para cargas de trabalho de agentes que mantêm conexões de longa duração.
• Suporte explícito a proxy. Listener de túnel opcional para ferramentas que suportam nativamente configuração de proxy via HTTP_PROXY, HTTPS_PROXY ou configurações SOCKS5.
• Proxy MITM para PostgreSQL. Listener opcional que autentica clientes contra credenciais gerenciadas pelo proxy, injeta SET ROLE na sessão upstream e rejeita tentativas do cliente de mutar o papel (SET ROLE, set_config('role', ...), blocos DO, etc.) por meio de uma travessia de AST SQL. Combina com row-level security do PostgreSQL para fornecer isolamento de dados por tenant quando a aplicação se conecta como um usuário de conta de serviço compartilhada. Requer que o PgBouncer (se usado) seja executado em pool_mode = session — os modos de pool transaction ou statement religam backends silenciosamente entre consultas e anulariam a política. Consulte docs.iron.sh para detalhes.

Feito para pipelines de CI, GitHub Actions, agentes de IA (Claude Code, Cursor, Codex) e qualquer ambiente onde você executa código em que não confia totalmente.

Instalação

Imagens Docker estão disponíveis no Docker Hub e binários pré-compilados para Linux/macOS (amd64/arm64) estão em GitHub Releases.

Ou compile a partir do código-fonte:```bash go build -o iron-proxy ./cmd/iron-proxy

## Início rápido```bash
cd examples/docker-compose
docker compose up

Isso inicia o iron-proxy e um cliente de demonstração que dispara cinco requisições através do proxy. Verifique os logs para ver requisições permitidas, bloqueadas e com segredos reescritos:```bash docker compose logs proxy

Cada requisição produz uma entrada de auditoria JSON estruturada:```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"] }] }
    }
  ]
}

Requisições rejeitadas incluem um campo rejected_by e são registradas no nível WARN. Consulte Formato do log de auditoria para o esquema completo.

Uso em produção

1. Gerar uma CA

O iron-proxy encerra o TLS gerando certificados leaf dinamicamente, assinados por uma CA que você fornece. Os contêineres cliente devem confiar nessa 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. Criar uma rede Docker

O iron-proxy precisa de um IP fixo para que os containers possam apontar o seu DNS para ele:```bash
docker network create --subnet=172.20.0.0/24 iron-proxy

3. Inicie o iron-proxy