Skip to content

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

GET /audit/statistics
Authorization: Bearer <admin-token>

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

GET /audit/access_matrix
Authorization: Bearer <admin-token>

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

GET /audit/failed_access?account_id=<uuid>
Authorization: Bearer <admin-token>

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

GET /audit/who_can?category=rgw&action=create
Authorization: Bearer <admin-token>

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

GET /audit/separation_of_duties
Authorization: Bearer <admin-token>

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

GET /audit/recent_activity?limit=50&account_id=<uuid>
Authorization: Bearer <admin-token>

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).