BuildPiper
Governance & Audit
Compliance

BP Audit Trail #

As BuildPiper is a mission-critical platform, comprehensive audit visibility is essential for governance, accountability, troubleshooting, and security investigations. BuildPiper provides multiple layers of audit logging and activity tracking to ensure operational transparency.

On This Page

▸BP Audit Trail Overview
▸Default Audit Trail
▸Audit Log Filtering
▸Pod-Level SSH Audit Tracking

1. BP Audit Trail Overview #

BuildPiper’s audit framework operates at multiple layers — capturing both user-initiated configuration changes through the UI and direct access events against running Kubernetes workloads. This dual visibility supports compliance, root-cause analysis, and security investigations.

Governance & Accountability

Every configuration change, deployment action, and administrative event is attributed to a user — supporting accountability and compliance reporting.

Multi-Layer Audit Logging

UI-level configuration tracking and pod-level SSH session tracking provide layered visibility — covering both control-plane and runtime access events.

Default Audit Trail #

BuildPiper includes a built-in audit logging framework that is enabled by default. This audit mechanism captures user actions performed through the BuildPiper UI and provides visibility into platform-level operational changes.

Enabled by Default: No additional setup or activation is required — audit logging is operational from the moment BuildPiper is deployed.

What Gets Captured #

The default audit trail records key user-driven actions across the platform.

CREATE
Resource Creation

UPDATE
Resource Modification

DELETE
Resource Deletion

CONFIG
Pipeline Configuration Changes

CONFIG
Job Template Updates

CONFIG
Environment Configuration Changes

DEPLOY
Deployment-Related Changes

ADMIN
Administrative UI Actions

BP Snapshot: BuildPiper Change Log showing the captured audit trail.

Audit Log Filtering #

Users can efficiently search and narrow down audit records in the BP Change Log using the available filtering options. These filters help quickly locate specific audit events instead of manually browsing through large audit datasets.

Filter Option	Purpose	Example Use Case
Change Type	Filters audit logs based on the type of action performed on an entity.	Find only `CREATE`, `UPDATE`, or `DELETE` operations.
Entity Type	Filters records based on the type of BuildPiper resource that was modified.	Search for changes to Services, CI Details, CD Details, Service Environment Variables, Global Job Templates, etc.
More Filters	Provides advanced filtering options for precise searches.	Search by a specific user, entity name, etc.
Clear Filters	Removes all active filters and resets the audit view.	Useful when starting a new search after applying multiple filters.
Pagination / Go to Page	Navigate directly through large audit datasets.	Jump to a specific page number when reviewing historical audit records.

Pod-Level SSH Audit Tracking #

In addition to configuration and resource activity, the default UI audit trail also tracks pod-level SSH access history.

Whenever a user initiates an SSH session into a Kubernetes pod through BuildPiper, the activity is recorded as part of the audit history — creating a complete trail of runtime access events alongside configuration changes.

SSH Audit Visibility Includes #

WHO
User Identity

Which user initiated the pod access.

WHAT
Pod Accessed

Which Kubernetes pod was accessed.

WHERE
App / Service Context

Target application or service the pod belongs to.

WHEN
Access Timestamp

Timestamp of access for chronological reconstruction.

HISTORY
Session Initiation History

Full session-start record retained for accountability and review.

Important: This capability is particularly critical in environments where production troubleshooting or live debugging access is permitted — providing the audit evidence required for both internal review and external compliance audits.

BuildPiper Documentation · BP Audit Trail

Last updated: May 2026