What is an Audit Trail?

Audit trails are electronic records that chronologically catalog events related to operational procedure or change.
In the context of Continuous Delivery, it’s basically the who, what and when of all activity relating to the contents, dependencies, and execution of your deployment pipelines.

Why does Continuous Delivery need an Audit Trail?

Simply put, audit trails provide proof of compliance and operational integrity when it comes to how organizations deliver software and manage change.
Without audit trails, organizations would be blind to answering the most basic of questions like “Who did what when?”
For many financial and retail organizations, audit trails enable proof of compliance, and proof of compliance enables them to legally trade. It’s that simple.
In a typical enterprise, you might have 10s of business units, 100s of dev teams, and 1000s of software engineers. Keeping an accurate audit of who did what when is therefore not a trivial task given that every application, environment, and tech stack is different.
I’ve personally heard stories of developers in many organizations using kubectl to directly update production clusters on-the-fly using their laptop. Compliance and operational integrity this is not.

How does the Audit Trail work in Harness?

The Harness Audit Trail can be found under the Continuous Security navigation drop-down:
harness audit trail
You should then see something like this (an audit trail of beauty):

In the above screenshot, the audit trail shows that I (Stephen Burton) created a new Service, Environment, Deployment Workflow, and Pipeline in just 3 minutes.
Harness basically captures and audits the timestamp, event source, resource and details of all user-level transactions (e.g. create, update, delete, execute, …)
Audit trails by default are persisted for one year.

Highlighting Diffs in Detail

Harness also audits and shows detailed differences for all updates.
For example, let’s say that I updated phase-2 of my canary deployment workflow from 50% of containers to 63%:

Harness would audit and log that change as follows:
canary_diff
Clicking on the “YAML Diff” icon (highlighted above) would then show the exact differences from the update:
change_differences
As you can see, the audit trail confirms that phase-2 of my canary deployment was updated to 63% of containers from 50%.
This detailed diff audit view is available for any component or config (e.g. Kubernetes manifests, environment variables, triggers, …) within your deployment pipelines.

It’s pretty awesome!

Feel free to kick the tires with our free trial.
Cheers,
Steve.

Keep Reading

  • The Women of DevOps: Patricia Anong

    The Women of DevOps: Patricia Anong

    Meet Patricia Anong, DevOps Consultant. We're thrilled for you to meet her!
  • Introduction to Helm: Charts, Deployments, & More

    Introduction to Helm: Charts, Deployments, & More

    Probably one of the first packages installed after your Kubernetes cluster is up and running is Helm. A stalwart in the Kubernetes ecosystem, Helm is a package manager for Kubernetes. If you are unfamiliar with Helm, Helm helps users to have a more consistent deployment by packaging up all of the needed resources needed for a Kubernetes deployment.
  • GitOps Got Me Up

    GitOps Got Me Up

    Two years ago, I joined the technology space - and as such, I am now a strong proponent for DevOps methodologies.