OpenSearch audit logging: what it records and when your team needs it
OpenSearch Security provides audit logs as part of its access control features, and this page explains how to enable them, which categories and storage targets to choose, and how to keep audit records outside the cluster they describe. It is written for regulated and security-conscious teams that run OpenSearch and must show who accessed or changed data. If your current answer depends on application logs or on someone's memory of a change window, the gap is worth closing before an incident, a customer dispute or an auditor forces the question.
Teams usually need audit logging for three kinds of request. The first is an access investigation, where security staff must establish which user or service account read, searched or modified an index during a given window. The second is change tracking, where the team must show who altered security roles, index settings or cluster configuration. The third is an internal or external audit request, where a reviewer asks for evidence that access was recorded and that the records are intact. Audit logs only answer these questions if the relevant events were enabled before the activity happened. Audit logging is one control among several, alongside access control, encryption, backups and change management. On its own it does not make a system compliant, and an auditor will judge the whole control set.
The OpenSearch Security plugin is licensed under the Apache License 2.0, like the rest of the OpenSearch project, and the OpenSearch FAQ does not describe a paid edition. The direct cost of audit logging is therefore your team's effort and the infrastructure that stores the logs, not a license fee for the feature. Design and testing are largely one-time costs, while storage, retention, review and upgrade checks recur. Storage grows with the categories you enable and with event volume, so the category decision is also a budget decision. When you request a quote from a partner, ask who configures categories, who builds the log shipping and retention, and who verifies records after each upgrade. Confirm the same questions with your own platform team before committing.
Before enabling anything, make four decisions in writing. Choose the event categories that match your investigation and audit questions, and document what you will not record and why. Choose the destination for records. A separate store that cluster operators cannot silently edit is the usual starting point, and you should confirm which storage targets your OpenSearch version supports. Set retention from your policy and legal obligations, then check it against available storage. Name the people who review the logs and how often. Finally, test on a non-production cluster: generate a known login, a role change and a read, and confirm that each appears in the destination with the expected user and timestamp.
The most common failure is keeping audit records on the cluster they describe. An administrator with broad rights, or an attacker who gains them, can then alter or delete the evidence along with the activity. Move records to a destination with its own access controls and retention, and limit who can administer that destination. Also plan for sensitive content, because audit records can capture request details. Confirm what your version logs and who can read the audit store. Verify after every OpenSearch upgrade, since a changed setting or plugin behavior can quietly stop events from being recorded. Add a recurring check that records still arrive.
Audit logging options and when each fits
This table compares the three decisions behind OpenSearch audit logging: which event categories to record, how verbose to be, and where records go. Read each row as a choice you make for your own risk profile, then confirm the setting names and defaults in the OpenSearch Security documentation for your version before committing.
| Decision option | What it is for | Cost in storage and review effort | What to confirm in the docs |
|---|---|---|---|
| Failures and configuration changes only | Catches failed logins, denied access and changes to security settings with the smallest record set | Low storage growth; review is focused, but routine successful access is invisible to investigators | Which failure and configuration events are categorized, and how they are named |
| All requests recorded | Full reconstruction of who read or changed what, useful for forensic investigations and assessor sampling | Highest storage growth and noise; reviewers need filters or detection rules to find anything | Whether request body content is logged, and the performance impact on your node count |
| Authentication events in scope | Shows sign-in activity across SAML, OIDC, LDAP and other configured backends | Moderate growth; review effort rises if many service accounts authenticate frequently | Which authentication backends emit audit events and whether successful logins are included |
| Local log file on each node | Simplest destination; keeps audit output close to the node that produced it | Little extra infrastructure, but each node holds its own records, so review means collecting files from every node | Log file path, rotation settings and whether records survive node loss |
| Separate audit index in the cluster | Keeps audit records queryable in Dashboards without a new tool | Adds index storage and retention to the same cluster it describes, so a cluster failure can take the evidence with it | Index name, retention method and whether the audit index is protected from the users it records |
| External collector or SIEM | Keeps records outside the audited cluster and supports central alerting and long retention | Adds collector infrastructure and licensing or operating cost for your chosen tool; forwarding failures need monitoring | Supported output configuration for your version and how delivery failures are reported |
| Version-specific settings | Ensures category names, destination options and defaults match the release you run | Changes between minor versions can alter what is recorded, so each upgrade needs a repeat check | The audit logging page for your exact version and its release notes |
Enabling audit logging on a self-managed cluster
This sequence takes a self-managed OpenSearch cluster from unconfigured audit logging to verified records in a destination outside the cluster. It runs in six steps: confirm the environment, define what is captured, apply the settings, generate known events and check their fields. Exact file names, setting keys and reload steps depend on the version, so take them from the security docs for that release.
Confirm the version and install method
The engineer making the change records the exact OpenSearch version and how the cluster was installed: Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian, Ansible or Windows. The install method determines where configuration files live, how settings are applied and whether a restart runs as a rolling process or a container redeploy. Audit setting names and reload behavior can differ between releases, so open the security docs for that exact version before editing anything. Done when the version reported by the cluster matches the docs you are following and the team agrees on the configuration path for each node.
Confirm the Security plugin and TLS
Check that the Security plugin is installed and initialized on every node, and that TLS is active for node-to-node and client traffic. Audit logging is a feature of the Security plugin, so a node where the plugin is disabled or partly configured will not produce the records you need. Confirm that an administrative user can authenticate over HTTPS and that each node answers a health request. Done when every node reports the same security configuration and an administrative session succeeds. Save the current configuration as a baseline so you can roll back if the change misbehaves.
Define audit categories and storage target
Decide which event categories to capture, such as failed authentication, access to indices, and changes to security configuration. Then choose the storage target: a dedicated index on the cluster, an external store, or a log destination that your logging platform collects from. Tie each category to a stated purpose so event volume stays manageable. Use the category and destination names listed in the security docs for your version, and record them in a change record. Done when the change record lists each category, its purpose, the chosen destination and the team that owns that destination.
Apply the audit settings and reload
Apply the audit configuration through the mechanism your install method uses, then follow the reload or restart procedure the security docs specify for that version. Some changes load through the security configuration tooling and others need a node restart. Where the procedure allows, change one node first and check its logs for a message showing the audit configuration loaded and for any startup errors before continuing. A rolling restart keeps the cluster available while nodes cycle. Done when every node reports the audit configuration loaded and the cluster returns to its prior health state.
Generate test events for each category
Produce a known set of events in a test environment or on a dedicated test index so business data is not affected. Run one failed login with a wrong password, one read of the test index by a user who has access, and one role or user change made by an administrator. Write down the time, username and action for each event so you can match it later. Done when you have a written list of the three actions with timestamps, which becomes the expected-results list for verification.
Verify each record and its fields
Open the chosen destination and confirm that each test action produced a record. Check that the fields the security docs list for each category are present, including the user, the origin address, the action or request, and the timestamp. Compare every record against your written list. Confirm that records reach a destination outside the audited cluster, because a log kept only on the cluster it describes may be lost along with that cluster. Done when all three events appear, field values match and the destination owner confirms receipt. Keep the test records as evidence for the change.
Keeping audit records outside the cluster they describe
Audit records kept only inside the cluster they describe are weak evidence. Anyone who gains administrative control of that cluster can also change, delete or silence its audit output, and a misconfiguration that rewrites index settings or retention can do the same without any attacker involved. When an assessor or incident responder asks whether the records are complete and unaltered, a copy the audited team controls alone does not answer that question. The design task is to decide where a second, independently controlled copy lives, who can reach it, and how long it is kept.
The first option is to ship audit records to a separate log store or SIEM that the audited cluster's administrators cannot write to or delete from. This gives the strongest separation, because the destination belongs to another system with its own accounts. The trade-offs are latency, since records arrive after a delay that depends on the forwarding path, and operational load, since someone must own the forwarder, watch for dropped or backlogged events, and handle buffering when the destination is unavailable. Ask who will be paged when delivery stops, and how the audit trail shows any gap that results.
The second option keeps records in an index or destination inside OpenSearch, but restricts access to a different admin group. The OpenSearch Security plugin provides role-based access control, so the audit index can be read only by roles held by a separate team. The limit is that the copy still sits on the same nodes, and anyone with cluster-level administrative rights may be able to reach or change it, depending on how roles and certificates are assigned. Confirm in your environment which accounts hold cluster-wide privileges, and test whether those accounts can read, modify or delete the audit index.
The third option is to retain copies under the organization's retention policy, typically as snapshots written to a repository that the audited cluster's operators cannot overwrite. Snapshots are cheap to schedule and suit long retention, but they are periodic, so events between snapshots exist only in the live cluster until the next one runs. Restoring them also takes planning and tested procedures. Verify that the snapshot repository has its own access controls and that someone has restored a sample set end to end before relying on it.
The replication or transport mechanism for each option must be confirmed for the chosen OpenSearch version and your environment, because forwarding behavior, supported destinations, and snapshot repository types depend on the release and deployment method. Before go-live, run a tamper test with a cluster administrator account, check that event counts match between the source and the separate store, and document the gap window and the recovery steps. Those results, not the design diagram, are what an auditor or incident responder will ask to see.
Security and operational considerations for audit logs
Audit logs are only useful if the pipeline that produces and stores them can be trusted. The cards cover how to protect the audit path, keep events correlatable across nodes, and make sure writes and records survive routine operations. Check each point against your own cluster layout and retention rules before you enable categories.
Encrypt node and client traffic
The OpenSearch Security plugin provides TLS for node and client traffic. Audit events record who touched data and settings, so transport between nodes and from clients should be encrypted before any audit category is enabled. Confirm that transport and HTTP certificates come from your own certificate authority, that rotation is scheduled, and that every component that writes or reads audit data verifies those certificates.
Restrict audit settings and reads
Role-based access control decides who can change audit configuration and who can read audit records. Limit the role that controls audit settings to a small, named group of administrators. Give analysts read access to audit indices through roles scoped to those indices only. Review role mappings after each change, because a broad admin mapping lets someone disable the logging that an investigation would later need.
Protect forwarder credentials
When audit records are sent to an external store or log pipeline, the account that forwards them holds credentials that can read or write sensitive events. Give the forwarder its own least-privilege user, keep its password or certificate in a secrets manager, and rotate it on a schedule. Confirm that a leaked forwarder credential cannot delete or alter records already stored outside the cluster.
Synchronize clocks across nodes
Events from different nodes are correlated by timestamp, so clock drift makes it hard to reconstruct the order of actions. Run a time synchronization service on every cluster node and on each forwarder host, and monitor clock offset as a health check. Confirm which time source your organization treats as authoritative and that stored records use one consistent time zone and format.
Plan disk capacity for audit writes
Audit writes compete with indexing and search for disk space. If a node runs out of space, audit events can be lost or rejected without an obvious error, and the gap may only surface when someone searches for a record. Size audit storage from the volume you measure after enabling categories, set alerts well before disk-full thresholds, and test what happens when a disk fills in a non-production cluster.
Include audit storage in restore tests
Audit records are only evidence if they can be recovered. Add the audit indices and the audit configuration to your backup schedule, then run restore tests that confirm records are readable, complete for the expected date range and attributable to the expected sources. Document the retention rule each backup applies so that expired records are removed by policy and any gap can be explained.
Running audit logging through upgrades and version changes
Audit logging needs to be checked again with every upgrade. The settings that enable audit logging, the event fields each record carries and the categories that decide what gets recorded can all change between OpenSearch versions. Treat every minor and major upgrade as a change to your audit output as well as to the search cluster. Before the upgrade, record the current audit settings, a sample of audit records and the category list your monitoring depends on. After the upgrade, compare them against the release notes and the documentation for the target version, and confirm each setting name and field name there. A field that a SIEM parser or a retention rule depends on is the one most likely to be renamed or moved without anyone noticing.
The release model sets how often that check happens. OpenSearch targets a new minor version about every eight weeks, and the releases page lists 3.8.0 on August 4, 2026 and 3.9.0 on September 29, 2026 as examples of that cadence. Each version stays under maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, a version receives bug fixes and security patches but no new features. A maintenance patch is therefore the lower-risk step, since it is not expected to add features, though you should still read its release notes for audit-related changes. A minor or major upgrade is where audit changes are most likely, so it needs the full verification described below.
The test plan for any upgrade should include one check that matters more than the rest: audit records still reach the protected destination. In the upgraded test cluster, generate known events such as a failed login, a permission change and a read of a restricted index, then confirm that each record arrives at the external store with the expected fields and timestamps. Confirm that the store blocks writes or deletes from the cluster's own administrators where your design says it should, and that the transport from the cluster still uses the TLS configuration you rely on. Run the same check after a rollback test, because a stopped audit pipeline may not appear in ordinary cluster health views. Record the results as evidence for the change.
Choose the upgrade path with that check in mind. OpenSearch documents four methods: rolling upgrades, snapshot and restore, remote reindexing and Migration Assistant. A rolling upgrade keeps the same cluster and its configuration, so audit continuity is easiest to verify on live nodes, but it works only from the source versions the documentation lists. Snapshot and restore and remote reindexing create or populate a new cluster, so the audit configuration must be applied and tested there before cutover, and the audit trail of the old cluster stays with the old destination unless you plan for it. Migration Assistant can move workloads across several major versions in one step and supports live traffic capture, which reduces downtime but means you must decide how audit records for requests captured during cutover will be verified. Confirm the supported version pairs in the migration documentation before you choose.
Turn this into three decisions before the upgrade window. First, name the owner of the audit verification step and make it a go or no-go item in the change record. Second, keep the audit configuration for each version in version control, so the target settings can be compared line by line with the current ones. Third, agree the retention period for audit records from the old cluster and where they will be searched after cutover. Ask your implementation partner, or confirm with the OpenSearch documentation for your target version, which audit settings and categories changed since your current version. Do not start the production upgrade until the destination check passes in the test environment.
Limits to confirm in your environment before you rely on audit logs
Audit logging only helps if the records exist, reach storage you control, survive failures and fit your retention plan. The checks below are the points to confirm in your own environment before you treat audit logs as evidence. DeployOpen prepares systems and evidence, but independent auditors decide whether the controls are sufficient.
Event categories and fields
Confirm which audit event categories your OpenSearch version records and which fields each event carries, such as the user, the source address and the target index. Category names and field layouts can change between releases, and OpenSearch targets a new minor version about every eight weeks, so check the documentation for the exact version you pin. Platform engineers should test each category you plan to alert on in a non-production cluster and keep the output as a baseline for future upgrades.
Storage target and its security
Confirm that the storage target you plan for audit records is supported for your version and how it is secured. Audit records should live outside the cluster they describe, so the target needs its own access controls, encryption in transit and a retention setting its owner can enforce. The security architect should review who can read, write and delete records there, and the platform team should verify the configuration against the documentation for that version before routing production events.
Behavior during node failure or partition
Confirm how audit records behave when a node fails, the network splits or the storage target is unreachable. Ask whether events are buffered, dropped or retried, and whether a partitioned node can keep producing records that later conflict with the rest of the cluster. The OpenSearch docs recommend dedicated cluster manager nodes and replicas on separate nodes, and those choices shape how much confidence the record set deserves. Platform engineers should run controlled failure tests and record what appears in storage afterwards.
Volume against disk and retention
Confirm that expected audit volume fits your disk and retention plan. Output depends on which categories you enable, how many requests your clusters serve and how many fields each event includes. Measure a representative load in a test environment, then size storage for the full retention period your auditors require, with headroom for growth and snapshots. Storage and operations owners should agree on these figures before enabling broad categories in production.
Auditor acceptance of the evidence
Confirm that your independent auditor accepts the format, retention period and chain of custody of the audit records as control evidence. The compliance lead should agree the evidence list early, including which events, which time range and which export method the auditor expects. DeployOpen can prepare systems, configuration and evidence for a compliance assessment, but it does not issue audit reports or attestations, and the auditor decides whether the controls are sufficient.
Questions buyers ask about OpenSearch audit logging
What drives the cost and effort of enabling OpenSearch audit logging?
The main drivers are how many clusters and environments need logging, which audit categories you enable, where the records go, and how much testing and documentation the change needs. Each node and environment adds configuration to apply, verify and keep consistent, so one development cluster takes far less effort than a production fleet with separate staging, disaster recovery and regional clusters. Broader category selection produces more records to store, search and review. Destination design adds work when records go to another cluster, object storage or a log platform, because each target needs its own access controls, retention settings and failure handling. Testing and documentation cover proving that events are written, that sensitive fields are handled as intended, and that operators can explain the setup to an auditor. Ask for a quote that lists each cluster, environment, category, destination and deliverable separately.
How long does it take to enable OpenSearch audit logging?
Timing depends on the number of clusters, the OpenSearch version and install method, how many destinations are involved, and how much change control your organization requires. A single lab cluster with one local destination is a short exercise, while a regulated production estate with staged rollouts, approvals and evidence collection takes considerably longer. Most work runs in phases: confirm requirements, configure in a non-production environment, test event capture and failure behavior, then roll out in a change window and document the result. Your change calendar and the availability of cluster owners often set the pace more than the configuration itself. Ask for a timeline in the written scope that names each phase, the environments included, and the dependencies on your team, such as access approvals and maintenance windows.
What must we provide before an audit logging engagement starts?
You need administrative access to the cluster or a non-production copy, the exact OpenSearch version, and the install method, such as Docker, Helm, the Kubernetes Operator, tarball, RPM, Debian packages or Ansible. Provide the retention requirements from your policy or framework, along with the auditor's expectations for who reviews logs and how long records must be kept. If audit records will leave the cluster, identify the destination and the team that owns it, including any log platform you already run. Share the existing security configuration, including TLS setup, authentication backend and role mappings, because audit settings interact with them. Name the people who approve changes and who will receive the documentation. Missing items usually surface as delays, so a checklist before kickoff pays off.
Can our internal team enable OpenSearch audit logging alone?
Yes, an internal team can enable OpenSearch audit logging alone if it has the security documentation for its exact OpenSearch version and a written test plan. Audit settings are configuration within the Security plugin, so the work is mostly planning categories, applying changes to each cluster and proving the output. Gaps usually appear in testing: confirming that the events you need are recorded, that they reach the destination, that access to them is restricted, and that a destination failure is detected. Teams working without a second reviewer often miss documentation steps, such as recording why a category was enabled or how records are retained. Outside help makes sense when you want an independent plan, have many clusters to change, or lack capacity during a change window. Either way, write the test cases before the first change.
Is the OpenSearch Security plugin free to use for audit logging?
The OpenSearch Security plugin is released under the Apache License 2.0, and all software in the OpenSearch project is under that license. The OpenSearch FAQ does not describe any paid edition, so enabling audit logging carries no license fee. Your costs come from the infrastructure that stores and reviews the records, from the people who operate and test the setup, and from any log platform you choose to use. DeployOpen plans, configures, tests and documents audit logging inside infrastructure you control. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your auditor early which evidence they expect.
Who issues the audit opinion on our OpenSearch audit logs?
Independent auditors and certification bodies issue audit opinions, reports, attestations and certifications, and DeployOpen does not issue any of them. DeployOpen prepares the audit logging configuration, test results, runbooks and supporting evidence that your auditor reviews. Before the engagement starts, ask your auditor which control objectives apply, what evidence format they accept, how they sample records, and whether they need access to the destination. The written scope can then list the evidence to be produced. Your compliance lead remains responsible for mapping the setup to the framework and for deciding whether it meets your obligations.
Should audit logs be stored on the same OpenSearch cluster they describe?
Keep audit records outside the cluster they describe, because a compromised or failing cluster could otherwise hide its own activity or lose the records you need. A separate destination, such as another OpenSearch cluster, object storage or a log platform, gives the records their own access controls and retention settings. The trade-off is more moving parts: the destination needs capacity, monitoring and credentials, and the transfer path must handle outages without silently dropping events. Test a destination failure during planning and document what happens to pending records and who gets alerted. Reviewers should be able to read the records they need without holding administrative rights on the monitored cluster.
How DeployOpen works on this
DeployOpen plans OpenSearch audit logging together with the cluster design, so categories, storage targets and access are decided before anything is switched on. We work in your own cloud accounts, data centers or air-gapped networks, under a fixed-scope engagement with the scope agreed in writing before build begins.
How we scope
- The written scope names which audit log categories are enabled and why each one is needed.
- It records the storage target for audit records and confirms it sits outside the cluster being audited.
- Retention, access to audit indexes, and who reviews the records are agreed before build starts.
How we build
- Security plugin settings are configured using the deployment method your team already runs, such as Helm or Ansible.
- Audit records are shipped to the agreed storage target over encrypted connections, with transport checked end to end.
- Test cases confirm that each enabled category produces records and that those records reach the target.
How we hand over
- A runbook covers how to change audit categories, rotate storage access and respond when records stop arriving.
- Documentation records the configuration as deployed, including the cluster version and security settings in use.
- Evidence packs for your compliance assessment, with auditors and certification bodies making the final determination.
How we support
- Ongoing support is available as a retainer, covering version changes and audit configuration reviews.
- Upgrades are planned against OpenSearch's release lifecycle, so audit settings are re-tested after each version change.
- Continuous testing of audit coverage is available under a retainer if your team wants recurring checks.
