Docker Content Trust Retirement: Migration Checklist for CI and Kubernetes

admin

3 hours ago

Docker Content Trust retirement migration checklist for CI pipelines and Kubernetes image verification

Docker is retiring Docker Content Trust, also called DCT, and the Notary v1 service behind it. For most Docker users, normal image pulls and pushes keep working. The change matters when a team deliberately enabled DCT, signs Docker Hub images with DCT, or uses DCT checks in CI/CD or Kubernetes admission policy.

The practical risk is not that every Docker install breaks overnight. The risk is that a build pipeline, deployment gate, or publishing workflow silently depends on an older trust service and only gets noticed during a brownout or production release. Use this checklist to find DCT usage, choose a replacement, and verify the change before Docker finishes the retirement.

Docker Content Trust retirement dates

July 14, 2026: four-hour write brownout.
July 15, 2026: four-hour write brownout.
August 10, 2026: four-hour read brownout.
August 12, 2026: four-hour read brownout.
December 8, 2026: full shutdown.

Docker says the brownout windows run for about four hours and begin at 8 a.m. Pacific time. Docker also says ordinary image pull and push operations continue through those windows. The affected area is DCT trust operations, so teams should focus on signing, verification, and policies that explicitly require DCT.

Who should check this now

Docker Hub publishers who sign images with Docker Content Trust.
CI/CD teams that enable DCT in build, release, deploy, or promotion jobs.
Kubernetes operators using admission policy to require DCT signatures before workloads run.
Managed hosting and SaaS teams that pull base images during customer maintenance or automated deploys.
Security teams that wrote older policy around tag-level DCT verification and have not moved to modern image signing.

What to inventory

Check developer machines and admin workstations. Look for DCT being enabled in shell profiles, Docker client configuration, or local build scripts.
Check CI/CD variables and secrets. Review GitHub Actions, GitLab CI, Jenkins, Buildkite, CircleCI, Azure DevOps, self-hosted runners, and release automation for Docker Content Trust settings.
Check deployment policy. Review Kubernetes admission controls, GitOps policy, image verification gates, and registry policy that still expects DCT or Notary v1 trust data.
Check image publishing. If your organization signs Docker Hub images with DCT today, decide who owns the replacement signing keys, identity, or certificate flow.
Check third-party dependencies. If you consume images from vendors that used DCT, ask whether they will publish Cosign, Notation, provenance, SBOM, or other modern trust data.

Choose the replacement path

There is no single replacement that fits every team. Docker points users toward modern OCI-native signing options such as Sigstore Cosign and the Notary Project’s Notation. The right choice depends on how your team manages identity, certificates, registry support, and Kubernetes admission policy.

Fastest unblock: turn off DCT where it was only being used to keep pulls working, then document the loss of tag-level verification and schedule a proper replacement.
Integrity baseline: pin critical images by digest so the deployment gets the exact image it was reviewed against.
Publisher identity: adopt Cosign or Notation so images have modern signature data stored alongside OCI artifacts.
Kubernetes policy: test Kyverno for Cosign-based verification or Ratify with Gatekeeper for Notation-based verification, depending on your preferred trust model.
Base image strategy: if your team relied on DCT for Docker Official Images, evaluate whether Docker Hardened Images, digest pinning, SBOM review, and provenance checks fit your operating model.

Brownout test plan

Before July 14: run the inventory and identify every workflow that depends on DCT trust data.
Before the write brownouts: test publishing and signing changes on a non-production image repository.
Before the read brownouts: test build, pull, deploy, and admission flows with DCT disabled or replaced.
During each brownout: watch CI/CD job status, container build logs, deployment approvals, Kubernetes admission decisions, and registry alerts.
After each brownout: record what failed, which teams own the failing workflow, and whether the fix is disable, digest pin, Cosign, Notation, or vendor follow-up.

Rollback and safety notes

Do not remove image trust checks without documenting the replacement control.
Keep a short-lived rollback path for CI/CD policy changes, but avoid rolling back to DCT as the long-term answer.
Back up Kubernetes policy manifests, GitOps repositories, and CI/CD configuration before making broad verification changes.
Test against staging clusters and non-production registries before touching customer-facing deploy lanes.
For customer or agency environments, communicate whether the work affects builds only, deployments only, or live application availability.

Post-migration verification

Confirm normal image pulls and pushes still work after DCT is removed from the workflow.
Confirm signed images are being produced with the chosen replacement.
Confirm Kubernetes admission allows approved signed images and rejects images that fail your policy.
Confirm digest-pinned deployments still roll forward through staging and production.
Confirm developers, support staff, and managed-hosting operators know which trust system is now authoritative.
Document the final owner for signing keys, certificate policy, admission rules, registry settings, and incident response.

Related Fix I.T. Phill reading

Sources

Need help finding old Docker Content Trust usage before the brownouts? Fix I.T. Phill can review CI/CD configuration, Kubernetes policy, Docker Hub publishing, and staging deployments so the migration is planned before a release window exposes the problem.