Skip to main content
Version: 50.0.0

Audit Logs

Audit Logs​

Audit logs allow platform operators to see what actions were triggered, when, and by whom, providing a sense of accountability in every step of a process. The creation of these logs is disabled by default.

Enable Audit Logs in a9s Service Broker​

To enable the audit logs in the a9s Service Broker the a9s Data Services must be deployed with the Ops file: ops/enable-service-broker-audit-logs.yml. The destination endpoints must be passed to this Ops file using a variable array. The audit log file is rotated on a daily base and the audit log file from the last day is kept in case that there was an issue while streaming the logs.

For example:

$ bosh deploy -d postgresql-service postgresql-service/postgresql-service.yml \
    -l config/iaas-config \
    -l config/postgresql.yml \
    -o ops/enable-service-broker-audit-logs.yml \
    -v audit_endpoints="[foo.example.com:3000, bar.example.com:4321]" \

Enable Audit Logs in a9s Backup Manager​

To activate the audit logs in the a9s Backup Manager the a9s Data Services must be deployed with the Ops file: ops/enable-backup-manager-audit-logs.yml. The destination endpoints must be passed to this Ops file using a variable array. The audit log file is rotated on a daily base and the audit log file from the last day is kept in case that there was an issue while streaming the logs.

For example:

$ bosh deploy -d backup-service backup-service/backup-service.yml \
    -l config/iaas-config.yml \
    -o ops/enable-backup-manager-audit-logs.yml \
    -v audit_endpoints="[foo.example.com:3000, bar.example.com:4321]" \

Audit Logs Format​

The audit logs format follows the Common Event Format (CEF) standard, a well defined audit logging format that can be sent via the syslog protocol. For more information see here.

The message sent over the syslog protocol follows the format shown below:

CEF:Version|Device Vendor|Device Product|Device Version|Signature|ID|Name|Severity|Extension

Where the values are such:

  • Version: An integer that identifies the version of the CEF format. We use Version 0
  • Device Vendor: A string that uniquely identifies the sending device vendor
  • Device Product: A string that uniquely identifies the type of sending device product
  • Device Version: A string that uniquely identifies the type of sending device version
  • Signature ID: A unique identifier per event-type
  • Name: A string representing a human-readable and understandable description of the event
  • Severity: An integer ranging from 0 to 10, with 10 being the most severe
  • Extension: A collection of key-value pairs, predefined by the CEF format

It is in this Extension parameter where the audit information is parsed to, using the following extension key-value pairs:

  • act: The action mentioned in the event (String 63)
  • app: The application level protocol, some example values are: HTTP, HTTPS, etc (String 31)
  • deviceExternalId: A name that uniquely identifies the device generating this event
  • deviceFacility: The facility generating this event. For example, Syslog has an explicit facility associated with every event
  • dtz: The timezone for the device generating the event
  • dvc: Identifies the device address that an event refers to in an IP network. The format is an IPv4 address. Example: 192.168.10.1
  • dvchost: The format should be a fully qualified domain name (FQDN) associated with the device node, when a node is available. Example: host.domain.com or host
  • dvcpid: Provides the ID of the process on the device generating the event
  • end: The time when the event ended (Date format MM dd yyyy HH:mm:ss)
  • outcome: Displays the event's status as success or failure (String 63)
  • reason: The The reason an audit event was generated (String 1043)
  • request: The URL accessed, protocol included (String 1023)
  • requestClientApplication: The User-Agent associated with the request (String 1023)
  • requestMethod: The HTTP method used to access a URL. Possible values: POST, GET, etc. (String 1023)
  • src: Identifies the source that an event refers to in an IP network. Example: 192.168.10.1
  • start: The time when the event started (Date format MM dd yyyy HH:mm:ss)
  • suid: The ID of the user associated with the source of the event (String 1023)
  • suser: The username of the user associated with the event (String 1023). For more information see Variances Of The suser Field

The information sent through these extensions varies according to the application executing the logged event, there are even some additional extensions that aren't shared between the apps. Therefore, the following sections go over the application specific configuration.

Audit Logs Format For The a9s Backup Manager​

The configuration for the a9s Backup Manager's audit logs approximates the structure of the format mentioned above.

The CEF message's header fields have the following values for the a9s Backup Manager:

  • Device Vendor: anynines
  • Device Product: a9s Backup Manager
  • Device Version: The version of the a9s Backup Manager. Example: 1.3.5
  • Signature ID: backup_manager_api
  • Name: The URL path of the action which has been triggered. Example: /backup_agent/backup_all
  • Severity: The following severity levels are supported in the a9s Backup Manager:
    • 1 = response succeeded,
    • 4 = response failed because of client error,
    • 7 = failed because of server error

The CEF message's extension fields have the following values for the a9s Backup Manager:

  • cs1: The request parameters. Example: the ID of the restored backup
  • cs1Label: requestParameters
  • cs2: The id of the instance that was called in requests
  • cs2Label: InstanceID

Audit Logs Format For The a9s Service Broker​

The configuration for the a9s Service Broker's audit logs approximates the structure of the format mentioned above.

The CEF message's header fields have the following values for the a9s Service Broker:

  • Device Vendor: anynines
  • Device Product: a9s Service Broker
  • Device Version: The version of the a9s Service Broker. Example: 1.3.5
  • Signature ID: broker_api
  • Name: The URL path of the action which has been triggered. Example: /v2/service_instances/1234-5678-90123
  • Severity: The following severity levels are supported in the a9s Service Broker:
    • 1 = response succeeded,
    • 4 = response failed because of client error,
    • 7 = failed because of server error

The CEF message's extension fields have the following values for the a9s Service Broker:

  • deviceExternalId: The GUID of the a9s Service Broker

Variances of the suser Field​

It should be noted that the suser value will vary depending on the application that executed the logged event, as shown in the cases below:

  • In the case of the event originating on the a9s Service Dashboard, the suser value will be logged as the username that executed the logged event
  • In the case of the event originating on the Cloud Foundry, the suser value will not correspond to the username and instead the user_id will be logged in its place, which always has the prefix cf-. This is due to a limitation by Cloud Foundry on the OSBAPI's Originating header, since it as it has no access to the username and only provides the user_id
  • There are special cases that apply in every application: The System generated events and Unknown user events. For system generated events the suser will be logged as system, and for an event with an unknown origin of execution then the suser will be logged as unknown