Audit & Compliance API¶
The audit API gives platform admins a read-only view of all significant actions performed in an organization — logins, permission changes, resource mutations, and destructive operations. All audit data is stored in the AuditLog table and is never writable through the API.
Admin-only
All audit endpoints require a platform-admin account (Admin role). Member accounts receive 403 Forbidden.
Endpoints¶
| Method | Path | Description |
|---|---|---|
GET | /audit/statistics | Action counts for a date range |
GET | /audit/access_matrix | All members with their current roles and permissions |
GET | /audit/permission_changes | Membership permission change history |
GET | /audit/failed_access | Recent denied/failed access attempts |
GET | /audit/who_can | List members with a given permission |
GET | /audit/separation_of_duties | Detect conflicting permission combinations |
GET | /audit/recent_activity | Most recent audit events |
Statistics¶
Returns aggregated counts for the requested period:
{
"total_actions": 482,
"success_count": 451,
"denied_count": 27,
"failed_count": 4,
"unique_accounts": 8
}
Optional query parameters from and to (ISO 8601 datetime) narrow the window. Defaults to the last 30 days.
Access matrix¶
Returns an array of all current memberships with their effective permissions. Admin accounts show { "*": ["*"] }. Useful for compliance reviews and access audits.
Permission changes¶
GET /audit/permission_changes?from=2026-01-01T00:00:00Z&to=2026-01-31T23:59:59Z
Authorization: Bearer <admin-token>
Returns the 100 most recent membership permission change events in the given window (defaults to last 30 days). Each entry includes the actor, the affected membership, and a change_data object with before/after snapshots.
Failed access attempts¶
Returns up to 100 recent denied audit log entries. Filter to a specific account with the account_id query parameter. Defaults to the last 7 days.
Who can¶
Returns every membership in the organization annotated with whether the member has the requested permission and how they have it (role, explicit_permission, or none).
Valid categories: projects, openstack, garden, rgw, apps, billing, members, settings.
Separation of duties¶
Runs a set of predefined checks and returns any violations:
| Check | Risk |
|---|---|
| Member has both billing-update and infrastructure-delete | High |
| Non-admin member can remove other members | Medium |
{
"violations": [
{
"type": "billing_and_infrastructure_delete",
"account": "ops@example.com",
"risk": "high",
"description": "User has both billing management and infrastructure deletion permissions"
}
],
"checks": ["billing_and_infrastructure_delete", "non_admin_member_management"]
}
Recent activity¶
Returns the most recent audit events, newest first. limit is capped at 100. Filter by account_id to see activity for a specific user.
Audited operations¶
The following operations generate audit log entries automatically. This list is not exhaustive but covers the most compliance-relevant events:
| Action key | Trigger |
|---|---|
rgw_users.purge | Irreversible all-objects purge before RGW user deletion |
memberships.update | Permission or role change on a membership |
accounts.login | Successful and failed logins |
accounts.close | Account closure |
Purge events record the actor, organization, project, bucket names, and total size at the time of the purge — ensuring a guaranteed audit trail before any data is destroyed (ISO 27001 / DSGVO requirement).