You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@apisix.apache.org by "mdnfiras (via GitHub)" <gi...@apache.org> on 2025/09/27 13:17:29 UTC

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

mdnfiras opened a new issue, #12640:
URL: https://github.com/apache/apisix/issues/12640

### 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 usage:
* 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
```yaml
apisix:
admin_audit_logs:
enabled: true
logging_plugin_name: elasticsearch-logger
logging_plugin_config:
# configure the chosen plugin here
```

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "Baoyuantop (via GitHub)" <gi...@apache.org>.

Baoyuantop commented on issue #12640:
URL: https://github.com/apache/apisix/issues/12640#issuecomment-3344690971

   > 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?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "venkatapgummadi (via GitHub)" <gi...@apache.org>.

venkatapgummadi commented on issue #12640:
URL: https://github.com/apache/apisix/issues/12640#issuecomment-4791988485

   @Baoyuantop Following up on the scoped v1 proposal above — would appreciate guidance on integration point and actor_header before opening a PR. Thanks!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "mdnfiras (via GitHub)" <gi...@apache.org>.

mdnfiras commented on issue #12640:
URL: https://github.com/apache/apisix/issues/12640#issuecomment-3351502283

   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 identify the user.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "Crazy-xyr (via GitHub)" <gi...@apache.org>.

Crazy-xyr commented on issue #12640:
URL: https://github.com/apache/apisix/issues/12640#issuecomment-3342235901

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

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

Posted by "venkatapgummadi (via GitHub)" <gi...@apache.org>.

venkatapgummadi commented on issue #12640:
URL: https://github.com/apache/apisix/issues/12640#issuecomment-4762152957

   Hi maintainers — I'm interested in contributing a scoped v1 for Admin API audit logging.
   
   **Proposal**
   - Optional `admin_audit_logs` config in `config.yaml`
   - Record Admin API write operations (POST/PUT/DELETE) as structured JSON
   - Fields: timestamp, actor (from configurable request header), resource type/id, HTTP method, result
   - Phase 1 output: file and/or reuse of an existing logger plugin
   - Phase 2 (separate PR): dashboard viewer and export
   
   **Questions**
   1. Is hooking into the Admin API layer in `apisix/admin/` the preferred integration point?
   2. Is a configurable `actor_header` acceptable for operator identity?
   3. Should v1 exclude Dashboard UI to keep the initial PR focused?
   
   Happy to share a short design note before opening the PR.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org