Google Container Registry Shutdown: Move gcr.io Images Safely and Keep Access Tight

Google shut down Container Registry on 18 March 2025, and any pipeline, cluster or script still pushing to a gcr.io host that is not backed by Artifact Registry can no longer write images. The shutdown is mostly an availability problem, but it hides security work: the access model changes from Cloud Storage bucket roles to repository roles, vulnerability scanning results change shape, and the migration itself copies images and permissions that nobody has reviewed for years. This guide is for platform engineers, cloud security teams and DevOps leads on Google Cloud. It covers the official status, how to find every reference to gcr.io and every identity that pushes or pulls, the two migration routes, how to test and roll back, and what to fix while you are in there. General registry hardening is in the Container Registry Security Guide and the product depth is in the Google Artifact Registry Security guide; this page is the migration companion.

This is an independent guide from NHI Mgmt Group, based on Google Cloud's public documentation as of November 2026. It is not sponsored or reviewed by Google Cloud. Product features change, so confirm settings against Google Cloud's current documentation.

Key takeaways

• Writes ended on 18 March 2025. Google's transition page states that effective that date Container Registry is shut down and writing images to it is unavailable; gcr.io URLs hosted on Artifact Registry are not affected.
• gcr.io keeps working only through Artifact Registry. gcr.io repositories in Artifact Registry are generally available and redirect requests for gcr.io hosts, so image names do not have to change.
• Bucket permissions do not carry the security model. Container Registry used Cloud Storage roles at multi-region level; Artifact Registry uses its own roles per repository, which is the chance to remove broad project-level access.
• Scanning output changes. Automatic scanning in Artifact Registry adds language package vulnerabilities, so expect more findings and retune any gate that counted Container Registry results.
• The identities are the hard part. CI service accounts, node service accounts and hand-written automation that set bucket ACLs are the things that break, and the things most likely to be over-privileged.

What is changing and why

Container Registry stored images in Cloud Storage buckets inside each project and billed for them as Cloud Storage. Google introduced Artifact Registry in 2020 as its successor (beta on 16 March 2020, general availability on 16 November 2020, per the Artifact Registry release notes) and has now retired the older service. Artifact Registry is a separate service with its own API, its own roles, its own quotas and its own pricing.

The differences that matter for security, as Google documents them on the transition page:

Official timeline and current status

All dates below are taken from Google's own documentation, checked on 8 November 2026. The transition page was last updated on 26 October 2026, and dates can still change, so re-check before you plan around them.

Current status: Container Registry is deprecated and shut down for writes. Google states that gcr.io URLs hosted on Artifact Registry are not affected and that Google-owned images with gcr.io URLs remain available at the same URLs. The cached Docker Hub mirror, mirror.gcr.io, is now hosted on Artifact Registry and needs action only where it is used inside a VPC Service Controls perimeter. As of 8 November 2026 Google's transition pages give no separate date for ending reads from, or deleting images in, legacy Container Registry storage, so do not assume legacy images will remain readable: treat them as already at risk.

Who and what is affected

• Build pipelines: any job that runs docker push, a build tool or a CI plug-in against gcr.io, asia.gcr.io, eu.gcr.io or us.gcr.io in a project without gcr.io repositories in Artifact Registry. Writes fail.
• Deploy targets: Kubernetes manifests, Helm values, Cloud Run and serverless service definitions and VM startup scripts that pull from gcr.io. Pulls depend on where the image now lives.
• Automation that edits bucket IAM: Google notes that creating an Artifact Registry repository does not create Cloud Storage buckets, so scripts or Terraform that granted access by changing bucket permissions now do nothing useful and must grant repository roles instead.
• Scripts using gcloud container images: listing, tagging and untagging commands map to gcloud artifacts docker equivalents (for example gcloud container images list-tags becomes gcloud artifacts docker tags list).
• Cross-project layouts: a Container Registry host cannot be mapped to a gcr.io repository in a different project, although pulls across projects still work. Shared-registry projects keep their own gcr.io repositories.
• Security tooling: scanners, admission policies and dashboards that read Container Registry scan results or allow-list gcr.io paths.

Finding affected systems and identities

Inventory three things: where gcr.io is referenced, which projects still hold images in Container Registry storage, and which identities push or pull. Do it read-only first.

1. Search configuration as code. Search every repository, Helm chart, Kustomize overlay, Terraform module, Cloud Build or other CI file for the four gcr.io host names. Record the project ID in each path, because the project determines where the gcr.io repository must exist.
2. Query running workloads. List the image field of every pod, Cloud Run revision and instance template and group by registry host. Any gcr.io image without a matching gcr.io repository in Artifact Registry is a deployment that will fail on the next pull from a cold node.
3. List projects and images. For each project, check whether Artifact Registry repositories named gcr.io, asia.gcr.io, eu.gcr.io or us.gcr.io exist, and list images with gcloud artifacts docker images list. A project with gcr.io references but no gcr.io repository is your priority list.
4. Find the writers. Use Cloud Audit Logs for Artifact Registry and the old storage buckets to identify which service accounts push images. Admin Activity logs are on by default; Data Access logs, which record pulls and pushes, normally need enabling. See the Google Cloud Audit Logs and Log Sinks Guide.
5. Find the over-privileged. Review project-level grants of storage administration roles that existed only so CI could push to Container Registry. Many date from early GKE set-ups and allow far more than image pushes. Pair this with a key review: CI systems that push images often still use downloaded service account keys. See How to inventory Google Cloud service account keys and replace them with federation.
6. Find the readers. Node service accounts and workload identities that pull images. Note which pull from other projects, because those grants have to be recreated on the target repositories.

The identity side matters more than the image side. A registry write credential is a software supply chain credential: whoever holds it can replace an image that production pulls by tag. MITRE ATT&CK tracks this as T1525 Implant Internal Image. The CI/CD Pipeline Identity Security Guide covers how to scope those identities.

Migration options

Google documents two destinations. Choose per project.

A common pattern is to adopt gcr.io repositories first to stop breakage, then move high-value images (production base images, release artefacts) into pkg.dev repositories split by environment, where access can be narrower.

Mapping access by capability

Google's role-mapping pages for the transition now redirect to the overview, so map by what each identity actually does rather than by translating old role names. Artifact Registry's predefined roles are:

Grant at repository level, not project level, wherever the layout allows. Give delete rights only to the cleanup identity. Use the Migration Admin role for the people running the transition and remove it afterwards. Keep CI on short-lived federated credentials rather than keys: see the Google Cloud IAM and Service Accounts Guide.

Copying images

Copy only what is still deployed or needed for rollback, not every image ever pushed. If you used the automatic migration tool before 19 March 2024, check upload times on copied images before turning on any cleanup policy keyed to age, because of the known issue Google recorded on 15 March 2024. Pin deployments to full digests after the copy and confirm the digest in Artifact Registry matches the one that was running.

Testing and rollback

1. Pilot one non-production project. Create the gcr.io repositories, grant the mapped roles, and run the full build, push, deploy and pull cycle. Pull from a fresh node to avoid cached layers hiding a failure.
2. Check scanning and gates. Confirm scan results appear for pushed images (on-demand with gcloud artifacts docker images scan, results with gcloud artifacts docker images list-vulnerabilities) and that admission or policy gates read the new findings. Expect more findings from language package coverage and agree thresholds before production.
3. Check notifications and perimeters. Confirm image-push messages still arrive on the gcr topic, and that VPC Service Controls perimeters include Artifact Registry and, if used, mirror.gcr.io.
4. Roll out by environment. Development, then staging, then production, with a freeze on new image pushes during each cut-over window.
5. Rollback plan. Writing back to Container Registry is no longer possible, so rollback means reverting manifests to a known image digest that already exists in Artifact Registry, or restoring a previous repository IAM policy. Export repository IAM policies before each change so they can be reapplied.
6. Clean up access. After a stable period, remove the old storage grants that existed for Container Registry, especially project-level storage administration given to CI.

Risks of doing nothing

• Failed deployments under pressure: a security patch that cannot be pushed is a patch that is not deployed. Emergency fixes blocked by a registry error become an outage and a vulnerability at the same time.
• Workarounds that weaken controls: teams under deadline push images to personal or public registries, or grant broad roles to make the error go away.
• Orphaned privileged identities: CI service accounts with project-wide storage administration remain long after their purpose has gone, a classic non-human identity sprawl problem. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide.
• Unscanned images: images that stay outside Artifact Registry stop getting the newer scan coverage.
• Loss of rollback images: Google publishes no guarantee about how long legacy stored images stay readable, so images needed for recovery should be copied deliberately.

Framework mapping and metrics

Metrics to track: number of gcr.io references in code and running workloads without a matching Artifact Registry repository (target zero); percentage of registry grants made at repository rather than project level; number of identities with write or delete rights per repository; percentage of image-pushing CI identities using federation instead of keys; percentage of deployed images pinned by digest; number of legacy storage grants still present after cut-over.

Practitioner checklist

• Record the official status (shutdown for writes on 18 March 2025) and recheck Google's transition page before each milestone.
• Inventory every gcr.io reference in code, manifests and running workloads, grouped by project.
• Confirm gcr.io or pkg.dev repositories exist for each project before any cut-over.
• Map each identity by capability to reader, writer, repoAdmin or admin, granted on the repository.
• Remove project-level storage administration that existed only for Container Registry pushes.
• Move CI image pushes to federated, short-lived credentials and retire downloaded keys.
• Check upload times on images copied before 19 March 2024 before enabling age-based cleanup.
• Recalibrate vulnerability gates for language package findings and pin deployments to full digests.
• Enable Data Access audit logs for Artifact Registry and alert on unexpected writers.

Standards and references

• Google Cloud: Transition from Container Registry
• Google Cloud: gcr.io repositories in Artifact Registry
• Google Cloud: Artifact Registry access control with IAM
• Google Cloud: Artifact Registry release notes
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: SP 800-190 Application Container Security Guide
• MITRE ATT&CK: T1525 Implant Internal Image

Related NHI Mgmt Group resources: Google Artifact Registry Security · Container Registry Security Guide · GKE Security Hardening Guide · Google Cloud Service Account Keys Security Guide