Authentication and authorization audit logs

Your product generates authentication and authorization audit logs. The auth-idp service generates authentication audit events and auth-pdp service generates authorization audit logs.

The Platform UI (Zen) service also generates some authorization audit logs. To view these audit logs, you must create the zen-audit-config configmap.

The audit logs contain the following fields.

Table 1. Authentication and authorization audit log data
Field name	Data saved	Description	Example
initiator.id	Source of an action	ID of the source that initiated the action	LDAP ID; ID of an API key
initiator.typeURI	URI of the source	URI of the source of action	service; user
initiator.credential.type	Type of ID	Type of ID of the source of action	token; API key
target.name	Target of an action	The endpoint on which the action is initiated.	service; resource
target.id	ID of the target	Cloud Resource Name (CRN) value of the service or resource	crn:v1:icp:private:platform-service:::core:service:metering-service
target.typeURI	URI of the target	URI of the target on which the action is initiated.	resource; API key; secret
action	Action that is requested	The action that triggers an event.	create; update; delete; deploy; authenticate
outcome	Result of the action		success; pending; failure
reason.reasonCode	HTTP response code	The response code of the result.	200 for success
severity	Severity level	The severity level of the event.	critical; normal
eventTime	Timestamp	The time, date, and time zone of the event.	2018-04-20 20:15:00.32 +0000 UTC

All create, read, update, and delete operations that are related to a directory, user, user group, and team are logged.

Each service that generates audit data writes audit records to a /var/log/audit/<service_name>-audit.log file inside the audit sidecar container in the respective pod. For example:

Authentication logs are saved to the /var/log/audit/platform-identity-management-audit.log file.
Authorization logs are saved to the /app/logs/audit/pdp-audit.log file.

The /var/log/audit directory is shared with the audit container, which is a sidecar container. An emptyDir volume is used for sharing the /var/log/audit directory between the two containers. The audit container (also known as auto agent) sends the data to systemd journal.

You can use a security information and event management (SIEM) tool of your choice to view these logs.

zen-audit-config configmap

You can publish the audit logs to the zen-audit pod stdout logs on your cluster.

Create a custom configmap to export your audit records to the zen-audit pod stdout logs on the cluster. Complete these steps from your cluster node.

Log in to the cluster by using the oc login command.
Change to the project where your IBM Cloud Pak is installed.
```
oc project <IBM Cloud Pak-namespace}}>
```

Create the configmap. You can use a custom name for the configmap. The default zen-audit-config name is used in the following steps. {: #create-cm}

cat <<EOF | oc apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: zen-audit-config
  namespace: <IBM Cloud Pak-namespace}}>
data:
  fluent.conf: |-
    <match export export.** records records.** syslog syslog.**>
      @type copy
      <store>
        @type stdout
      </store>
    </match>
EOF

Patch the zenService custom resource to specify the custom configmap.

oc patch zenService lite-cr \
-n <IBM Cloud Pak-namespace}}> \
--type="json: \
--patch '[{"op": "replace", "path":"/spec/zen_audit_config_custom", "value": 'zen-audit-config' }]'

Delete all zen-audit pods to force a restart to pick up changes. {: #delete-pods}
1. Get the names of all zen-audit pods.
```
oc get pods | grep zen-audit
```
2. Delete the zen-audit pods. Repeat the command for each zen-audit pod.
```
oc delete pod <zen-audit-pod-name>
```
You can now see the audit events in the zen-audit pod stdout logs.