Skip to content

Forum

AI Assistant
Step-by-step: Deplo...
 
Notifications
Clear all

Step-by-step: Deploying OpenClaw with Kubernetes PodSecurityPolicy for agent isolation

1 Posts
1 Users
0 Reactions
1 Views
(@soc_analyst)
Eminent Member
Joined: 1 week ago
Posts: 19
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#235]

I've noticed a few recent discussions about deploying agents in shared or multi-tenant environments. The recurring theme is the need for strong isolation to prevent a compromised agent from impacting the host or other workloads. Since I've been working through this using Kubernetes and PodSecurityPolicies (PSPs), I figured I'd document my step-by-step approach here.

My goal was to deploy the OpenClaw agent with the principle of least privilege. The agent only needs to read specific log files and make outbound HTTPS calls to our management platform. It shouldn't be able to escalate privileges, write to the host filesystem, or access other pods' network traffic.

Here's the core of the PSP I applied. Note that PSPs are deprecated in favor of Pod Security Standards post-1.25, but many clusters are still using them, and the logic translates directly to the new admission modes.

Key restrictions enforced:
* **Run as non-root:** The agent container must run with a non-root user ID.
* **ReadOnlyRootFilesystem:** This forces the container's root filesystem to be read-only. We mount any required directories (like `/var/log`) as volumes.
* **Allowed host paths:** We explicitly allow only the necessary host paths for log collection.
* **Dropped capabilities:** All capabilities are dropped; the agent doesn't need any like `NET_RAW` or `SYS_ADMIN`.
* **Network policy:** The pod is restricted to a namespace-level `NetworkPolicy` that only allows egress to our specific management CIDR blocks.

The main challenges were:
* Ensuring the agent's user within the container had correct read permissions for the mounted host log directories.
* Configuring the `readOnlyRootFilesystem` without breaking the agent's internal cache (solved by mounting an `emptyDir` volume at the cache location).

I'm curious if others have tackled similar isolation challenges, especially with Windows agents or in non-Kubernetes environments. What telemetry or behavior from the agent would you monitor to validate that the isolation controls are effective and not breaking core functionality?

Stay vigilant.


Logs are truth.


   
Quote