Control Plane auditing data model

Three are three categories of audit events.

CDP service events
For actions that a service within the CDP Control Plane undertakes. These actions are often as a result of human activity, but can also result from autonomous processes within the Control Plane.
API request events
For calls to public API endpoints. These events are analogous to access logs kept by web servers. Because an API call often leads to actions within the CDP Control Plane, an API request often connects to one or more CDP service events.
Interactive login events
For logins to the CDP Control Plane.
All three categories of audit events share the following common fields:
Field name Description Example
version Version of the audit event model 1.0.0
ID Unique identifier for the event a random UUID
source Control plane service that submitted the event iam
name Type of action being audited createGroupServiceEvent
timestamp Time when the action occurred 2020-03-18T01:02:03Z
actor identity Who initiated the action see below
account ID Identifier for account within which the action occurred a UUID
request ID Identifier for API request that led to the action a UUID
result code A string describing the result of the action, whether successful or not INVALID_ARGUMENT
result message A short message further describing the result The group already exists

Each event source (service) defines its own event names. So, two sources may emit events with the same name, but for different actions. Events for an action within one source always use the same name.

An actor is an entity that causes an action to occur. In an audit event, an actor may be specified one of two ways.

Actor CRN
For a human actor, or for the special "internal" actor
Actor service name
For an antonymous process initiated by a control plane service (reserved for future use)

It is possible for the actor service name and the source in an audit event to be different. For example, a high-level service A may kick off an autonomous process that makes calls to another service B to make changes; audit events from that process would have actor service name A but source B.

Every call to the Control Plane public API receives a request ID. The request ID propagates through the Control Plane to services that perform actions, and audit events from those services include the request ID. Therefore, a request ID can be used to tie together multiple audit events under the umbrella of a single API request.

Most audit events include result information, but sometimes that information may be missing. This indicates that the event source experienced a failure such that it could not submit the result information for an event after submitting its initial, known set of information.

For example, consider the action to grant a role to a user. The event source responsible for this action starts by submitting an audit event for role creation, including all the information known before attempting the action: the user CRN, the role CRN, and perhaps more. After role creation either succeeds or fails, the source appends result information to the event. However, if the source crashes, it cannot append the result information. When this happens, at least the initial, known information is recorded in an audit event.