Argo CD / Generated systems and controlled recovery / Lesson 18

Governance, source verification, and versioned change

Maintain delivery policy and platform compatibility without confusing signed input with approved behavior.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish source authenticity, candidate policy, and target authorization.
Plan a reviewed upgrade or policy change with representative negative cases.

Authentic source still needs an acceptance policy

Argo CD supports documented Git signature-verification mechanisms that can help establish source authenticity under configured trusted keys and project rules. A valid signature does not prove harmless manifests, approved values, correct container bytes, or compatibility with current data. Parcel’s acceptance policy still needs expected source, reviewed generation inputs, allowed target scope, and meaningful verification. Keep signing identity and repository-writing authority protected. This course creates no key, imports no trust material, verifies no real commit, and performs no source or target operation.

The delivery chain extends beyond one Git commit

A signed configuration can reference a mutable image tag or chart dependency. Review actual package identity, dependency origin, generation toolchain, and any authenticated provenance needed by the consumer. Do not claim that enabling one verification feature secures every supply-chain link. A source-policy exception should name its scope, owner, reason, expiry, and compensating evidence. Avoid disabling verification globally because one source fails a legitimate check. Preserve the rejected evidence and investigate whether source identity, trust configuration, or an actual unauthorized change explains the failure.

Describe a bounded policy review

The JSON record below is a synthetic review request, not Argo CD project configuration or a signed attestation. It requires independent source, scope, and compatibility evidence. A real decision needs authenticated authority and candidate binding. Changing a project, diff exception, health check, or ApplicationSet template can alter many applications without changing their workload repositories, so include affected consumers and rollback constraints. Governance should make those consequences visible rather than relying on a vague approval label attached to unknown future inputs.

json A synthetic delivery-policy review record

{"change":"parcel-delivery-policy-lab","required":["source-authenticity","target-scope","state-compatibility"],"affected":"declared-lab-applications","decision":"review-required"}

The labels do not represent a real approval, key, token, policy object, or attestation. No verification feature or Application setting is changed.

Upgrade review needs the actual version path

The course’s release-3.1 documentation baseline is a learning snapshot, not a recommendation to install that version or a support claim. A real upgrade must use the official guidance for the installed and intended versions, including intervening changes where required. Review CRDs, configuration fields, RBAC semantics, renderer versions, custom health logic, ApplicationSet behavior, and dependency compatibility. Retain protected recovery material and representative fixtures. This course installs, upgrades, restarts, exports, imports, and administers nothing; operational validation belongs to a separately authorized environment and owner.

Keep independent review conditions conjunctive

The complete local predicate below accepts a synthetic candidate only when source authentication, permitted scope, and state compatibility are all present. It rejects a signed candidate with an unacceptable target or incompatible state. It is not cryptographic verification, Argo CD RBAC, or a complete supply-chain policy. The model shows why one favorable signal cannot replace the rest. Add negative cases for missing source evidence, changed candidate, stale health, generator removal, repeated resources, and failed hooks in the actual reviewed validation plan.

python A synthetic multi-condition acceptance model

def acceptable(authenticated_source, permitted_scope, compatible_state):
    return all((authenticated_source, permitted_scope, compatible_state))
print(acceptable(True, False, True))
print(acceptable(True, True, False))
print(acceptable(True, True, True))

Expected output

False
False
True

Only booleans are evaluated. No signature, source repository, policy, cluster, controller version, or recovery artifact is inspected.

Common errors and fixes

A signed commit is treated as proof that every referenced artifact is trusted.

Why it happens: Source authenticity was stretched into the whole dependency and target chain.
How to fix it: Review package identity, rendering inputs, policy, and compatibility separately.
Prevent it next time: Document what each verification mechanism establishes.

Verification is disabled globally for one failing candidate.

Why it happens: A narrow exception is replaced by removal of the shared trust boundary.
How to fix it: Investigate the failure and review a bounded authorized exception if justified.
Prevent it next time: Retain owner, expiry, reason, and affected candidate identity.

A versioned teaching example is copied into an incompatible installation.

Why it happens: Documentation baseline was confused with installed feature support.
How to fix it: Review the actual version path and supported configuration before adoption.
Prevent it next time: Maintain compatibility fixtures and evidence for platform changes.

Check your understanding

1. A source signature is valid but the generated resource targets an unapproved namespace. Is the candidate acceptable?

Show worked solution

Not under a policy requiring permitted scope. Authenticity identifies a trusted claim or authoring path; it does not authorize every resulting action. Review the target and project constraints and preserve the rejection rather than weakening the boundary.

2. What should an upgrade rehearsal cover beyond successful startup?