Alright, I'll bite. Been implementing OpenClaw for a few months now, and I keep hitting the same wall: the orchestrator pod is ignoring the `NetworkPolicy` we have in place to block egress to the internet. It's supposed to only talk to the tool executor pods and our internal HashiCorp Vault cluster.
The policy is straightforward. We're using a deny-all-egress default, then whitelisting specific CIDRs and pod selectors.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-egress
spec:
podSelector: {}
policyTypes:
- Egress
egress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: orchestrator-allow-specific
spec:
podSelector:
matchLabels:
app: openclaw-orchestrator
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
component: tool-executor
- to:
- ipBlock:
cidr: 10.42.0.0/24 # Our Vault CIDR
ports:
- protocol: TCP
port: 8200
```
Yet, when I tail the orchestrator logs, I see it making successful HTTP calls to external APIs for things like geolocation lookups and vulnerability DB pulls—calls that should be gated *through* a tool executor, not initiated directly. The network policy should be dropping these packets, but they're going through.
What I'm seeing:
* Direct egress to `api.ipgeolocation.io` (and others) from the orchestrator pod.
* No corresponding logs in the designated "web-request" tool executor pods.
* `kubectl describe networkpolicy` confirms the policies are applied to the namespace.
This breaks the whole trust boundary model. The orchestrator shouldn't have a direct internet pipe. If it's bypassing the tool executor, then all the input sanitization and output filtering we built into the executors is useless. It also means our egress audit trail is incomplete.
Is this a known bug in the current release, or have I misconfigured something fundamental? I've verified Calico is running and the policies are non-zero. Anyone else seeing this, or am I the lucky one?
ship it or break it.
Ah, classic. Your policy looks correct, which means it's probably not the policy. The orchestrator might be inheriting a service account token that's mounted by default, and some CNI plugins (looking at you, Calico in certain modes) don't apply egress rules to traffic to the API server. If the orchestrator is using in-cluster service discovery for those external calls (like `kubernetes.default.svc` for the API), that traffic might be bypassing your policy.
Quick test: can you exec into the orchestrator pod and try a raw curl to one of those external APIs? Then check if the traffic is actually exiting the node via the expected interface. Sometimes it's a hairpin through the node's network stack that slips through.
Also, double-check your pod labels. A typo in `matchLabels` would leave the pod uncovered by your allow policy, so it'd only get the deny-all, which... would actually block the calls. So if the calls are working, the pod *is* likely matching your allow policy. Might be a CNI quirk.
Segregate and conquer.