Troubleshoot Audit Logging on Confluent Cloud

Use these tips to troubleshoot audit logging issues.

Cluster not sending audit log events

Audit logs are available on Standard, Enterprise, Dedicated, and Freight clusters only. If you are using a Basic cluster type, consider upgrading.

Topic altered without authorization does not appear in audit log messages

If you attempted to alter a topic on a Dedicated cluster, but the topic does not subsequently appear in the audit logs messages, this can happen because some common administration tools attempt to describe a resource before attempting to create, alter, or delete it. In cases where the describe request fails or is rejected, the tool might not attempt to send a second request. In such cases, the audit logs include an authentication event, but do not include any additional authorization checks, because the create, alter, or delete request was never made.

Newly created topic does not appear in audit log messages

When the API checks a user’s permission to create a topic, it first attempts to confirm that the user has cluster-level permission to create any topic. If so, the API grants access. If not, the API performs a secondary check to see if the user has permission to create the specific topic name (or a prefix using that name). If this cluster-level check succeeds, then the audit log event includes the ID of the cluster without any reference to the specific topic, because the topic name is not used in the cluster-level permission check.

Unfamiliar names appear in authorization checks

You might find several CreateTopics authorization checks with topic names that you don’t recognize or that don’t exist. When logged in to the Confluent Cloud Console, certain pages commonly perform “dry-run” permission checks in the background to check permissions and show only the controls that are relevant to the logged-in user. The authentication and authorization checks for these dry-run requests are logged. They typically have a resourceName that looks like crn:///kafka=lkc-abcde/topic=341e9e2e-f734-439d-8469-4433ce7f627c.

Authentication failures do not appear in audit log messages

If an authentication failure does not appear in your audit log messages, this can happen because Confluent Cloud logs all authentication failures internally, but only passes them on to your audit logs when the connection tries to use one of your valid, active API keys on the cluster, but with an incorrect secret.

Audit log messages include identifiers with no descriptions

If you come across audit log messages that use identifiers with no descriptions, for example, User:12345, run one of the following commands:

confluent iam user list
confluent api-key list
confluent iam service-account list

Describe command output is empty

You can run the confluent audit-log describe command and see no output, even when your organization has audit logging enabled. In such cases, the Confluent CLI might have cached your organization’s information before you enabled audit logging. To refresh the cache, run the following command:

confluent login --prompt

Audit log messages are not being generated for producer and consumer requests

Audit log messages include the authentication events from when the producers and consumers connect, but not the produce and consume requests themselves.