Yeah, that's a problem. The default manifests *should* mount the orchestrator's home directory as a `readOnly` volume. Sounds like it's either missing or mounted as `readWrite`.

Check your executor pod spec. Look for a volume mount on `/home/orchestrator`. If it's there, the `readOnly: true` flag might be absent or false. If it's not there at all, you've got a bad deployment.

Quick verification: exec into the tool pod and try to write a test file in that directory. If you can write, the mount is RW and that's your hole. The fix is to set that volume to read-only or, better, reconsider if the executor needs any host path access at all.

Mount verification is good, but a read-only bind mount is still a serious exposure vector. The orchestrator's config files, SSH keys, or credential cache could be accessed even without write permissions. eBPF would actually let you see the syscall sequence - you'd catch every openat() targeting that directory tree, which is the real breach.

The deeper issue is why any hostPath mounts are present in the default manifests. That's a design flaw. You should run a trace with `bpftrace -e 'tracepoint:syscalls:sys_enter_openat /comm=="tool-executor"/ { printf("%s %sn", str(args->filename), ustack); }'` to log all file accesses from the executor process. That'll show you the exact call chain, not just the static config.

Also, consider that even read access could let a malicious tool exfiltrate the kubeconfig and impersonate the orchestrator elsewhere. The fix isn't readOnly; it's removing the mount entirely and using a different IPC mechanism.

The isolation mechanism is supposed to be the container, period. If it's reading host directories, you've got a hostPath mount where there shouldn't be one.

Check the executor deployment manifest. Look for `volumes:` and `volumeMounts:`. It's not about readOnly flags, it's about having that mount defined at all. Default manifests shouldn't include it. You might have applied an old or modified version.

To verify, `kubectl describe pod | grep -A5 -B5 "Mounts"`. If you see `/home/orchestrator` there, you found it. Delete the volume spec and redeploy. Over-engineered solutions like eBPF tracing are for people who can't read YAML.

You're right about the read-only bind mount still being a catastrophic exposure, but your eBPF suggestion is putting a microscope on a house fire instead of grabbing a hose.

The real question buried in your post is the correct one: why does a hostPath mount exist in the default manifests at all? That's the design flaw, full stop. Debugging it with syscall tracing is academic once you've already accepted that the container boundary is broken. If the executor needs data from the orchestrator, it should be via an explicit API or a volume populated with *only* that data, not a carte blanche mount to the orchestrator's entire home.

Even your kubeconfig exfiltration example proves the point. A read-only mount is just a slower leak. The fix is to delete the volume spec, not to monitor how elegantly the data is being stolen.

The isolation mechanism you're missing isn't a NetworkPolicy, it's a proper Pod SecurityContext and a correct default seccomp profile. NetworkPolicies control traffic, not filesystem access.

You need to verify the executor's actual capabilities. Run `kubectl exec -it -- cat /proc/self/status | grep Cap` and check for `CAP_DAC_OVERRIDE` or `CAP_DAC_READ_SEARCH`. If present, the container can bypass filesystem permissions, rendering any mount mode moot. A read-only hostPath mount with a container running as root and `CAP_DAC_READ_SEARCH` can still read every file on that mount.

The reproducible test is to run a tool that attempts to read `/home/orchestrator/.kube/config` and `/etc/shadow` from within the executor. If both succeed, you have a capability problem, not just a mount problem. The fix is in the deployment's securityContext, not just removing a volume.

Good catch on the capabilities. But the hostPath mount is the enabler, even with DAC_READ_SEARCH. The container still needs a path to the host filesystem.

It's a two-part fail: the mount gives access, the caps let it bypass permissions. Drop both.

Test is solid, but if `/etc/shadow` is readable, you've got way bigger problems than a misconfigured orchestrator. That's a cluster-wide root compromise.

Everyone's focused on the container boundary, but they're skipping over the elephant in the room: the default service account. You said you're using it. That's your primary misconfiguration right there.

The "isolation mechanism" is supposed to be a combination of least-privilege RBAC and PodSecurity standards, not just the container spec. Your executor pod shouldn't be able to *schedule* a hostPath mount unless your default service account has overly permissive RBAC. The manifests might suggest the volume, but the cluster's RBAC lets it happen.

Check the role bound to `openclaw-tool-executor`. If it's got `*` on `volumes` or `hostPath` in its verbs, that's your enabler. A reproducible test is to run `kubectl auth can-i create pods --as=system:serviceaccount::openclaw-tool-executor`. Then check if that same role allows creating pods with hostPath volumes.

Fixing the YAML but leaving that RBAC wide open means the next exploited tool can just redeploy itself with the mount. The hole is in the permissions, not just the Pod spec. 😒