feat: As a user, I want audit logs for the APISIX Admin API, so that all configuration changes are transparent and traceable

[mdnfiras]

Description

As a user, I would like the APISIX Admin API to provide audit logs that record all configuration changes (e.g., route creation, updates, deletions, plugin configurations), along with details such as who made the change, when it was made, and what was changed.

Motivation:

• Transparency and accountability: making sure all changes are visible and traceable to specific users or automation processes.
• Troubleshooting and debugging: quickly identifying when and why a misconfiguration was introduced.
• Compliance and security: many organisations must comply with standards (like ISO 27001, etc.), which require detailed audit trails for system changes.
• Forensics and incident response: having audit logs helps reconstruct the sequence of events that led to a security incident or system outage.

Proposed criteria:

• Admin API operations (create, update, delete) are logged.
• Logs include: timestamp, user/actor identity, request details, and result (success/failure).
• Logs storage:
  • Storage format: logs are stored in a structured and queryable format (e.g., JSON).
  • Storage backend: configurable backends for audit log storage: e.g., file, database, external logging system, perhaps existing logging plugins can be reused?
• Dashboard integration:
  • A dedicated audit logs viewer is available in the APISIX Dashboard where logs can be filtered and searched by actor, resource, action type, or time range.
  • UI displays change diffs where applicable (e.g., before/after for route changes).
  • export functionality (e.g., download as JSON or CSV) for compliance audits.

Example configuration by the user:

• The user would have to enable this in the APISIX config file. And if the implementation reuses existing logging plugins, then the user would have to choose a logging plugin and configure it for audit logging, for example this way:

apisix:
  admin_audit_logs:
    enabled: true
    logging_plugin_name: elasticsearch-logger
    logging_plugin_config:
      # configure the chosen plugin here

[Crazy-xyr]

Audit is a good idea, A dedicated audit logs viewer. I don't think it's necessary at present. Currently, admin_key is a weak RBAC mode. It's unlikely that everyone distributes different keys to use the dashboard, so that the operator is the same, unless methods such as user/password are supported.

Most logs plugins only provide the stored api. Does this mean that plugins need to be modified to offer a query api?

What i focus on is the configuration comparison between the new and old routes. Currently, each rollback relies on the etcd MVCC（-auto-compaction-retention=7d）, And admin_api use access_log to print the request path, method, json body, and token for auditing

Can we implement the json configuration viewer of the previous independent dashboard, and add a new button to view the plugin configuration of the previous version? Put the configuration changes of the previous few versions into the key-value ( like "previous":{ } ) of etcd, or query etcd MVCC, and all configuration changes can be audited and rolled back，I think it's better to do so

[Baoyuantop]

Currently, admin_key is a weak RBAC mode. It's unlikely that everyone distributes different keys to use the dashboard, so that the operator is the same, unless methods such as user/password are supported.

Hi @mdnfiras, what do you think about this?

[mdnfiras]

Currently, admin_key is a weak RBAC mode. It's unlikely that everyone distributes different keys to use the dashboard, so that the operator is the same, unless methods such as user/password are supported.

in our case, we route the dashboard requests through apisix gateway and we use openid-connect plugin to login to dashboard, and a custom plugin to extract the user email address from the x-userinfo header (which was set by the openid-connect plugin), and we save the email in a new header (i.e X-User-Email). we rely on this new header to identify the user.

other authentication plugins like key-auth will end up setting X-Credential-Identifier and X-Consumer-Username, so these are other headers that can identify the user.

so if the audit logs feature allows the user to chose which request header to be used as identity, then the user can:

• ensure that header exists (i.e by routing the dashboard requests through apisix gateway then using some plugins),
• then set the header name in the apisix audit logs config to use to identify the user.