# Audit Log Event Records on Confluent Cloud
An audit log record is a JSON-formatted entry that captures an auditable
event in Confluent Cloud. Confluent Cloud stores each record in the audit log cluster’s
`confluent-audit-log-events` Apache Kafka® topic.
When an [auditable event](../../_glossary.md#term-auditable-event) occurs in Confluent Cloud, an event method is
triggered and generates the [event message](../../_glossary.md#term-event-message) that becomes the record.
Each event record stored in the audit log includes a unique identifier (`id`)
that ensures uniqueness across all events, regardless of event source
(`source`).
Each audit log record comprises the following details:
* [event context](#event-context-properties): Metadata about the event,
including the source, event type, data content type, subject, and time.
* [event data](#event-data-properties): Details about the event data,
including the service name, the method name, resource name, authentication,
authorization, and request.
#### NOTE
Auditable event messages do not capture the content of events. Audit log records
inform you that an event happened and only contain metadata about the event context
and event data.
## Audit log record example
The following audit log record example shows the contents of an audit log
message that is returned from a cluster when a user creates a new topic:
```json
{
"id": "fc0f727d-899a-4a22-ad8b-a866871a9d37",
"source": "crn://confluent.cloud/kafka=lkc-a1b2c",
"specversion": "1.0",
"type": "io.confluent.kafka.server/authorization",
"datacontenttype": "application/json",
"subject": "crn://confluent.cloud/kafka=lkc-a1b2c",
"time": "2021-01-01T12:34:56.789Z",
"data": {
"serviceName": "crn://confluent.cloud/kafka=lkc-a1b2c",
"methodName": "kafka.CreateTopics",
"resourceName": "crn://confluent.cloud/kafka=lkc-a1b2c/topic=departures",
"authenticationInfo": {
"principal": "User:123456"
},
"authorizationInfo": {
"granted": true,
"operation": "DescribeConfigs",
"resourceType": "Topic",
"resourceName": "departures",
"patternType": "LITERAL"
},
"request": {
"correlationId": "123",
"clientId": "adminclient-42"
}
}
}
```
In the example, the [event context properties](#event-context-properties)
give values related to metadata of the event occurrence.
* The `source` of the auditable event message is defined in the Confluent
Resource Name (CRN) `crn://confluent.cloud/kafka=lkc-a1b2c`, which
indicates that the event occurred in the Kafka cluster `lkc-a1b2c`.
* The `type` of event, `io.confluent.kafka.server/authorization`, indicates
that the auditable event message was triggered as a result of an authorization check.
* The `time` shows the timestamp for the authorization event.
In the [event data properties](#event-data-properties) section, the
`data` payload includes event data details for the authorization event.
* The `serviceName` shows the event occurred in the Kafka cluster `lkc-a1b2c`.
* The `methodName` shows the authorization was for creating a topic.
* The `resourceName` shows the topic is `departures`.
* The `authenticationInfo` shows that the authenticated user account was `123456`.
* The `authorizationInfo` section shows that authorization was granted to run the
operation `DescribeConfigs` on the topic `departures`.
* The `request` section includes the request correlation identifier and the client identifier.
Complete details about all properties are included in [event context
properties](#event-context-properties) and [event data properties](#event-data-properties).
## Event context properties
The first section of an audit log entry includes contextual information about
the event:
* Unique identifier
* Source of the event
* Event log schema version
* Type of event
* Data content type
* Subject of the event
* Time the event occurred
| Event context property | Description |
|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `id` | A randomly generated universally unique identifier (UUID) that ensures
uniqueness across all sources. |
| `source` | The source location of the auditable event.
For events on Kafka clusters, this is a [Confluent Resource Name (CRN)](../../security/access-control/hierarchy/confluent-resource-names.md#confluent-resource-names)
that identifies the cluster. For other events, it is the top-level CRN (`crn://confluent.cloud/`). |
| `subject` | The resource affected by the auditable event. For Kafka clusters, this is the CRN of the cluster itself.
For other resources, it is the CRN for the resource. |
| `specversion` | The version of the [CloudEvents](https://cloudevents.io/) specification in use. |
| `type` | The type of event that occurred. The value in this property corresponds
with the presence or absence of certain other event properties. Valid types are:
* `io.confluent.kafka.server/authentication`
* `io.confluent.kafka.server/authorization`
* `io.confluent.cloud/request`
For more details, read the [audit log event schema](audit-log-schema.md#cloud-audit-log-schema-file). |
| `datacontenttype` | The CloudEvent format the audit log data is presented in (JSON). |
| `time` | The timestamp, in [RFC 3339 format](https://datatracker.ietf.org/doc/html/rfc3339), for when the event occurred. |
## Event data properties
Event data properties describe the `data` payload of an audit log record,
including the service, method, resource, and authentication and authorization
details involved in the event.
The event payload is encoded into the media format specified in the
`datacontenttype` context property.
All the data properties are included in the `data` section of the audit log
record. Because these properties vary between different event types, see the
relevant section that follows for:
* [Authentication event data](#data-properties-authentication)
* [Authorization event data](#data-properties-authorization)
* [Organization event data](#data-properties-organization)
## Authentication event data properties
Event type: `io.confluent.kafka.server/authentication`
| Event data property | Description |
|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `data` | The event data payload for the auditable event. |
| `methodName` | Always `kafka.Authentication`. |
| `serviceName` | The CRN of the Kafka cluster where a principal is attempting
authentication. |
| `resourceName` | The CRN of the Kafka cluster. For authentication events, this is the
same value as `serviceName` because authentication applies at the
cluster level, not to a specific sub-resource. |
| `authenticationInfo` | Details about the [principal](../../_glossary.md#term-principal) being authenticated. |
| `result` | The outcome of the authentication. |
## Authorization event data properties
Event type: `io.confluent.kafka.server/authorization`
| Event data property | Description |
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `data` | The event data payload for the auditable event. |
| `methodName` | The type of operation for which authorization is performed.
For resources on a Kafka cluster, `methodName` properties start with a `kafka.` prefix.
For resources elsewhere, the `methodName` is `mds.Authorize`. |
| `serviceName` | The service that generated this audit log.
For authorization on a Kafka cluster, it is the CRN of that specific Kafka cluster.
For authorization elsewhere, it is the top-level Confluent Cloud CRN. |
| `resourceName` | Canonical CRN of the resource for which authorization was being requested.
For creation of new resources, authorization is checked before the entity
even exists. So the included CRN is of the parent scope, and not the entity itself. |
| `authenticationInfo` | Details about the principal for which the authorization was checked.
For nested properties, see the [audit log schema file](audit-log-schema.md#cloud-audit-log-schema-file). |
| `authorizationInfo` | Details of the resource type, authorization policy applied, and whether
the authorization was granted or denied. |
| `request` | Additional user-supplied information in the request. |
## Organization event data properties
Event type: `io.confluent.cloud/request`
| Event data property | Description |
|-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `data` | The event data payload for the auditable event. |
| `methodName` | The type of request that triggered the auditable event message. |
| `serviceName` | The top-level Confluent Cloud CRN (`crn://confluent.cloud`). |
| `resourceName` | The CRN of the affected resource. |
| `cloudResources` | A list of resources affected by the organization event. |
| `authenticationInfo` | Details about the [principal](../../_glossary.md#term-principal) that made the request. |
| `requestMetadata` | Additional metadata, such as the client IP address, that can be used to
correlate multiple auditable event actions triggered by a single user
account. A single action by a user account, such as trying to create
a Kafka cluster, might result in multiple audit log records, such as
authorization checks and a result or response. You can use the
request ID to connect these audit log records. |
| `request` | Details about the request. |
| `result` | The result of the request, such as a resource being created. |
## authenticationInfo properties
The `authenticationInfo` section contains details about the principal being
authenticated.
| Property name | Type | Description | Examples |
|-----------------|--------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------|
| principal | string | Identifies the authenticated principal that made the request. | User:12345 |
| identity | string | Identity of the requester in CRN format. Included when
[group mapping](../../security/authenticate/user-identities/user-idps/sso/group-mapping/overview.md#group-mapping) is enabled. | crn://confluent.cloud/organization=uuid-for-ourcorp/identity-provider=ourcorp-idp/identity=u-yw9507 |
## authorizationInfo properties
The `authorizationInfo` section contains details about the authorization
decision, including the resource, operation, access control method, and
assigned principals used to grant or deny the request.
| Property name | Type | Description | Examples |
|--------------------|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
| granted | boolean | The result of the authorization check. | |
| operation | $ref | Identifies the operation being checked for authorization. | Refers to `#/$defs/operation` |
| resourceType | string | The type of the resource being checked for authorization. | Cluster, Group, Topic |
| resourceName | string | The resource name of the checked authorization rule. | kafka-cluster, delivery-estimator, departures |
| patternType | string | The pattern, LITERAL or PREFIX, used to match the resource against the authorization rule. | LITERAL or PREFIX |
| aclAuthorization | object | Details about an access control list (ACL) rule. See also
[aclAuthorization properties](#acl-authorization-properties). | |
| rbacAuthorization | object | Details about the role-based access control (RBAC) role used for
the authorization decision. See also
[rbacAuthorization properties](#rbac-authorization-properties). | |
| assignedPrincipals | array | The list of principals the user has access to, including the user and
group mappings. Included when [group mapping](../../security/authenticate/user-identities/user-idps/sso/group-mapping/overview.md#group-mapping) is enabled. | Array of strings |
### aclAuthorization properties
The `aclAuthorization` section contains details about the ACL rule used for
the authorization decision.
| Property name | Type | Description | Examples |
|-----------------|--------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------|
| permissionType | $ref | The type of permission granted with `ALLOW` or
denied with `DENY` by the ACL rule. | Refers to #/$defs/permissionType |
| host | $ref | Host to which the ACL rule applies, usually a wildcard (`*`). | Refers to `#/$defs/host` |
| actingPrincipal | string | The decisive principal used for authorization. Included when
[group mapping](../../security/authenticate/user-identities/user-idps/sso/group-mapping/overview.md#group-mapping) is enabled. | |
### rbacAuthorization properties
The `rbacAuthorization` section contains the RBAC role, its scope, and
the acting principal used for the authorization decision.
| Property name | Type | Description | Examples |
|-----------------|--------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------|
| role | $ref | A role that the principal has, granting authorization to perform the
operation on the resource. | Refers to `#/$defs/role` |
| scope | object | The scope the action was authorized in. See also
[rbacAuthorization scope properties](#rbac-authorization-scope-properties). | |
| actingPrincipal | string | The decisive principal used for authorization. Included when
[group mapping](../../security/authenticate/user-identities/user-idps/sso/group-mapping/overview.md#group-mapping) is enabled. | |
#### rbacAuthorization scope properties
The `outerScope` property lists the scope’s path elements, with the
outermost scope listed first.
| Property name | Type | Description | Examples |
|-----------------|--------|-----------------------------------------------------------------|------------------|
| outerScope | array | The path elements in the outer scopes with the outermost first. | Array of strings |
## Related content
- [Schema quick reference](audit-log-schema.md#cloud-audit-log-schema-quick-reference)
- [Audit Log Event Categories on Confluent Cloud](cloud-audit-log-categories.md#cloud-audit-log-categories)