A common pattern sends logs from each service to stdout, a per-host agent forwards them to a message broker, and a central service processes them. Secure each hop: mutual TLS between agent and broker, least-privilege access on the broker, secrets removed before logging, and no assumption that the broker prevents loss.
The pattern
The OWASP Microservices Security Cheat Sheet describes it: services write to standard output or error, a logging agent on each host forwards to a broker, and a central service processes the stream. It is popular because services stay simple and the pipeline can be swapped without code changes.
Hop by hop
Service to agent. The cheat sheet advises buffering logs locally but notes that local files do not guarantee lossless delivery. Plan for gaps, especially around crashes and node loss.
Agent to broker. Use mutual TLS between the agent and the broker. Give each agent identity only the right to publish to the log topic. If a compromised host can read the topic, it can read every service's logs.
Broker to processor. Apply least-privilege access control on the broker for the reading side too. The broker holds a copy of everything your services said. Treat it as sensitive storage.
Secrets in logs
The sheet says to remove secrets and sensitive data before logging, and points out that agent-side filtering cannot clean data already written to local files. So fix it at the source. Redact tokens, passwords, keys and personal data in the application logger. Add a test that logs a fake secret and checks it does not appear.
Make logs useful for investigation
The same page recommends correlation IDs, structured formats, context enrichment and agent health reporting. Correlation IDs let you follow one request across services, which matters when responding to an incident. See correlation and trace IDs in investigations.
What a broker does not give you
The cheat sheet says a broker alone does not prevent log loss or denial of service. A flood of noisy logs can still fill disks, delay delivery or push out the events you need. Add quotas per producer, alert on agent silence, and keep a separate path for the audit events that must not be lost.
Checklist
- Separate topic and credentials for security events.
- mTLS from agent to broker.
- Publish-only rights for agents.
- Redaction in the application and a test for it.
- Alerts when an agent or a service stops sending.
- Retention set by data sensitivity, not disk size.
For the broker side, see Kafka ACLs for producers and consumers.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can the agent filter out secrets for me?
Not reliably. The OWASP sheet notes agent-side filtering cannot clean data already written locally, so redact in the application.
Does a broker guarantee no log loss?
No. OWASP says a broker alone does not prevent log loss or denial of service.
Sources
Last reviewed: 19 October 2026.
