[Repository Request]opensearch-audit-logging

[niravpi]

Are you requesting a new GitHub Repository within opensearch-project GitHub Organization?

Yes

GitHub Repository Proposal

#501

GitHub Repository Additional Information

1. What is the new GitHub repository name?

opensearch-audit-logging

2. Project description and community value?

A standalone audit logging plugin for OpenSearch that decouples audit logging from the security plugin into an independent, first-class capability. It captures data-plane operations (REST requests, transport actions, document reads/writes) using standard OpenSearch extension points (ActionFilter, IndexingOperationListener), works with or without the security plugin, and provides an extensible sink architecture (Log4j, internal OpenSearch index, custom sinks via reflection). When the security plugin is co-installed, it enriches audit events with user identity from ThreadContext — no compile-time dependency on the security plugin JAR.

Community value:

• Makes audit logging available to ALL OpenSearch users, not just those with FGAC enabled
• Enables compliance (SOC2, HIPAA, PCI-DSS, ISO 27001, GDPR) without requiring the full security stack
• Provides an extensible AuditSink interface for community-built SIEM integrations (Splunk, Datadog, etc.)
• Reduces complexity in the security plugin by extracting ~20 classes across config/, impl/, routing/, sink/ packages
• Enables independent release cycle for audit logging improvements

3. What user problem are you trying to solve with this new repository?

Today, audit logging is embedded inside the security plugin (org.opensearch.security.auditlog package) and requires FGAC to be enabled. This means:

• Users running OpenSearch for log analytics/observability without FGAC have zero audit visibility
• Users who only need audit trails for compliance must adopt the full security plugin (authentication backends, RBAC, multi-tenancy, DLS/FLS)
• Users who want to route audit events to custom SIEM systems must modify the security plugin itself
• Audit logging bug fixes and improvements are blocked by unrelated security plugin release cycles

This plugin solves all four problems by providing audit logging as a standalone, extensible capability.

4. Why do we create a new repo at this time?

• Active development is starting immediately with a team of 6 engineers
• The existing audit logging code in the security plugin has a clean interface boundary (AuditLog.java interface, well-defined event categories, separate sink architecture) that makes extraction feasible now
• The security plugin's audit code (~20 classes) adds significant surface area to an already complex plugin — decoupling reduces maintenance burden for both repos
• This follows the established pattern of decoupling capabilities from larger plugins (similar to opensearch-storage-encryption being extracted from OpenSearch core: [GitHub Request]Creation of new opensearch-storage-encryption plugin repo #286)

5. Is there any existing projects that is similar to your proposal?

The security plugin's built-in audit logging (https://github.com/opensearch-project/security/tree/main/src/main/java/org/opensearch/security/auditlog) provides similar functionality but is tightly coupled to the security plugin and requires FGAC. This project extracts and extends that capability into a standalone plugin. No other standalone audit logging plugin exists in the OpenSearch ecosystem.

6. Should this project be in OpenSearch Core/OpenSearch Dashboards Core? If no, why not? Or, shall we combine this project to an existing repo source code in opensearch-project GitHub Org?

No, it should not be in OpenSearch Core. Audit logging is an optional capability — not all deployments need it. A plugin architecture allows users to install it only when needed and allows an independent release cycle. This follows the same pattern as other OpenSearch plugins (security, alerting, anomaly-detection, index-management).

It should also not remain in the security plugin repo because:

• Audit logging is a compliance/observability concern, not strictly a security concern
• The tight coupling to FGAC prevents users without the security plugin from using audit logging
• Independent maintenance reduces the security plugin's complexity and test matrix

7. Is this project an OpenSearch/OpenSearch Dashboards plugin to be included as part of the OpenSearch release?

Yes, it is an OpenSearch plugin. We propose including it in the OpenSearch distribution as an optional bundled plugin, similar to how the security plugin, alerting plugin, and anomaly-detection plugin are bundled today.

GitHub Repository Owners

1. Who will be supporting this repo going forward?

The OpenSearch Security team, with community contributions.

2. What is your plan (including staffing) to be responsive to the community (at a minimum, this should include reviewing PRs, responding to issues, answering forum questions?)

• Review PRs within 5 business days
• Respond to issues within 3 business days
• Monitor and respond to OpenSearch forum questions tagged with audit-logging
• Regular releases aligned with OpenSearch release cadence (major/minor/patch)
• Team of 6 engineers for initial development, ongoing maintenance by 2-3 engineers

3. Initial Maintainers List (max 3 users, provide GitHub aliases):

• Nirav - https://github.com/niravpi
• Shubham – https://github.com/shubhmkr-amazon
• Uday - https://github.com/udabhas

GitHub Repository Source Code / License / Libraries

1. Please provide the URL to the source code.

New repository — no existing source code yet. Development will begin upon repo creation. The plugin design is based on the existing audit logging architecture in the security plugin: https://github.com/opensearch-project/security/tree/main/src/main/java/org/opensearch/security/auditlog

2. What is the license for the source code?

Apache License 2.0

3. Does the source code include any third-party code that is not compliant with the Apache License 2.0?

No. The plugin will use only Apache 2.0 compatible dependencies:

• OpenSearch core APIs (Apache 2.0)
• Log4j2 (Apache 2.0) — already provided by OpenSearch runtime
• Jackson (Apache 2.0) — already provided by OpenSearch runtime
• No additional third-party libraries required

What is the publication target(s)?

You can choose multiple targets from the list.

Maven Central

Notes (DO NOT CHANGE)

Next Steps:

• If this is about creating a new GitHub Repository

  • Build Interest Group (BIG) and its members will review your proposal and provide feedback
    • Review of Proposal, asking questions, adding comments
    • If there is any concern regarding the naming / IP, additional IP review will be requested
    • Involve Subject Matter Experts from other repositories on the proposed topics
    • Ensure new repositories align with the foundation’s charter
    • Review the provided source code if any
    • Send final feedback and recommendations to the Technical Steering Committee
  • Technical Steering Committee (TSC) will have a vote based on BIG feedback, and reply back the vote as a comment in this issue by a TSC member
  • At least three positive (+1) TSC members' votes are necessary, and no vetoes (-1) after a one week period, then Admin Team will open a repo creation ticket with Linux Foundation
  • Linux Foundation verify the votes and create repo
  • Admin Team setup automations on repo settings, secrets, scanning, add initial maintainers, and more
  • Repository delivered to the original requester

• If you already have a GitHub repo and just want to add new publication target(s)

  • Admin Team will review your request and follow up

Track the progress of your request here: Engineering Effectiveness Board (view).
Member of @opensearch-project/admin will take a look at the request soon.
Thanks!

[peterzhuamazon]

Have offline discussion with @niravpi and will check this again once they have working code available.
In the meantime folks can check their RFC for more information.

Thanks.