Back to Writing

Writing · 21 May 2026

GitOps was sold as a delivery mechanism. In a regulated environment, the audit trail is the point.

GitOps tooling gets pitched on convenience: declarative state, automatic reconciliation, drift correction without a human running a deploy script at 2am. Those are real, useful properties. In a regulated platform, they're not the reason ArgoCD earns its place. The reason is that every change to what's actually running in the cluster now has a commit behind it: who proposed it, who reviewed it, when it merged, when it synced.

The question an auditor actually asks

Eventually someone asks who changed what, when, and with whose sign-off. GitOps answers that by construction instead of through a change-management system bolted on after the fact. The Git history is the change log. The pull request review is the sign-off record. The sync timestamp is the “when.” None of that is a report generated after the fact from someone's memory of what happened; it's the same artifact that caused the change to happen in the first place.

What imperative operations leave behind instead

Run kubectl apply or oc patch directly against a cluster and you get the change immediately, with no equivalent record unless someone remembers to log it somewhere else. Manual change logs drift out of sync with reality the moment anyone's in a hurry, and in an incident, everyone's in a hurry. The gap between what a change log says happened and what a cluster actually did is exactly where an audit finding lives.

Designing the repo around this, not retrofitting it

A few structural choices make the audit-trail property real instead of incidental:

  • Every environment promotion is its own commit or PR, not a manual sync click with no record of why it happened.
  • Drift detection isn't just a convenience feature. An application showing OutOfSync is itself a finding: something touched the cluster outside the recorded process, and that's worth knowing regardless of whether the drift was benign.
  • Least privilege has to extend to who can merge into the branches ArgoCD watches, not just who holds cluster RBAC. The Git permission boundary is the change-approval boundary now; get that wrong and the audit trail has a hole in it that no amount of cluster-level RBAC fixes.

Right-sizing, secrets management, and multi-year cost modeling are all still real operational concerns on a platform like this. But the property that actually comes up in an audit is this one, and it's far cheaper to design the repo structure and merge policy around it from the start than to retrofit an audit trail onto a year of undocumented changes after the fact.

Back to Writing