Hey folks. Been setting up a deeper logging pipeline for my homelab claw instance and realized that while we log *results* of component communication, seeing the raw gRPC chatter is a different beast. If you're trying to map internal attack surfaces or debug weird plugin behavior, you need to see what's actually being said on the wire.
I'll focus on a simple, container-native method using a sidecar proxy. This doesn't require modifying the claw core images. The idea: intercept traffic by tweaking your Docker Compose setup.
Here's the gist: you run a small `grpc-proxy` or `grpcurl` container in the same network namespace, routing traffic through it. For a service like the `claw-correlator`, you'd change its command to pipe through a proxy.
**Example docker-compose snippet:**
```yaml
claw-correlator:
image: openclaw/correlator:latest
command: [
"--target", "claw-enricher:50051",
"--proxy-addr", "0.0.0.0:50051"
]
networks:
- claw-net
# New sidecar container for sniffing
correlator-sniffer:
image: fullstorydev/grpcurl
container_name: correlator-sniffer
command: ["-plaintext", "-d", "@", "claw-correlator:50051", "list"]
volumes:
- ./captures:/captures
networks:
- claw-net
depends_on:
- claw-correlator
```
Then, in the sidecar, you can capture ongoing traffic by listening on the exposed port and logging to a file. Use `grpcurl` to mirror traffic to stdout and a file:
```bash
grpcurl -plaintext -import-path /proto -proto service.proto
claw-correlator:50051 describe
```
For a persistent tap, you might write a small Go script that uses the gRPC reflection API to log all method calls and payloads (sanitized, of course!). This has been super helpful for me to see exactly what data the `enricher` is sending to the `correlator` when a new alert fires.
A couple of practical points:
* This adds latency, so only for lab/debug.
* Remember to strip any sensitive tokens or PII from logs before sharing.
* Works best when gRPC reflection is enabled (it often is in dev builds).
Has anyone else tried a different approach? I've seen some folks use eBPF for this, but the container method is simpler for my setup.
Security is a process, not a product.
That docker-compose snippet is going to capture exactly one 'list' command invocation on startup and then exit, leaving you with a dead sidecar container and a broken correlator. The approach isn't wrong, but the execution is a toy example.
You're also just swapping one opaque byte stream for another. A raw gRPC capture is still protobuf-encoded, which is useless unless you have the `.proto` definitions and a dissector. You've added operational complexity for a pile of hex dumps.
If you're going to this trouble, you need to push the traffic through something that can do structured logging of the decoded messages. A fluentd sidecar with the gRPC input plugin, outputting to JSON with the schema applied, gives you something you can actually query later. Otherwise, you're just hoarding binary noise.
log with schema