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