Getting Tuft Mesh Vault audit logs into your SIEM

The audit log is one of the more useful outputs of a service mesh, and also one of the more commonly ignored ones until a security team asks for it. Tuft Mesh Vault writes a structured JSON event for every policy change, certificate rotation, and routing update. Getting those events into a SIEM is straightforward, but the right approach depends on what your SIEM ingestion pipeline looks like.

Output modes ¶

The audit log supports three output modes: stdout, a local file path, and a Unix domain socket. Stdout is the default and works well if you are already running a log shipper (Filebeat, Fluentd, Vector) that tails container or process stdout. The file output writes to a path you specify, with optional log rotation settings. The Unix socket output is for cases where you want a custom consumer. A small daemon that reads events and forwards them with additional context.

All three modes write the same JSON schema. The event_type field is an enum with a defined set of values, so you can write reliable parsing rules without worrying about schema drift between versions.

Elastic Stack ingestion ¶

If you are using the Elastic Stack, the straightforward path is Filebeat tailing the audit log file (or stdout via the container log path) with a JSON codec. The event schema maps cleanly to Elastic Common Schema fields: occurred_at maps to @timestamp, actor maps to user.name, source_ip maps to source.ip, and event_type maps to event.action. A sample Filebeat configuration is in the docs.

For teams using Elastic Security, the policy decision events (event_type: policy.allow and policy.deny) are the most useful for building detection rules. A spike in policy.deny events from a specific source workload is a reasonable signal for an anomaly alert.

Splunk ingestion ¶

For Splunk, the Universal Forwarder monitoring a file input is the standard approach. The JSON events index cleanly with sourcetype=_json. The event_id field (UUID v4) is useful as a deduplication key if your forwarder configuration might deliver events more than once. A sample inputs.conf stanza is in the docs.

The full audit log schema reference, including all event_type values and their payload shapes, is in the docs under 'Audit log'. If your SIEM uses a different ingestion path, the community forum has threads covering several other platforms.