Chapter 9. Audit logs in Red Hat Developer Hub Audit logs are a chronological set of records documenting the user activities, system events, and data changes that affect your Red Hat Developer Hub users, administrators, or components. Administrators can view Developer Hub audit logs in the OpenShift Container Platform web console to monitor scaffolder events, changes to the RBAC system, and changes to the Catalog database. Audit logs include the following information: Name of the audited event Actor that triggered the audited event, for example, terminal, port, IP address, or hostname Event metadata, for example, date, time Event status, for example, success , failure Severity levels, for example, info , debug , warn , error You can use the information in the audit log to achieve the following goals: Enhance security Trace activities, including those initiated by automated systems and software templates, back to their source. Know when software templates are executed, as well as the details of application and component installations, updates, configuration changes, and removals. Automate compliance Use streamlined processes to view log data for specified points in time for auditing purposes or continuous compliance maintenance. Debug issues Use access records and activity details to fix issues with software templates or plugins. Note Audit logs are not forwarded to the internal log store by default because this does not provide secure storage. You are responsible for ensuring that the system to which you forward audit logs is compliant with your organizational and governmental regulations, and is properly secured. Additional resources For more information about logging in OpenShift Container Platform, see About Logging For a complete list of fields that a Developer Hub audit log can include, see Section 9.2.1, "Audit log fields" For a list of scaffolder events that a Developer Hub audit log can include, see Section 9.2.2, "Scaffolder events" 9.1. Configuring audit logs for Developer Hub on OpenShift Container Platform Use the OpenShift Container Platform web console to configure the following OpenShift Container Platform logging components to use audit logging for Developer Hub: Logging deployment Configure the logging environment, including both the CPU and memory limits for each logging component. For more information, see Red Hat OpenShift Container Platform - Configuring your Logging deployment . Logging collector Configure the spec.collection stanza in the ClusterLogging custom resource (CR) to use a supported modification to the log collector and collect logs from STDOUT . For more information, see Red Hat OpenShift Container Platform - Configuring the logging collector . Log forwarding Send logs to specific endpoints inside and outside your OpenShift Container Platform cluster by specifying a combination of outputs and pipelines in a ClusterLogForwarder CR. For more information, see Red Hat OpenShift Container Platform - Enabling JSON log forwarding and Red Hat OpenShift Container Platform - Configuring log forwarding . 9.2. Viewing audit logs in Developer Hub Administrators can view, search, filter, and manage the log data from the Red Hat OpenShift Container Platform web console. You can filter audit logs from other log types by using the isAuditLog field. Prerequisites You are logged in as an administrator in the OpenShift Container Platform web console. Procedure From the Developer perspective of the OpenShift Container Platform web console, click the Topology tab. From the Topology view, click the pod that you want to view audit log data for. From the pod panel, click the Resources tab. From the Pods section of the Resources tab, click View logs . From the Logs view, enter isAuditLog into the Search field to filter audit logs from other log types. You can use the arrows to browse the logs containing the isAuditLog field. 9.2.1. Audit log fields Developer Hub audit logs can include the following fields: eventName The name of the audited event. actor An object containing information about the actor that triggered the audited event. Contains the following fields: actorId The name/id/ entityRef of the associated user or service. Can be null if an unauthenticated user accesses the endpoints and the default authentication policy is disabled. ip The IP address of the actor (optional). hostname The hostname of the actor (optional). client The user agent of the actor (optional). stage The stage of the event at the time that the audit log was generated, for example, initiation or completion . status The status of the event, for example, succeeded or failed . meta An optional object containing event specific data, for example, taskId . request An optional field that contains information about the HTTP request sent to an endpoint. Contains the following fields: method The HTTP method of the request. query The query fields of the request. params The params fields of the request. body The request body . The secrets provided when creating a task are redacted and appear as * . url The endpoint URL of the request. response An optional field that contains information about the HTTP response sent from an endpoint. Contains the following fields: status The status code of the HTTP response. body The contents of the request body. isAuditLog A flag set to true to differentiate audit logs from other log types. errors A list of errors containing the name , message and potentially the stack field of the error. Only appears when status is failed . 9.2.2. Scaffolder events Developer Hub audit logs can include the following scaffolder events: ScaffolderParameterSchemaFetch Tracks GET requests to the /v2/templates/:namespace/:kind/:name/parameter-schema endpoint which return template parameter schemas ScaffolderInstalledActionsFetch Tracks GET requests to the /v2/actions endpoint which grabs the list of installed actions ScaffolderTaskCreation Tracks POST requests to the /v2/tasks endpoint which creates tasks that the scaffolder executes ScaffolderTaskListFetch Tracks GET requests to the /v2/tasks endpoint which fetches details of all tasks in the scaffolder. ScaffolderTaskFetch Tracks GET requests to the /v2/tasks/:taskId endpoint which fetches details of a specified task :taskId ScaffolderTaskCancellation Tracks POST requests to the /v2/tasks/:taskId/cancel endpoint which cancels a running task ScaffolderTaskStream Tracks GET requests to the /v2/tasks/:taskId/eventstream endpoint which returns an event stream of the task logs of task :taskId ScaffolderTaskEventFetch Tracks GET requests to the /v2/tasks/:taskId/events endpoint which returns a snapshot of the task logs of task :taskId ScaffolderTaskDryRun Tracks POST requests to the /v2/dry-run endpoint which creates a dry-run task. All audit logs for events associated with dry runs have the meta.isDryLog flag set to true . ScaffolderStaleTaskCancellation Tracks automated cancellation of stale tasks ScaffolderTaskExecution Tracks the initiation and completion of a real scaffolder task execution (will not occur during dry runs) ScaffolderTaskStepExecution Tracks initiation and completion of a scaffolder task step execution ScaffolderTaskStepSkip Tracks steps skipped due to if conditionals not being met ScaffolderTaskStepIteration Tracks the step execution of each iteration of a task step that contains the each field. 9.2.3. Catalog events Developer Hub audit logs can include the following catalog events: CatalogEntityAncestryFetch Tracks GET requests to the /entities/by-name/:kind/:namespace/:name/ancestry endpoint, which returns the ancestry of an entity CatalogEntityBatchFetch Tracks POST requests to the /entities/by-refs endpoint, which returns a batch of entities CatalogEntityDeletion Tracks DELETE requests to the /entities/by-uid/:uid endpoint, which deletes an entity Note If the parent location of the deleted entity is still present in the catalog, then the entity is restored in the catalog during the processing cycle. CatalogEntityFacetFetch Tracks GET requests to the /entity-facets endpoint, which returns the facets of an entity CatalogEntityFetch Tracks GET requests to the /entities endpoint, which returns a list of entities CatalogEntityFetchByName Tracks GET requests to the /entities/by-name/:kind/:namespace/:name endpoint, which returns an entity matching the specified entity reference, for example, <kind>:<namespace>/<name> CatalogEntityFetchByUid Tracks GET requests to the /entities/by-uid/:uid endpoint, which returns an entity matching the unique ID of the specified entity CatalogEntityRefresh Tracks POST requests to the /entities/refresh endpoint, which schedules the specified entity to be refreshed CatalogEntityValidate Tracks POST requests to the /entities/validate endpoint, which validates the specified entity CatalogLocationCreation Tracks POST requests to the /locations endpoint, which creates a location Note A location is a marker that references other places to look for catalog data. CatalogLocationAnalyze Tracks POST requests to the /locations/analyze endpoint, which analyzes the specified location CatalogLocationDeletion Tracks DELETE requests to the /locations/:id endpoint, which deletes a location and all child entities associated with it CatalogLocationFetch Tracks GET requests to the /locations endpoint, which returns a list of locations CatalogLocationFetchByEntityRef Tracks GET requests to the /locations/by-entity endpoint, which returns a list of locations associated with the specified entity reference CatalogLocationFetchById Tracks GET requests to the /locations/:id endpoint, which returns a location matching the specified location ID QueriedCatalogEntityFetch Tracks GET requests to the /entities/by-query endpoint, which returns a list of entities matching the specified query

Commands: