Generating logs for auditing purposes

The logging of audit-able activities and events of a CP4BA production deployment can be enabled after installation by setting the sc_audit_logging.enabled custom resource (CR) parameter to true. An audit event is any activity that manages or manipulates sensitive data. Information about the activity provides accountability, traceability, and regulatory compliance of data access, data modification, and data security.

About this task

Cloud Pak for Business Automation includes an Audit Logging service (rsyslog process) that is designed to collect and validate audit events. The following Cloud Pak for Business Automation capabilities support the Audit Logging service.

Table 1. CP4BA capabilities that support the Audit Logging service
CP4BA capability Support For more information, see
Automation Document Processing Automation Document Processing audit log records
Business Automation Application Business Automation Application audit log records
Business Automation Navigator Business Automation Navigator audit log records
Business Automation Workflow Workflow automation audit log records
Decision Intelligence Client Managed Software Decision Intelligence Client Managed Software audit log records
Content Cortex Content Cortex audit log records
Note: Content Platform Engine (CPE), Content Management Interoperability Service (CMIS), and Business Automation Navigator can generate audit records.
Operational Decision Manager Operational Decision Manager audit log records
Table 2. CP4BA foundation capabilities that support the Audit Logging service
CP4BA foundation capabilities Support For more information, see
Business Automation Insights Business Automation Insights audit log records
Business Automation Navigator Business Automation Navigator audit log records
Business Automation Studio Business Automation Studio audit log records

The following Cloud Pak foundational services support the Audit Logging service.

Table 3. Cloud Pak foundational services that support the Audit Logging service
Cloud Pak foundational services Support For more information, see
Business Teams Service Business Teams Service audit log records External link opens a new window or tab
Identity Management (IM) Auditing IM service External link opens a new window or tab
Platform UI (Zen Service) Zen Service audit log records

The Audit Logging service is scoped to each CP4BA production deployment namespace. In a multi-tenant configuration, each Audit Logging service is configured and runs independently from services in other namespaces. Therefore, the audit log records from each CP4BA deployment are isolated from other namespaces. From a security and compliance perspective, the Audit Logging service makes sure that auditors for one tenant have visibility to records only for that tenant.

The Audit Logging service can also forward and persist the records to external Security Information and Event Management (SIEM) solutions. SIEM solutions can secure and enable auditing compliance queries. By default, the Audit Logging service is configured without SIEM, but you can add external SIEM configurations to the ConfigMap named zen-audit-config to forward the logs.

Note: When the Audit Logging service is enabled, the well-being of the rsyslog process is monitored. If the process stops running, the following messages are seen in the log to inform you that the rsyslog pod restarted.
Startup probe failed: Readiness probe successful. rsyslog is not running. Restarting pod.
...
Liveness probe failed: Liveness probe successful. rsyslog is not running. Restarting pod.

Procedure

  1. Configure your chosen external SIEM solution to export the audit records from your CP4BA deployment.

    For more information about specific SIEM solution instructions, see Exporting audit records to a SIEM solution External link opens a new window or tab.

  2. To enable the Audit Logging service, change the value of the sc_audit_logging.enabled CP4BA CR parameter to true.
    shared_configuration:
      sc_audit_logging:
        enabled: true
  3. Modify the CR Audit Logging parameters to configure the service for the entire deployment.
    Note: The audit_log_dir_size requires a minimum of (rolling_max_files x rolling_max_size) + 50 Mi.
    shared_configuration:
      sc_audit_logging:
        enabled: true
        audit_log_dir_size: 150Mi
        rolling_max_files: 5
        rolling_max_size: 20Mi
    Tip: If you want to overwrite the shared configuration settings for a capability in your CP4BA deployment, then add the parameters in the component sections of the CR.

    For more information, see Shared configuration custom resource parameters.

    The following example shows the CR parameters for Operational Decision Manager.

    odm_configuration:
      audit_logging:
        enabled: true
        rolling_max_files: 5
        rolling_max_size: 20Mi

    If you set the value of odm_configuration.audit_logging.enabled to false, then audit log records for the capability are not sent to the Audit Logging service, even when the shared_configuration.audit_logging.enabled parameter is set to true.

    After you apply the changes to the CP4BA CR, the Audit Logging service generates output from the CP4BA capabilities and forwards the records to the zen-audit pod stdout log.

  4. View the records in the zen-audit pod stdout log.

    To get the zen-audit pod name, run the following command.

    export POD_NAME=$(oc get pods -n <cp4ba-namespace> | grep zen-audit | awk {'print $1'})

    The stdout log is not intended for long-term audit record management as it is deleted when the zen-audit pod restarts, but the configuration helps you to confirm that all the records are forwarded properly to the zen-audit pod. It is recommended to use a SIEM solution for audit logging in the production environment.

    To view the audit log from the zen-audit pod with stdout configured run the following command.

    oc logs -f $POD_NAME
  5. Check whether the audit logs are generated in the component pods.

    To determine which component pods are generating audit events, run the following commands.

    export POD_NAME=$(oc get pods -n <cp4ba-namespace> | grep <component pod> | awk {'print $1'})
    oc rsh $POD_NAME
    ls -al /audit-logging/

    When the pod starts up, an empty log file is created under a directory named audit-logging. The file name has the format audit_$POD_NAME, and always starts with audit and ends with .log. The log is populated as soon as audit events are detected.

    Note: For CMIS and Business Automation Navigator, the audit log file, by default audit_<$POD_NAME>.log, is created in the same pod under the /audit-logging folder.

    For CPE, irrespective of the number of instances, a new pod (content-cpe-audit-deploy) is created, and the logs can be found in this pod.

    /audit-logging/audit_$POD_NAME.log
  6. Optional: Scale up or out the Audit Logging service.

    The Audit Logging service pod deployment (zen-audit) supports multiple replicas. By default, the zen-audit deployment is configured as a single replica with minimal memory and CPU load.