Audit log structure

This topic describes the structure of the Conjur audit logs.

Syslog protocol formats

Audit logs conform to the Syslog Protocol outlined in RFC 5424. Log messages follow the formatting guidelines in the RFC:


For example, a log message for an authentication event appears below:

<86>1 2020-04-14T21:05:52.886+00:00 6002d85d7d48 conjur 898268ec-a9c0-4ed1-9bbd-6c8d9832dbc9 authn [action@43868 result="success" operation="authenticate"][subject@43868 role="demo:user:admin"][auth@43868 authenticator="authn" user="demo:user:admin"][meta sequenceId="1"] demo:user:admin successfully authenticated with authenticator authn

In this example:




The value in angle brackets, (<86> in the example above), is called the Priority Value (PRIVAL). It represents two values, Facility and Severity, such that: Priority Value = Facility * 8 + Severity

For example, the Priority Value of <86> represents Facility 10 and Severity 6 so that 10 * 8 + 6 = 86.

The Facility and Severity values used by Conjur Enterprise have been chosen in accordance with the standardized values defined by RFC 5424, as follows:


  • Facility 4 auth for all events (other than authentication)

  • Facility 10 authpriv (used for all authentication events)


  • Severity 4 warn for failed operations

  • Severity 5 notice for policy load events

  • Severity 6 info for successful operations


Represents the version of the Syslog Protocol.


The time the event was created in a format that conforms to ISO 8601, as required by the RFC.

The actual value of this attribute depends upon the underlying environment:

  • For Kubernetes/OpenShift, HOSTNAME contains the container's internal cluster IP address.

  • For Docker, HOSTNAME containers the 12 character container hash ID.


Identifies the machine that sent the syslog message and is determined by the syslogd process running on Conjur Enterprise.


Identifies the name of the application sending the log message and is hard-coded to conjur.


The Process ID can be used to further identify the sender of a log message.

In Conjur Enterprise, this is set to the value of the X-Request-Id HTTP header, when provided in REST API requests. If the header isn't present, a random UUID is used instead.


The Message ID is a string that identifies the type of message as follows:

  • authn for authentication events

  • check for permission checks

  • fetch for secret value fetches

  • policy for policy changes

  • update for secret value changes

  • password for user password changes

  • api-key for role API key rotations


The structured data elements included in Conjur log messages. For details, see Structured data below.


A human-readable message describing the audit event.


The types of events generated by Conjur Enterprise are fully explained in Audit Event Reference.

Structured data

Conjur log messages include the following structured data elements:

Data Element



Contains details about the operation performed and (optionally) its result. Values may or may not be present, depending on whether an event tracks the success of the audited operation. Possible values include:

  • operation: a verb describing the action performed. For example, when a user tries to change a password operation would be set to change.

  • result: set to success or failure when an action is not successful. For example, when a user attempts to change a password, the result is present and contains either: success or failure, depnding on whether the user successfully changed their password.

    For more information about the structured data fields for audit events, see Audit Event Reference.


For authentication events, this contains the CyberArk authenticator used for the authentication attempt.

  • authenticator: the service ID of the CyberArk authenticator used to perform authentication. Set authn for the default Conjur authenticator.

For all other events, it includes information about the authenticated user or host performing the operation:

  • user: the fully-qualified ID for the authenticated role (the policy path/name where the role is defined).


Contains information about the API client that generated the audit event:

  • ip: The IP address of the client that triggered the action.


The IP address recorded in the audit event is the IP address that is available to the Leader or Followers in the HTTP request. Conjur Enterprise configuration is required to ensure the available IP address is accurate. For more information, see IP Address Overview.


Used for policy load events and includes the following required parameters:

  • version: the current version of the policy, incremented on each load.

  • id: the fully-qualified policy ID for the policy being loaded.


Contains information about the target of the operation that generated the log message. The contents of this element varies, depending on the type of audit event and is specified in Audit Event Reference.

JSON file format

Conjur Enterprise supports the JSON file format for compatibility with log aggregators that can not ingest messages formatted using the Syslog Protocol (such as Splunk).

JSON log files must adhere to the following requirements:

  • Use UTF-8 Encoding

  • Each object must appear on its own line

  • Each line must use valid JSON

  • Each line must be separated by '\n'

JSON field mappings

This section describes how the fields in JSON-formatted log messages map to the fields used for the Syslog Protocol in RFC 5424.

Example of a JSON log message:

  "subject@43868": {
    "resource": "demo:group:security_ops"
  "policy@43868": {
    "version": "1",
    "id": "demo:policy:root"
  "auth@43868": {
    "user": "demo:user:admin"
  "action@43868": {
    "operation": "add"
  "PROGRAM": "conjur",
  "PID": "e9c07c05-4dc2-4809-b7e1-43f5d3a20599",
  "MSGID": "policy",
  "MESSAGE": "demo:user:admin added resource demo:group:security_ops",
  "LEVEL": "notice",
  "ISODATE": "2020-04-14T20:40:24.806+00:00",
  "FACILITY": "auth"

The first several fields with the format <name>@<number> are structured data elements.

The remaining fields are mapped as follows:




Maps to the APP-NAME field


Maps to the PROCID field


Maps to the MSGID field


Maps to the MSG field


The Severity level used to calculate thePRI


Maps to the TIMESTAMP field


The Facility level used to calculate the PRI