OpenBao audit devices and logging

Why OpenBao audit devices and logging matter for your secrets program

OpenBao audit devices record the requests made to the server and the responses it returns, so your team can later show who accessed which secret, when, and through which path. A security or platform team needs them as soon as the secrets program must answer those questions for an auditor, an incident responder or an internal control owner. The trail only covers the period in which an audit device was enabled, so the decision to turn logging on belongs in the first production design, not after the first investigation.

Audit devices are configured per cluster. OpenBao supports file, syslog, socket and HTTP destinations, and most teams forward the resulting logs to a SIEM where security analysts can search, correlate and alert on them. Each destination brings its own owner, storage location, permissions and failure behavior. Before you enable anything, list who will read the logs, where the SIEM receives them, how long they must be kept, and which team controls the hosts that hold them. Those answers shape which destinations you use.

An audit device that cannot write its log can cause OpenBao to stop serving requests, so the logging design is also an availability decision. Running more than one audit device lets requests continue if one destination fails, but that choice needs its own monitoring, capacity planning and test. Ask your platform team to confirm how the log path behaves when a SIEM connection drops, when a disk fills, and when a syslog target restarts, and record the result before go-live.

DeployOpen configures and documents audit devices and log forwarding inside your own infrastructure, including the destinations, the SIEM handoff and the runbooks your operators will follow. We prepare the configuration and evidence that your compliance team needs, but we do not issue audit reports or attestations. Those come from independent auditors and certification bodies. Confirm with your assessor which records they expect, how long your SIEM must retain them, and which fields must be HMAC-hashed before they leave the cluster, so the scope is agreed in writing before work starts.

Choosing between file, syslog, socket and HTTP audit devices

This table compares the four OpenBao audit device types by where they send audit entries, who runs the receiving side and the situations where each one fits. Read each row as a decision: the typical use points to the destination, and the operations column shows what your team must keep running. Use the final column as a checklist before enabling a device, because option names, transport settings and failure behavior should be verified against the OpenBao documentation for your version.

Device type	Typical use	What operations must run	Confirm in the OpenBao docs before choosing
File	Writing entries to a local file on each OpenBao node, usually read by a log shipper.	Log rotation, disk space monitoring and a collector that reads and forwards the file.	File path and permissions, how rotation is handled and behavior when the disk fills.
Syslog	Sending entries to an existing syslog service that already feeds central logging.	Syslog receiver or relay, its retention settings and monitoring for dropped messages.	Supported transports and facilities, tagging options and whether delivery is acknowledged.
Socket	Streaming entries to a TCP or UDP listener that your team operates.	A listener that stays available, its own access controls and capacity planning.	Supported address formats, reconnect behavior and whether writes block when the listener is unavailable.
HTTP	Posting entries to an HTTP endpoint, such as a webhook receiver or a SIEM collector with an HTTP input.	The receiving service, its certificates and authentication, and the secrets used to reach it.	Request format, header and TLS options, retry behavior and failure handling.
Two or more devices	Enabling more than one audit device so one device failure does not block requests.	Alerting on every enabled device and testing how failures are handled.	Whether OpenBao keeps serving requests when one device errors, and the exact condition that triggers this.
SIEM forwarding	Shipping HMAC-hashed entries to a SIEM so sensitive values stay hashed in the logs.	Forwarder, parser for the audit format and the process for handling HMAC key material.	Which fields are hashed by default, how HMAC settings are configured and how hashes can be verified.

Running two audit devices so one failure does not block requests

Enabling two audit devices is a way to keep requests flowing when one log destination stops accepting writes. The central design question is what OpenBao does when a device cannot record an entry, because that behavior determines whether a second device protects availability, auditability or both. Confirm the failure behavior for each device type in the official OpenBao documentation for your release, and record the answer in your design file before you build.

When you design the layout, consider these points:

Destinations: choose two devices with separate failure domains, such as a local file on one host and a socket or syslog path that forwards to a collector.
Independent paths: avoid placing both devices on the same disk, volume or network route, since one shared fault could disable both.
Hashing: decide which fields are HMAC-hashed before entries leave the node, so both devices receive protected records in a consistent form.
Ownership: name the team that owns each destination, along with its retention period and access controls.
Illustrative example: a team might write a local file for on-host recovery and send a second copy to a SIEM collector.

Before you finalize the layout, check the failure mode in the docs for each device type you plan to use.

How to enable and verify OpenBao audit devices step by step

This sequence takes an OpenBao cluster from no audit logging to a set of audit devices, each confirmed to record a test request at its destination. Run it on a non-production cluster first, then repeat it on production under your change process. Confirm every command and flag against the OpenBao documentation for your exact version before you run it.

Decide destinations, retention and ownership
The platform or security team decides which audit devices will run, where each one writes, how long entries are kept and who reads them. A common pattern pairs a local file for on-host review with a syslog, socket or HTTP path that forwards entries to a SIEM, but confirm which device types your version supports in the OpenBao audit documentation. Write the retention rule down before enabling anything, because it drives disk sizing and the volume sent to the SIEM. This step is done when each destination has a named owner and a retention period agreed with the teams that consume the logs.
Prepare file paths and receivers with correct permissions
The operator creates each file path, socket or receiving endpoint and sets ownership so the OpenBao service account can write to it and other local users cannot read or alter entries. For file devices, confirm the directory exists, the service user owns it and the permissions are restrictive. For syslog, socket and HTTP destinations, confirm the receiver accepts connections from the OpenBao hosts and that network rules allow the traffic. Check ownership by listing the path as the service user, and send a test write where the receiver supports one. This step is done when the write succeeds and the receiver shows the connection.
Enable the first audit device
Using the OpenBao CLI or HTTP API with an operator token that carries audit administration rights, enable the first device and point it at the path or receiver prepared in the previous step. Options differ by device type and version, so take the exact syntax from the OpenBao docs for your release. Then read the list of enabled audit devices and confirm the new entry shows the expected type, path and options. This step is done when the device appears in the list and the enabling call returns no error.
Add a second device for redundancy
Enable at least one more audit device that writes to a different destination, so the cluster has a fallback path. Before relying on this design, check the OpenBao docs for your version to see how the server behaves when an audit device fails, since that behavior determines whether requests are blocked. Read the device list again and confirm both devices are present and that neither was disabled during the change. Record which device is primary, which is secondary and who is alerted if either stops writing. This step is done when both devices are listed and the failure behavior is documented.
Generate a test request and locate the entry
From a known client, send a harmless read request to the cluster, such as a lightweight lookup on a test identity, so the entry is easy to find. Note the time of the request and any request identifier returned. Open the file or receiver output and locate the entry for that request. Confirm the entry is structured and that sensitive values appear as HMAC-hashed values. Confirm which fields are hashed in your version, because the default set may differ from what your SIEM expects. This step is done when you can find the entry for the test request in each destination.
Confirm arrival at the SIEM and every destination
Check the downstream side. The SIEM or log platform should show the test entry through the ingest path you designed, with fields parsed as expected. If your change process allows it, make one device deliberately unavailable in a controlled window and repeat the test request, then confirm the remaining device still records it and that requests behave as the documentation describes. Restore the device afterward and confirm it resumes writing. Record the results in the change ticket. This step is done when every destination and the SIEM show the test entry and the failure test matches the documented behavior.

Forwarding HMAC-hashed audit logs to a SIEM such as Wazuh or Graylog

The decision that matters here is how audit entries leave the OpenBao host and reach a system your security team can search and alert on. OpenBao hashes sensitive values with HMAC before they are written to an audit device, so the SIEM receives hashed entries rather than plain secret values. Analysts can still match repeated values across entries because the same key produces the same hash, but they cannot read the secret itself. Confirm in the OpenBao audit documentation which fields are hashed for each request type, and confirm that your audit device settings keep that behavior. Your forwarding design should assume the SIEM will hold security-relevant metadata for a long time, so plan access and retention for it as deliberately as you would for the cluster.

Three forwarding paths are common, and each one places work on a different team. With the file device, a log shipper or agent on the OpenBao node reads the file, so you must plan file permissions, rotation and what happens to the shipper if it falls behind. With the syslog device, OpenBao sends entries to a syslog listener, so the transport, its reliability and its message size limits become your concern. With the HTTP device, OpenBao posts entries to a receiver endpoint that you operate, so the receiver's availability and its handling of request failures directly affect audit delivery. Whichever path you choose, verify that a stalled SIEM does not stop OpenBao from serving requests, which connects to the multiple-device design covered elsewhere on this page.

Wazuh is distributed under GPL-2.0 with an exception that permits linking with OpenSSL, which many security teams review with counsel before adoption. Its agents run on Linux, Windows and macOS, and it collects syslog from agentless sources, so the syslog device is the most direct fit. Wazuh analyzes incoming data with decoders and rules, and its dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. You will likely need a custom decoder and rules for OpenBao's log structure, so ask your Wazuh contact or test with sample entries to confirm the current parsing for the OpenBao log format before you commit to this path. Plan an owner for those rules, because they change when the audit format changes.

Graylog Open ingests syslog, GELF and Beats inputs, and it rotates indices by message count, size or time, deleting the oldest indices under your retention setting. Its Open edition is licensed under SSPL-1.0, which is not an OSI-approved license, so the license review will differ from the one for Wazuh. According to Graylog's pricing page, Graylog Open is free with no volume limits and community support, while Enterprise and Security tiers are paid and start at stated annual amounts with a minimum daily volume. Graylog also needs MongoDB and a search backend, and the Graylog system architecture page advises sizing log storage as daily ingest multiplied by retention days and then by 120 percent. Measure your OpenBao audit volume before you size anything, and confirm current compatibility and parsing for the OpenBao format with Graylog.

Choose between the two by weighing license terms, storage sizing and staffing together. Legal review will decide whether the GPL-2.0 exception or the SSPL-1.0 terms fit your policies. Storage depends on measured audit volume, retention requirements and, for Graylog, the message journal sizing that the architecture guidance describes. Staffing decides who upgrades the search backend, maintains parsing rules and responds when forwarding fails, and Graylog's multi-node guidance and Wazuh's server cluster option both add operational work. Before go-live, run a test that sends a known request through each device, confirm the SIEM shows hashed values, trigger a delivery failure to see what your team sees, and record the owners for each step. Quotes for implementation work should follow a written scope that names the chosen path, the SIEM version and the test plan.

Protecting audit logs and keeping secret values out of them

An audit trail is only useful if it is complete, readable by the right people and unchanged. The cards below cover the file, network, SIEM and people controls that keep OpenBao's audit output trustworthy, plus the checks that show when a write has failed or a log has gone missing.

Protect file audit device paths

A file audit device writes to a path on the OpenBao host, so the operating system account that runs OpenBao needs write access while other local accounts should not be able to read, append to or delete entries. Check the owner, group and mode of the log directory and of each rotated file. Confirm that log rotation keeps the same ownership, so a rotated file does not become unreadable to OpenBao or readable to everyone. Confirm the exact requirements for your service manager and file system against the OpenBao documentation for your version.

Protect syslog and HTTP transport

Syslog and HTTP audit devices send entries across the network, so the path between OpenBao and the receiver must resist interception and tampering. Use TLS for HTTP audit destinations and confirm that the receiver validates the certificate chain. For syslog, check whether your chosen transport supports TLS end to end, and whether any relay between the host and the collector preserves that protection. Test the connection with an untrusted certificate to confirm that the failure is visible.

Control SIEM read access

The SIEM stores the hashed audit trail and its own records of who searched, exported or changed it. Restrict read access to named roles, sign in through your identity provider where the SIEM supports it, and log administrative changes such as new inputs, index changes and deleted saved searches. Give the forwarding account permission to write to its own input only, so a compromised forwarder cannot read other log sources.

Separate operators from audit readers

People who administer OpenBao policies, audit device settings and recovery procedures should not also be the people who read or alter the audit trail. Map each duty to a separate group in your identity provider, grant SIEM read access only to an audit group, and record who can change audit device configuration. Agree in advance how an administrator's own activity is reviewed, and confirm that your recovery procedures do not give one person both operator and reader access.

Monitor failed or missing audit writes

OpenBao depends on audit devices accepting entries, so a device that stops writing needs to be noticed quickly. Alert on audit device errors in OpenBao's own logs, and alert in the SIEM when a host or source stops sending for longer than your agreed tolerance. Test both alerts by making a device path unwritable in a non-production cluster. Confirm with the documentation for your version how OpenBao behaves when one device fails and others succeed, and whether it blocks requests when every device fails.

Retain, delete and back up logs

Set one retention period that matches your legal and contractual obligations, and apply it to the live file, the SIEM index and every backup. Deletion should be documented and carried out by a named role. Back up the log directory, the SIEM storage and the forwarder configuration, store backups under the same access restrictions as the live trail, and keep integrity checks so an altered copy can be detected. Test a restore in a separate environment and confirm the restored trail is still searchable. Ask your compliance advisor which retention periods apply to you.

How to test that HMAC hashing and log flow work before go-live

Before go-live, test four things: that known requests produce audit entries, that sensitive values appear only as HMAC-hashed values, that entries reach the SIEM and parse correctly, and that the platform behaves as designed when one audit destination fails. Start by writing a short test matrix that names each test, the request or condition that triggers it, the expected result, and the evidence you will keep. Use test secrets with a unique, recognizable marker string in each one, so that a plaintext leak can be found by searching the raw log files and the SIEM. Send the requests through the same paths your production clients use, such as a key/value write, a read, a dynamic credential request and a failed login.

For the HMAC test, search every enabled audit device's raw output for the marker strings. None of them should appear in plaintext. Then confirm that the secret values appear as HMAC-hashed strings in the fields the documentation describes. Also check which fields remain unhashed, such as request paths, operation types and entity identifiers, and confirm with your data classification owner that those fields are acceptable to store and forward. Review every setting that changes hashing behavior, including any option that disables hashing for a device, and confirm that none is set in your configuration. The expected outcome for each check must come from the OpenBao documentation for the exact version you run, because hashing behavior and the options that affect it can change between releases.

For the SIEM test, confirm that each test event arrives at the SIEM within the delay your team has agreed to accept, that the fields parse into the expected schema, and that a field the parser expects is never silently dropped. If the forwarding path uses Graylog, check that the input (for example syslog, GELF or Beats, depending on the forwarder) receives the messages, that streams route them to the right destination, and that extractors produce the fields your searches use. If the SIEM is Wazuh, check that its decoders and rules match the entries. Confirm that the HMAC values are stored as text and are not altered or truncated by a pipeline step that was written for plaintext fields. Run this test with a sample of each request type, not only the simplest one.

For the failure test, take one audit destination offline in a non-production cluster, for example by stopping the receiving service or blocking the socket or syslog target, and then send the same set of test requests. Observe three things: whether requests continue to succeed while another audit device is healthy, whether OpenBao reports the failed device in its own logs or status, and whether your monitoring raises an alert. Then test the case where every audit device is unavailable, and confirm from the documentation for your version how OpenBao handles requests in that state. Restore the destination and check whether a gap appears in the SIEM and how your team would detect and document it. Ask the operations team to confirm that the alert reaches a person who can act on it.

Record the results as evidence for internal review. For each test, keep the test identifier, the OpenBao version, the date, the configuration reference, the operator, the documentation section used for the expected outcome, the observed result, a pass or fail decision, and redacted sample entries. Store the records where the security and compliance teams can read them. These records show what your team tested and what it found, but they are not an audit and do not establish compliance with any framework. Independent auditors and certification bodies make that determination. Repeat the affected tests after every upgrade, change to an audit device, or change to the SIEM pipeline, so the evidence matches the environment that is running.

What to confirm in your environment before you rely on audit logs

Audit logs are only as useful as the environment that produces and stores them. The items below mark where OpenBao behavior, storage, time sources and SIEM choices meet, and each one needs a check in your own cluster before an investigation or compliance review depends on it. Each card names who should confirm it.

OpenBao version and edition

Confirm which OpenBao version and edition each node runs, and whether that release line is the one your team plans to support. Audit device behavior, log fields and HMAC handling can change between releases, so record the exact version on every node and compare it with the release notes before you write SIEM parsing rules. The OpenBao documentation and release notes are the reference for this check, and your platform team owns the version inventory and upgrade plan.

Audit device behavior under failure

Confirm how your version responds when an audit device cannot write, including whether requests are blocked when a device fails and whether other enabled devices keep recording. This behavior drives the design of the device set, so verify it on your own release instead of assuming it from another version. Check the OpenBao audit documentation for your release, then run a controlled device failure in a non-production cluster and record what happens to client requests and to the log trail.

Log volume and storage sizing

Confirm the expected audit log volume per day and the retention period your policies require, then size storage separately for the local file or socket target and for the SIEM. Each request and response produces audit entries, so volume follows traffic and the number of enabled devices. Your team sets the retention requirement and measures real traffic in a pilot. The SIEM vendor documents its own indexing and storage requirements, which you should request before you size the platform.

SIEM support for the log format

Confirm that the SIEM parses the audit format your devices emit, including the JSON field structure and the HMAC-hashed values OpenBao writes in place of raw secret data. Hashed values can only be matched when the same HMAC key and salt are in use, so test a known search and a known alert against sample entries before rollout. The OpenBao documentation defines the format, and the SIEM vendor confirms parser and field mapping support.

Clock synchronization across nodes

Confirm that every OpenBao node, standby node and log forwarder keeps time from a synchronized source your team controls. Audit entries carry timestamps, and clock skew between nodes makes event ordering unreliable during an investigation and can break correlation across devices. Your platform team owns the time service configuration and drift monitoring, and should check each host, including standby nodes, before the SIEM correlates events from the cluster.

SIEM license fit with policy

Confirm that the license of the chosen SIEM fits your internal policy before you build on it. Licenses differ in how they treat modification, redistribution and hosted use. Graylog Open, for example, is licensed under SSPL-1.0, which is not an OSI-approved open source license, while Wazuh is distributed under GPL version 2 with an OpenSSL linking exception. Your legal and procurement team owns this review, using the license file in each vendor's repository as the starting point.

What buyers ask about OpenBao audit logging cost, time and effort

How much does OpenBao audit logging setup cost?

Setup cost depends on scope, and the SIEM license is a separate line. A quote covers DeployOpen's fixed-scope work to configure the audit devices, connect them to your SIEM, test failure behavior and write the operating documentation. Your infrastructure costs and any SIEM subscription are paid to other parties. For Graylog, the Graylog pricing page lists Graylog Open as free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. These tiers are licensed on processed data with no per-user or per-device fees. Ask for the services quote and the SIEM subscription as separate items.

What drives the scope and price of OpenBao audit logging work?

Scope is the main driver, followed by SIEM integration and the number of clusters. Each audit device you add, whether file, syslog, socket or HTTP, adds configuration, permissions and a test case. Running more than one device so that a single audit failure does not block requests is a design decision with its own testing. Forwarding HMAC-hashed logs to a SIEM requires parsing, field mapping and alert rules built around that format. Every additional cluster multiplies configuration and verification work, and the documentation grows with each environment. Ask the vendor to list destinations, clusters and SIEM use cases by name so each one is priced and tested explicitly.

How does log volume affect Graylog sizing and licensing for OpenBao?

Log volume sets SIEM sizing, and sizing drives infrastructure cost. Graylog's system architecture guidance advises sizing log storage as daily ingest multiplied by retention days, then multiplied by 120 percent. It also advises giving the message journal 3 to 5 times the daily ingest on SSDs. Measure daily OpenBao audit volume on a test cluster before you size anything, because the formula is only as accurate as the input. Volume also affects licensing, since Graylog's commercial tiers list a minimum of 10 GB per day or 100 Graylog Compute Units. Ask any partner to state its sizing assumptions in the quote so you can check them against your own numbers.

How long does OpenBao audit logging setup take?

Duration depends on the same drivers as cost, so no fixed number applies here. A single cluster with one file device and one SIEM destination takes far less work than several clusters with syslog, HTTP and socket devices feeding a SIEM that needs custom parsing. Time also depends on how quickly your team approves change windows, provisions SIEM nodes and confirms retention. Graylog's multi-node guidance for medium to large deployments includes three Graylog and MongoDB nodes, three Data Nodes and a load balancer. Provisioning that infrastructure can lengthen the lead time before testing starts. Ask for a timeline tied to written milestones in the agreed scope.

Can our internal team set up OpenBao audit logging by itself?

An internal team can do it alone if it has OpenBao, SIEM and change-control skills available. The work spans the OpenBao audit devices, high availability behavior, the SIEM cluster, parsers and alerting, and documentation that a security reviewer or auditor will read. The SIEM side often needs the most coordination, because indexing, retention and access rules need a named owner. Check whether the people who will run OpenBao and the SIEM after go-live will also build it, and whether anyone has tested what happens when an audit device fails. A partner adds capacity and an independent review, but it does not replace an internal owner after handover.

What must we provide before OpenBao audit logging work starts?

You provide access, a SIEM owner and retention decisions before build work starts. Expect to supply administrative access to the OpenBao clusters and the target SIEM environment, or a named operator who runs commands with the implementation team. Name a SIEM owner who can approve index settings, user access and alert routing. Retention for each log category should be decided with your legal, compliance and security leads, because those rules set storage size. Also provide network paths between the clusters and the SIEM, change windows and a test plan agreed with operations. Unresolved decisions on retention and ownership tend to pause work, so settle them first.

Does DeployOpen provide audit reports for OpenBao logging?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies produce those documents after they test your environment. DeployOpen can deliver the configuration, documented audit device settings, test records of failure behavior and SIEM alert logic that your assessor can review. Ask your auditor which evidence they expect before the work is scoped, because their requirements determine what should be collected and retained. Be cautious with any provider that offers to produce an audit report on its own.

What does a fixed-scope quote for audit logging cover?

A fixed-scope quote covers the scope, deliverables and timelines agreed in writing before work starts. Most DeployOpen engagements are fixed-scope, and the quote follows from that written scope. Ask for the list of audit devices, clusters, SIEM integrations and test cases included, along with the documentation and handover items. Check what is excluded, such as SIEM licensing, hardware, storage expansion or follow-on support. Ongoing support, upgrades and continuous testing are available as retainers and are quoted separately from the initial build. Ask how changes to scope after signing are handled and priced.

How DeployOpen scopes and delivers OpenBao audit logging

DeployOpen plans OpenBao audit devices and logging as part of your own infrastructure, so audit records stay in environments you control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

The written scope lists which audit devices, such as file, syslog, socket or HTTP, your clusters will use.
Scope names log destinations, the retention owner, the SIEM receiving audit events and HMAC handling.
Scope covers cluster sizing, failure behavior and who approves changes to audit configuration.

How we build

Configure at least two audit devices per cluster so one failing device does not block requests.
Forward logs to the SIEM over an agreed transport, keeping HMAC-hashed values in forwarded records.
Test each device with failure injection in a staging cluster before production cutover, and record results.

How we hand over

Runbooks for enabling, disabling and rotating audit devices, plus the steps for responding to failures.
Documented evidence of configuration and test results, prepared for your compliance assessor to review.
Knowledge transfer sessions with the platform, security and SIEM teams who will operate the audit pipeline.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review audit device health and SIEM ingestion when OpenBao versions change, before upgrading the cluster.
Confirm support hours, response expectations and SIEM licensing terms in your written scope.