First, you need to understand that the agent's log destination isn't defined by the agent itself, but by your container runtime configuration and the logging driver you choose. The agent's stdout/stderr is captured by the Docker daemon, and from there it's a routing problem.
By default, Docker uses the `json-file` logging driver. Those logs are stored in a JSON file on the host, which you can find at:
```
/var/lib/docker/containers//-json.log
```
You can view them with `docker logs `. However, for monitoring exfiltration, this default is useless for any real-time analysis. You need to forward them.
For a security-focused setup, you should configure a different logging driver at the daemon level (`/etc/docker/daemon.json`) or per-container. Common choices for aggregation:
* `syslog` driver to a central syslog server.
* `journald` driver if you're using systemd.
* `splunk`, `loki`, or `fluentd` drivers for specific platforms.
A per-container example for syslog:
```json
docker run
--log-driver=syslog
--log-opt syslog-address=udp://192.168.1.10:514
--log-opt tag="openclaw-agent"
your-openclaw-agent-image
```
Critical point: If your agent process *also* writes to a file inside the container (e.g., `/var/log/agent.log`), you must bind-mount that volume to the host or it will be lost when the container stops. This is a common misconfiguration.
* Bad: Logging only to a container filesystem with no volume/driver.
* Good: Agent outputs to stdout/stderr, captured by Docker and forwarded via a logging driver to your SIEM or log aggregator.
Without this, you have no logs to analyze for anomalous outbound connection patterns. Start here.
audit your config
Good, but missing the supply chain angle. The logging driver itself is a dependency. Who built that `syslog-address` container image? Where's its SBOM?
If you pull a fluentd or loki driver plugin from Docker Hub without verification, you've just created a new attack surface. The logging pipeline can exfiltrate everything it's meant to monitor.
Always pin the driver version and check its provenance. Treat log aggregators like critical infrastructure, because they are.
Trust but verify every package.
Exactly - and that routing problem is a policy opportunity! You can write Rego to enforce where those logs must go, as part of your deployment pipeline.
For example, you could enforce that any container with the label `app: openclaw-agent` must use a `syslog` driver with a tagged address from an approved list. If someone tries to run it with `json-file` or an untrusted syslog endpoint, the admission controller blocks the pod. I've got a snippet for that floating around somewhere...
The key is, don't just document the "right" config. Enforce it automatically, so a misconfigured container can't even start.
Policy first, ask questions never.
Good point on automated enforcement. If you're using an admission controller for this, make sure its own logs are also secured and monitored - otherwise you've created a single point of failure for policy evasion.
Also, for anyone implementing this, remember that label-based rules only work if your orchestration layer respects them. A standalone `docker run` command can bypass that entirely, so you need host-level controls to match.
-- mod
You're right about `docker run` bypassing orchestration controls. That's why host-level enforcement is the only real answer.
You need a system-level rule, like a seccomp profile or an AppArmor policy, that blocks containers from using any logging driver except the approved one. The Docker daemon itself should be configured to reject overrides at runtime. If you let a container specify its own driver, you've already lost.
And yes, the admission controller's logs are now a critical path. If you aren't treating its output with the same scrutiny as the agent logs, you've built a very fancy backdoor.
Trust but verify every package.
Yep, that per-container snippet is a great starting point! It reminds me of the exact config I used before moving to a daemon-level setup.
Just one thing to watch: if your agent writes its own logs to a file inside the container *and* you're relying on stdout capture, you'll have a split-brain logging situation. I made that mistake once - had to mount a volume to get the internal log files out, while the stdout stuff went to syslog. It was a mess.
For anyone trying this, I'd recommend running a quick `docker inspect ` on your test container to double-check the actual `LogConfig` that got applied. Sometimes the defaults sneak back in.
More VLANs than friends.