Drift management — running vs approved, proven by digest

What is running, versus what was approved — continuously, by digest.

Tags lie. Digests do not. SARC keys compliance on the SHA256 image digest, so “drift” is a fact, not a guess.

Compliance is easy to claim at deploy time. The hard question is the one an auditor actually asks three months later: is the thing running right now still the thing you approved? SARC answers it continuously. A reporter snapshots each namespace into Fides; Fides compares every running container’s digest against the artifacts it attested for that environment; the portal shows the verdict.

The signal

running pod digest  !=  any Fides-attested artifact digest
    -> running[].registered = false
    -> shadowChanges[]                      (karc-portal/src/lib/fides.ts)
    -> environment card NON_COMPLIANT        (DashboardEnvironmentRow.tsx)

⛶ Fullscreen

flowchart LR
A["Pipeline build + attest<br/>(digest signed, SBOM, scans)"] --> B["Fides trail<br/>attested artifacts"]
C["Cluster<br/>running pods"] --> D["fides-reporter CronJob<br/>snapshot running digests"]
D --> E{"digest in<br/>attested set?"}
B --> E
E -->|yes| F["registered: true<br/>COMPLIANT"]
E -->|no| G["shadowChanges[]<br/>NON_COMPLIANT"]

Two things this demonstrates

1. Detection. The portal computes compliance from what is actually running, by digest. On the live aws-karc-dev environment, six podtato-head containers match their attested digests and two others run digests outside the attested set — so the environment card is already NON_COMPLIANT, with no ticket filed.

2. Auto-remediation. On dev and qa, the ArgoCD Applications carry automated: { selfHeal: true }. Push an unapproved image straight to the cluster and ArgoCD reverts it to the approved digest within seconds — you cannot successfully drift a self-healing environment.

# detection: show the environment's real drift state
just demo-drift-status   dev aws

# auto-remediation: inject a shadow deploy, watch ArgoCD revert it
just demo-drift-selfheal dev aws

# both, narrated end to end
just demo-drift          dev aws

Verified live output of the self-heal:

>> INJECT drift: karc-dev/podtato-head-entry -> ghcr.io/podtato-head/podtato-server:v0.3.2
   (an image digest Fides has never attested for env aws-karc-dev)
deployment "podtato-head-entry" successfully rolled out
>> watching ArgoCD self-heal podtato-head-aws-dev...
>> ArgoCD reverted the drift to the attested digest.

Prod is different — drift is held, not healed

Prod ArgoCD auto-sync is off by policy (gitops/apps/podtato-head/prod/ sync-policy.yaml has no automated block) and a PreSync hook asserts an approved ServiceNow CR before any sync. So in prod an unapproved change never lands, and a genuine drift stays OutOfSync and visible until a human with a CAB-approved change record syncs it. Detect-and-auto-correct below prod; detect-and-hold at prod.

What makes this credible

• Digest, not tag. SHA256 is content-addressed; it cannot drift. The ServiceNow CR/CMDB link (u_image_digest) is the one link that cannot drift either.
• Continuous, not point-in-time. The fides-reporter CronJob (infra/modules/cluster-bootstrap/fides-reporter.tf) reports every namespace to env <cloud>-karc-<env> on a schedule; the demo just triggers the same snapshot on demand.
• Enforced, not just reported. Below prod ArgoCD self-heals; at prod a change gate holds. Fides advises (verdict + risk score); ServiceNow decides.

The full presenter runbook — narration, prerequisites, the ApplicationSet self-heal reality, and honest limitations — lives at docs/demo/DRIFT-DEMO.md in the repo.