Skip to content
Cloud Provider Benchmarks

Cloud security & auditing

OpenStack audit logging: CADF, keystonemiddleware and building an audit trail

How audit logging works in OpenStack: the CADF event format, the keystonemiddleware audit filter, Keystone notifications and how clouds expose audit events.

Published: Updated: Türkçe oku

Direct answer

In OpenStack, audit events are produced by the keystonemiddleware audit filter in each API service and by Keystone's CADF notifications. They are emitted as notifications (or logs) and must be collected, stored and indexed by the operator; there is no default retention or search interface.

Executive summary

OpenStack has no single built-in audit service comparable to CloudTrail. Instead, the keystonemiddleware audit filter can be inserted into each service's API pipeline to emit DMTF CADF events for every request, and Keystone emits CADF notifications for identity operations. Operators route these events through oslo.messaging to storage and search systems. Public OpenStack clouds typically package this into a managed audit service; PortvMind's vTrail is one example of a provider-operated audit log for an OpenStack-based cloud.

Key findings

  1. 01 CADF (Cloud Auditing Data Federation) is a DMTF standard that structures each event as initiator, action, target, observer and outcome.
  2. 02 keystonemiddleware's audit filter maps API paths to CADF actions using per-service audit map files and attaches the authenticated user, project and roles from the Keystone token.
  3. 03 Delivery is via oslo.messaging notifications, so the operator decides storage, retention and access — the main difference from managed audit services.
  4. 04 Provider-operated audit services on OpenStack clouds add the missing pieces: storage, retention, search and tenant-scoped access.

The CADF event model

CADF describes every auditable action with a small, fixed vocabulary:

CADF element Meaning Example
initiator Who acted user ID, name, project, host address, agent
action What was attempted create, update, delete, read/list
target What was acted upon a server, volume or network, by type URI and ID
observer Who recorded it the API service that emitted the event
outcome Result success, failure, pending
eventTime When RFC 3339 timestamp

keystonemiddleware’s audit filter

The audit middleware sits in an API service’s WSGI pipeline next to the authentication filter. For each request it:

  1. Reads the token context set by auth_token (user, project, roles).
  2. Maps the HTTP method and path to a CADF action and target using an audit map file for that service.
  3. Emits a CADF event when the request arrives and another with the outcome when the response returns.
  4. Sends the event through oslo.messaging as a notification, or writes it to a log.

Because it runs inside each service, coverage depends on the operator enabling the filter everywhere.

Keystone notifications

Keystone itself emits CADF-formatted notifications for identity operations such as authentication, user and project changes and role assignments when configured with the CADF notification format. These complement the per-service API events.

What the operator must add

The middleware produces events; it does not store or serve them. An audit trail needs:

  • a collector consuming notifications from the message bus;
  • storage with a defined retention period and write protection;
  • indexing and search by user, project, resource and time;
  • tenant isolation, so each customer sees only their own events;
  • export to customer-owned systems.

This is the gap that provider-operated services close on public OpenStack clouds.

vTrail as an example

vTrail is PortvMind Cloud’s audit-logging service. Its provider-supplied event model records the time, request ID, HTTP method and path, status, client IP, user agent, the authenticated user, project and scope, the service and route, and the request duration. The mapping below shows how those fields correspond to CADF, CloudTrail and Google Cloud audit fields.

Conceptual cloud audit event data model For research documentation; does not represent production audit records.
Field Type Description AWS CloudTrail Google Cloud Audit Logs OpenStack CADF
event_time string (RFC 3339) When the operation was received, in UTC. eventTime timestamp eventTime
request_id string Unique request identifier used to correlate gateway, service and resource logs. requestID insertId / operation.id id / requestId (attachment)
http_method string HTTP verb of the API call (GET, POST, PUT, PATCH, DELETE). — httpRequest.requestMethod action (mapped)
full_path string Requested API path, identifying the target resource. eventSource + eventName protoPayload.methodName / resourceName target.id / requestPath
http_status integer Response status code — the outcome of the operation. errorCode (on failure) protoPayload.status.code outcome / reason.reasonCode
client_ip string (IP) Source IP address of the caller. sourceIPAddress protoPayload.requestMetadata.callerIp initiator.host.address
user_agent string Client software (console, CLI, SDK, Terraform). userAgent protoPayload.requestMetadata.callerSuppliedUserAgent initiator.host.agent
auth_user_id string Stable identifier of the authenticated user. userIdentity.principalId protoPayload.authenticationInfo.principalSubject initiator.id
auth_user_name string Human-readable user name at the time of the request. userIdentity.userName / arn protoPayload.authenticationInfo.principalEmail initiator.name
auth_project_id string Project (tenant) the token was scoped to. recipientAccountId resource.labels.project_id initiator.project_id
auth_scope string Authorisation scope or role context of the token. userIdentity.sessionContext protoPayload.authorizationInfo initiator.credential
service_id string Backend cloud service that handled the request (compute, network, storage). eventSource protoPayload.serviceName observer.id / target.typeURI
route_id string API gateway route that matched the request. — — —
request_time number (ms) End-to-end request processing time. — httpRequest.latency —
Empty template (JSON)
{
  "event_time": "",
  "request_id": "",
  "http_method": "",
  "full_path": "",
  "http_status": null,
  "client_ip": "",
  "user_agent": "",
  "auth_user_id": "",
  "auth_user_name": "",
  "auth_project_id": "",
  "auth_scope": "",
  "service_id": "",
  "route_id": "",
  "request_time": null
}

Retention, export, search and integrity features of vTrail are not yet publicly documented and are marked unverified in the audit logging comparison.

Limitations

  • OpenStack deployments vary widely; which services emit audit events depends on configuration.
  • CADF field mappings in the table are conceptual equivalents, not exact semantic matches.
  • vTrail information is provider-supplied.

Conclusion

OpenStack gives operators a standards-based way to generate audit events, but not a finished audit trail. When evaluating an OpenStack-based provider, ask what it has built around CADF: coverage, retention, search, tenant isolation and export.

Frequently asked questions

Does OpenStack have a CloudTrail equivalent?

Not as a single service. OpenStack provides the building blocks — the audit middleware and CADF notifications — and operators assemble collection, storage and search around them.

What is CADF?

Cloud Auditing Data Federation, a DMTF standard event model for audit records. OpenStack uses it through the pyCADF library.

Which OpenStack services can be audited?

Any WSGI API service whose paste pipeline includes the audit filter and which has an audit map file, such as Compute, Networking, Block Storage and Image.

Sources

  1. [1] keystonemiddleware — Audit middleware — OpenStack Official documentation accessed:
  2. [2] pyCADF documentation — OpenStack Official documentation accessed:
  3. [3] DMTF Cloud Auditing Data Federation (CADF) — DMTF Official documentation accessed:
  4. [4] Keystone event notifications — OpenStack Official documentation accessed:
  5. [5] PortvMind Cloud — PortvMind Supplied by provider team accessed: