Skip to content
All writing Part 09 of 12 · Remote-Controlling Chrome in Containers
Engineering · 2 min read

NetworkPolicy: Locking the Unauthenticated Front Door

CDP has no password and socat opens it to the cluster. One NetworkPolicy restricts ingress to the API pod only, plus two traps to watch for.

The Risk

socat listens on 0.0.0.0:9222. It accepts connections from any pod in the cluster. CDP has no password. Any pod that connects can control Chrome: navigate URLs, read page content, run JavaScript, and use paid proxy credentials.

Without NetworkPolicy Any pod in cluster Chrome :9222 (no auth) SSRF + credential leak With NetworkPolicy Only render-api Chrome :9222 one caller, no lateral move

The Fix

A NetworkPolicy that allows ingress only from the API pod:

spec:
  podSelector:
    matchLabels:
      app: render-chrome
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: render-api
      ports:
        - port: 9222

This rule tells Kubernetes: only pods with label render-api can connect to Chrome on port 9222. Block all others.

Two traps:

  • Name collision on shared clusters. If dev and staging share a cluster, both deployments create a NetworkPolicy with the same name. The second overwrites the first. Use env-prefixed names: dev-chrome-devtools-ingress.
  • The CNI must enforce it. Calico, Cilium, and the GKE default all work. Flannel does not. The policy applies but traffic flows anyway.

CDP has no password. socat is open to everyone. NetworkPolicy is the only lock on the door.


References:

Related: see the socat relay that opens this door, the Headless Service that routes to Chrome, or go back to the series overview.

Tags #kubernetes #chrome-devtools #containers
// connect

Be brave | Be wise | Be grateful

21 BreakinCode

// elsewhere
LinkedInMedium (lang: en)Life RecordYoutube
wh:~$William Hung· © 2026 Taipei · GMT+8 · Available for collaboration