HN 표시: Buildcage – Docker 빌드에 대한 송신 필터링(SNI 기반, MitM 없음)

Secure your Docker builds against supply chain attacks — restrict outbound network access to only the domains you allow. When you run RUN npm install or RUN pip install in a Dockerfile, those commands can execute arbitrary code and make outbound connections to any server on the internet — without visibility or control. A compromised dependency could silently exfiltrate your build secrets or phone home to an attacker's server. Buildcage prevents this. You define a list of allowed domains, and only those connections are permitted during builds. Everything else is blocked. No Dockerfile changes required. No proxy configuration needed. No certificates to install. Works with any language or package manager. Buildcage runs as a remote driver for Docker Buildx. All RUN step containers are placed on an isolated network, and outbound traffic is routed through a proxy that enforces your allowlist. - HTTPS: SNI (Server Name Indication) for domain matching — TLS is not terminated - HTTP: Host header for domain matching - Direct IP access: blocked unless explicitly allowed - Non-TCP protocols (UDP, ICMP, etc.): all blocked — only TCP connections are supported Two modes available (see Reference for details): - Audit mode: Records all network destinations during builds, useful for creating allowlists. - Restrict mode: Allows access only to permitted domains, blocking everything else. - CI/CD pipelines pulling from public registries — if your builds download packages from npm, PyPI, RubyGems, or other public sources, Buildcage limits the blast radius of compromised packages - Builds that handle secrets — if your Dockerfiles use build secrets, tokens, or credentials, Buildcage prevents them from being exfiltrated to unauthorized servers - Teams that need network visibility — if you need to know exactly which external services your builds contact, Buildcage logs every outbound connection and can enforce an allowlist - Fully offline builds — if your builds run in an air-gapped environment with no external network access - Internal-only registries — if all dependencies come from vetted, internal repositories with no public package sources - No-dependency builds — if your Dockerfile only copies files and never runs commands that fetch external resources - 🚀 GitHub Actions support: Available as reusable actions for CI/CD pipelines - ✅ Zero Dockerfile changes: Works with existing Dockerfiles without modification - 🔒 Network isolation: Isolates network access for each RUN step using CNI (Container Network Interface) - 🔍 Audit mode: Discover dependencies before enforcing restrictions - 🛡️ Restrict mode: Production-ready access control - 📊 Detailed logging: Complete visibility into all network connections during builds - 🔐 Self-hostable: Fork or import the repo to build and manage the image in your own GitHub environment — full control over what you trust - Docker with BuildKit (buildx plugin) - GitHub Actions runner with Docker support (for CI/CD usage) - Docker Compose (for local usage) Using Buildcage in GitHub Actions involves three workflow steps: - Start the Buildcage container (runs BuildKit inside a network-controlled environment) - Configure Docker Buildx to use the Buildcage container as a remote builder - Run your build as usual — your Dockerfile and build commands stay the same name: Discover Build Dependencies on: [push] jobs: audit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Start Buildcage in audit mode id: buildcage uses: dash14/buildcage/setup@v2 with: proxy_mode: audit # Log everything, block nothing - name: Set up Docker Buildx uses: docker/setup-buildx-action@v4 with: driver: remote endpoint: docker-container://buildcage - name: Build and discover dependencies uses: docker/build-push-action@v6 with: context: . push: false # Set to true to push the built image - name: Show Buildcage report if: always() uses: dash14/buildcage/report@v2 with: fail_on_blocked: false # Don't fail, just show the report See the complete example workflow. The report action outputs a Job Summary showing every domain your build contacted: Copy these domain names into allowed_https_rules or allowed_http_rules for Step 3. name: Secure Build on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Start Buildcage in restrict mode id: buildcage uses: dash14/buildcage/setup@v2 with: proxy_mode: restrict # Block everything except allowed domains allowed_https_rules: >- registry.npmjs.org:443 fonts.googleapis.com:443 name: Set up Docker Buildx uses: docker/setup-buildx-action@v4 with: driver: remote endpoint: docker-container://buildcage - name: Build with protection uses: docker/build-push-action@v6 with: context: . push: false # Set to true to push the built image - name: Show Buildcage report if: always() uses: dash14/buildcage/report@v2 # Build fails if any unexpected connections were blocked See the complete example workflow. Your builds are now protected. Any unexpected connections wil