OpenClaw on Kubernetes: Test the Boundary Before Adding the Tools

An agent can run in a Kubernetes Pod and still have far too much authority. A mounted credential, a reachable management API, or a powerful tool can cross the boundary you thought the container provided.

We’ll design a small containment experiment first. The useful result is evidence about what the workload can and cannot do, before it receives real operational tools.

Start with the authority, not the image

List what the workload can read, change, and contact. Include mounted files, API credentials, tool permissions, outbound connections, and the people allowed to submit work.

OpenClaw’s security guidance assumes a trusted operator boundary; it is not a general hostile multi-tenant isolation service. Separate the gateway’s trust model from the infrastructure controls around it.

The diagram places a check between a proposed operation and its execution. That check must exist in the tool or execution system, independently of what the model says it intends to do.

Work through one harmless task

Suppose the agent’s only job is summarizing three synthetic log files. It needs read access to those files and perhaps a model API. It doesn’t need your cluster administrator credential, a host filesystem mount, or a container runtime socket.

Write an authority table before deployment:

These are test requirements, not claims that a namespace enforces them automatically.

Translate requirements into a Pod design

For an image that supports these settings, the following is a partial Pod specification, not a complete deployable application:

spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: agent
      # Supply a verified, pinned image and its documented command.
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: [ALL]

Turning off token automount avoids supplying a default Kubernetes credential to a task that doesn’t need one. Container security settings narrow specific operations; see the security-context reference.

Determine the image’s required user ID and writable paths from the release you select. Provide explicit writable volumes only where needed. A read-only root filesystem that prevents startup is a compatibility finding to investigate, not a reason to grant unrestricted host access.

Use the release’s installation documentation for its actual image, ports, state paths, and startup behavior. The previous article’s guessed image and dashboard details have been removed.

Test network authority separately

Start with no application connectivity, then introduce only the paths the experiment requires. Use the NetworkPolicy lesson to prove enforcement before adapting it.

Allowing all public IPv4 addresses on port 443 is not an allowlist of one model provider. It may allow many destinations, and it says nothing by itself about IPv6 or other reachable address spaces. A namespace is not a guarantee against reaching internal services.

For domain-based restrictions, choose an enforcement mechanism that supports that requirement and verify its resolution and proxy behavior. Don’t pretend that a domain name is a stable CIDR block.

Keep the agent sandbox and the Pod distinct

OpenClaw’s tool sandbox has its own execution policy. Running the gateway in a container doesn’t automatically establish that policy. Its sandbox documentation distinguishes tool execution from the gateway process and documents escape hatches such as elevated execution.

Record which process actually runs a tool and which credentials it inherits. An audit command can identify some configuration problems, but its success isn’t proof that every boundary you need has been tested.

Try a containment failure

Before adding a real tool, repeat the authority table with synthetic inputs, test rejection as well as success, and verify that you can remove the workload and revoke its credentials. The next step is binding approval to a specific proposed change (lesson in preparation).