GitOps Supply-Chain Security for Tenant Releases: From Commit to Rollback

Direct answer

A secure GitOps supply chain for tenant releases requires signed source commits, immutable artifacts, policy-based admission control, and tenant-scoped rollback provenance. OpenTenant compiles these controls into a reviewable deployment chain: every change from commit to rollout is attested, verified, and auditable per tenant.

The supply chain components

Signed source. Git commits are signed with GPG or Sigstore. Each tenant repository enforces signed commits before merging. The commit signature and author are recorded in the deployment provenance.

Immutable artifacts. Container images and Helm charts are built once, signed, and stored in an immutable registry. Each artifact is identified by its digest, not a mutable tag. Signed attestations (SLSA provenance, SBOM) are stored alongside the artifact.

Policy admission. Before a tenant release is deployed, policy checks verify:

The image is from an approved registry and signed by a trusted authority
The Helm chart has passed security scanning
The configuration does not violate tenant isolation boundaries
The deployment matches the approved Git revision

Tenant-scoped rollback. Every deployment records the source revision, artifact digest, configuration hash, and reconciliation result. Rollback restores the previous known-good state—not by re-running Helm, but by reverting to the attested artifact and configuration that was previously verified.

Reference architecture

commit signed → build → artifact signed + attested
  → policy admission (image signing, vulnerability scan, tenant boundary)
  → Helm release rendered from attested chart
  → deployment observed and recorded
  → rollback to previous attested revision

OpenTenant's role is to make this supply chain tenant-scoped. Each tenant has its own source repositories, artifact registries, policy bindings, and deployment history.

Illustrative tenant declaration

tenant: acme
source:
  repo: [email protected]/tenants/acme/app
  branch: main
  signed: required
artifact:
  registry: registry.acme.com/tenants/acme
  signing: cosign
  attestations: slsa-provenance, sbom
policy:
  admission:
    - image-signature
    - vulnerability-scan
    - tenant-boundary
rollback:
  retention: 30 days
  provenance: required

This is illustrative. Production declarations should reference specific policy configurations and attestation formats.

Production decisions before onboarding

Signing infrastructure. Choose GPG for commits and Cosign or Sigstore for artifacts. Store signing keys securely and rotate them periodically.

Attestation format. SLSA provenance provides build integrity. SBOM provides component inventory. Both should be stored alongside artifacts in the registry.

Policy engine. Use OPA, Kyverno, or similar for admission control. Policies must be tenant-scoped: tenant A's policy should not affect tenant B's deployments.

Rollback strategy. Rollback should restore the previous known-good revision, not just re-run Helm. The rollback provenance must record why the rollback occurred and what state was restored.

Evaluation checklist

Are commits signed and verified per tenant repository?
Are artifacts built, signed, and stored immutably?
Are SLSA provenance and SBOM attestations generated and stored?
Does policy admission verify image signatures and vulnerability status?
Does policy admission enforce tenant isolation boundaries?
Is rollback provenance recorded and reviewable?
Can a rollback restore the previous known-good revision?

Sources

OpenTenant brings supply‑chain security to tenant operations: every deployment is provably built, verified, and reversible.