동적·ID 인식·안전한 Sandbox auth

Cloudflare Sandbox와 Containers에 outbound Workers가 추가되면서, 샌드박스의 모든 HTTP/HTTPS egress를 신뢰할 수 있는 프록시 코드로 제어할 수 있게 됐다. 샌드박스 안의 워크로드는 비신뢰 영역으로 두고, 인증과 정책은 바깥의 Worker가 담당한다.

핵심은 토큰을 워크로드에 직접 주지 않는 것이다. outbound와 outboundByHost를 이용하면 요청을 가로채서 로그를 남기고, 특정 메서드를 차단하고, 도메인별로 비밀값을 주입하고, 샌드박스 ID에 따라 다른 권한을 적용할 수 있다.

기존 auth 방식은 각각 약점이 있었다.

• Standard API tokens: 가장 단순하지만 샌드박스 유출 위험이 크다.
• Workload identity tokens(OIDC): 더 안전하지만 upstream 서비스의 네이티브 지원이 부족한 경우가 많다.
• Custom proxies: 유연하지만 모든 트래픽을 동적으로, 효율적으로 가로채는 구현이 어렵다.

Outbound Workers는 이 문제를 zero trust, simple, flexible, identity-aware, observable, performant, transparent, dynamic한 방식으로 묶는다. 예를 들어 my-internal-vcs.dev 요청에는 샌드박스가 볼 수 없는 SECRET을 헤더에 넣고, ctx.containerId를 기준으로 KV에서 다른 인증 키를 읽어 각 인스턴스별로 분리된 접근 제어를 할 수 있다.

Cloudflare Developer Platform과의 결합도 강점이다. outbound Worker 안에서 R2, KV, Agents, 다른 Containers, 다른 Worker services 바인딩을 직접 호출할 수 있어, 토큰 교환 로직 없이 코드만으로 세밀한 권한 정책을 구현한다.

네트워크 제어도 정적 설정에 묶이지 않는다. outboundHandlers와 setOutboundHandler로 부팅 시에는 allowHosts로 github.com과 npmjs.org만 열고, 작업이 끝나면 noHttp로 전환해 egress를 닫을 수 있다. 의존성 설치나 초기화 단계처럼 짧게만 필요한 네트워크 허용을 코드로 자동화하는 셈이다.

HTTPS까지 투명하게 다루려면 TLS 복호화가 필요하다. Cloudflare는 Sandbox 인스턴스마다 고유한 ephemeral CA와 private key를 만들고, 샌드박스는 그 CA를 신뢰하며, 컨테이너는 필요할 때 sudo update-ca-certificates로 이를 opt-in할 수 있다.

이 구조 덕분에 outbound Workers는 단순한 라우팅이 아니라 transparent MITM proxy처럼 동작한다. 샌드박스는 프로토콜이나 도메인별 세부 구현을 알 필요가 없고, 모든 HTTP/HTTPS 트래픽이 같은 제어면을 거쳐 필터링, 수정, 로깅된다.

하부 구현에서는 ctx.container에 interceptOutboundHttp와 interceptOutboundHttps를 추가해 특정 호스트명, IP 범위, 혹은 전체 outbound 트래픽을 가로챌 수 있게 했다. 실제 요청 처리는 WorkerEntrypoint가 맡아, outbound Worker가 샌드박스 네트워크의 정문 역할을 수행한다.