Learn GitOps with ArgoCD - Compliance & Audit

#Introduction

In episode 23 we built layered security — authentication, RBAC, networking, and supply chain. There's one side effect you may not have noticed: every layer produces evidence. In this episode we harness it: compliance & audit. Because in GitOps, the answer to an auditor's question "who changed what, when, and who approved it" isn't a painstakingly produced report — it's a natural artifact of Git and ArgoCD logs.

Why does this matter? Standards like SOC 2, HIPAA, and PCI-DSS penalize organizations that can't prove their controls. Traditionally, proving deployment controls meant giant pipelines recorded in spreadsheets — expensive and never accurate. GitOps flips it: because every deployment change is a commit signed by its author, the audit trail exists by default. Our only job is to assemble it into presentable evidence.

#Audit Logging

The GitOps audit trail has three complementary layers:

1. Git commit history — the source of truth for configuration changes: author, time, message, and diff.
2. ArgoCD audit logs — API server actions: who logged in, who triggered a sync, from where.
3. Controller logs — automatic work: reconcile, sync operations, failures.

Enable API server audit logging by adding the --audit-log-path argument to the argocd-server deployment:

spec:
  template:
    spec:
      containers:
        - name: argocd-server
          args:
            - /usr/local/bin/argocd-server
            - --audit-log-path=/var/log/audit.log
            - --audit-log-format=json

With JSON format, every API action is recorded with the user, resource, action, and IP — the raw material for answering "who ran a sync at 3 AM?". At the Git layer, the whole commit history is accessible to anyone without additional tooling:

git log --oneline --all -- manifests/overlays/prod/api
git show --stat <commit>

Note that both must be connected: the commit in Git is the decision, the ArgoCD log is the execution. An application changes manifests (commit abc123), then the sync is recorded in the ArgoCD audit log. For a complete trail, you need both.

#Compliance Requirements

Each standard has a different emphasis; GitOps turns them from "heavy work" into "routine verification":

#Change Approval Workflows

Auditors want to see a process before changes reach production. In GitOps, that process is a pull request with review:

1. A developer changes manifests on a feature/x branch.
2. CI runs manifest validation (lint, helm template, the policy checks from episode 23).
3. Two reviewers approve the pull request; branch protection blocks the merge without it.
4. Merging to main triggers ArgoCD to sync — a recorded execution.

Each step produces an auditable trail. This is the perfect example of "an audit trail that forms because of the workflow, not because of a report".

#Audit Trail: Who, What, When

The core audit question: who changed what, when. Git provides the who and when; argocd app history provides what changed on the execution side:

Deployment history

argocd app get api --history
argocd app rollback api 3
argocd app get api --refresh

Each history line records the manifest revision, sync time, and triggering user. Rollbacks are recorded too — important for answering "what happened during the incident?". A complete audit trail has four parts: decision (commit), approval (review), execution (sync), and recovery (rollback). GitOps stores them all.

#Reporting

A control that isn't measured can't be improved. DORA metrics — now the common language of engineering — can be computed directly from Git and ArgoCD logs:

• Change frequency — how often main changes per period; computed from the number of commits/merges per day.
• Lead time — the time from the first commit to a successful deploy; measured from git log to the Synced status in ArgoCD.
• MTTR (Mean Time To Recovery) — the time from incident detection to a healthy application; computable from the duration of Degraded/OutOfSync status in metrics (episode 22).

Example query for computing how long an app was unhealthy:

time() - max(argocd_app_sync_status{sync_status="OutOfSync"} == 1) by (name)

Compliance reports then become dashboards (episode 22) and periodic exports: a weekly list of changes, the list of active accesses, and an incident summary with a recovery timeline. If an audit demands it, all these reports link directly to the raw evidence — a commit or log.

#Policy as Code

The final step: make sure the policies themselves are managed like code — in Git, reviewed, and automatically enforced.

#OPA and Kyverno

Both tools run policies as admission webhooks: every resource about to be applied (including by ArgoCD) is inspected before entering the cluster.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-owner-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-team-label
      match:
        resources:
          kinds:
            - Namespace
      validate:
        message: "Namespace harus punya label team"
        pattern:
          metadata:
            labels:
              team: "?*"

The power of the GitOps + policy-as-code combination: policies are stored in the same repo, applied to the cluster by ArgoCD, and run by the webhook when resources are applied. The result is a closed loop — policies can be audited like code, and violations are rejected with a clear message.

#Policy Validation in CI

To catch violations earlier, run policy validation in the CI pipeline: kubectl kustomize produces the manifests, then conftest test (OPA) or kyverno apply checks them before the merge. A pull request that violates policy is rejected before it ever touches the cluster — cheaper than fixing it in production.

#Closing

This episode turned GitOps into a compliance engine: ArgoCD audit logs and Git history as three layers of evidence, SOC 2/HIPAA/PCI-DSS considerations, change approval workflows via pull requests, an audit trail answering who-changed-what-when, reporting with DORA metrics and MTTR, and policy as code with OPA and Kyverno.

The points you should take with you:

• The GitOps audit trail is a natural artifact: commit, review, sync, and rollback.
• Enable --audit-log-path on the API server to trace user actions.
• A pull request with branch protection is an auditable change approval workflow.
• DORA metrics can be computed directly from Git and ArgoCD metrics.
• Policies as code are reviewed, applied with GitOps, and enforced automatically.

Complete evidence makes audits feel light. But a healthy system must also be fast — and the more resources ArgoCD manages, the more its performance burden is felt. In the next episode 25 we discuss performance tuning & optimization — repo optimization, controller tuning, large scale, and cluster performance. See you in episode 25!