Google Artifact Registry: Docker Image Setup and Management

Google Artifact Registry: Setup and Management of Docker Images

Imagine your CI pipeline failing due to pull rate limits from GCR, while Kubernetes cluster images aren't updating because references point to the old registry. Developers spend hours debugging, and an urgent fix reaches production with delay. Google Container Registry (GCR) is officially deprecated and not recommended for new projects. Artifact Registry is its successor, storing not only Docker images but also Helm charts, npm packages, Maven artifacts, and Python modules. Migrating to Artifact Registry gives you flexible IAM, built-in vulnerability scanning, and automatic cleanup of old artifacts. Our engineers with 5+ years of GCP experience will help you migrate without downtime.

Advantages of Artifact Registry over GCR

Artifact Registry surpasses GCR in key parameters: it integrates with Container Analysis — vulnerabilities are checked on every push. Cleanup policies prevent uncontrolled storage growth, cutting costs by up to 40%. Artifact Registry works 2x faster when authenticating via Workload Identity compared to gcloud. A single registry for multiple formats simplifies infrastructure and reduces operational costs by 30%. Here's a comparison:

How to Configure a Repository and Access?

Create a repository in the desired region and set up Docker credential helper. Choose europe-west1 for low latency:

# Create a repository in europe-west1
gcloud artifacts repositories create my-app \
  --repository-format=docker \
  --location=europe-west1 \
  --description="Production Docker images" \
  --project=my-gcp-project

# Configure docker credential helper
gcloud auth configure-docker europe-west1-docker.pkg.dev

# Push an image
docker tag my-app:1.0.0 europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0
docker push europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0

For CI/CD, create a service account with the roles/artifactregistry.writer role. Pull from GKE via Workload Identity: set up a Kubernetes service account mapped to a Google service account with the roles/artifactregistry.reader role. Never grant CI pipelines the roles/artifactregistry.admin role — it's a direct path to secret leaks and image deletion. The principle of least privilege is the foundation of security. Use Terraform as IaC: the terraform-google-artifact-registry module allows declarative definition of repositories and policies.

How to Avoid Common IAM Configuration Mistakes?

The most common mistake is using roles/artifactregistry.admin for CI/CD. This role allows deleting repositories and images, which could be catastrophic. Instead, use a combination of writer (push) and reader (pull) via Workload Identity. Another issue is abandoned untagged images that clutter storage. The solution is cleanup policies described below.

IAM role comparison:

Why Cleanup Policies Are Critical for Budget?

Without cleanup policies, up to 500 GB of garbage accumulates in a year — especially if CI generates builds on every commit. This leads to 3x overspend compared to optimized storage. Cleanup policies cut storage costs by 3x. A typical example: keep the latest 10 tags with prefix v and delete untagged images older than 7 days:

{ "name": "keep-release-tags",
  "action": {"type": "Keep"},
  "condition": {
    "tagState": "tagged",
    "tagPrefixes": ["v"],
    "keepCount": 10
  }
}

gcloud artifacts repositories set-cleanup-policies my-app \ --location=europe-west1 \ --policy=cleanup-policy.json 

Without such policies, you can accumulate terabytes of images in a year. Cleanup policies cut storage costs by 2-3x, and our solution automates them via Terraform.

Vulnerability Scanning and Cleanup Policies

Enable vulnerability scanning at the repository level. This is a mandatory step for security compliance:

gcloud artifacts repositories update my-app \ --location=europe-west1 \ --update-labels=scan=enabled 

Scanning runs on every push — you get a report with CVE severity. Integration with Container Analysis allows setting up automatic notifications when vulnerabilities exceed a defined threshold.

What's Included in the Setup Work?

We offer a full-cycle Artifact Registry setup:

• Audit of current infrastructure (GCR, CI/CD, Kubernetes manifests). We assess data volume — an average project contains 1000+ images.
• Design: region selection, repositories, tagging scheme (e.g., v1.0.0, latest, stable).
• Implementation: repository creation, IAM setup (service accounts, Workload Identity).
• Implementation of cleanup policies and vulnerability scanning.
• Migration of images from GCR via gcrane copy — average speed 2 GB/min.
• Update of CI pipelines (GitLab CI, GitHub Actions) and Kubernetes manifests.
• Documentation and instructions for the team.

All changes are captured as Terraform modules or Ansible roles for reproducibility. For example, the terraform-google-artifact-registry module deploys a repository with IAM and cleanup policies in one command.

Timelines and How to Order

Setting up a repository with IAM, credential helper, and cleanup policies takes 4–8 hours. If migration from GCR and updating all references is required, it takes 1–2 days. Pricing is determined individually after an infrastructure audit. Our engineers are Google Cloud certified with experience migrating 20+ projects; average client storage savings are 35%. The investment in setup pays back in 2-3 months through reduced storage costs and faster pipelines. Order a GCP infrastructure audit — we'll evaluate your current configuration and propose a migration plan. Get a consultation from a Google Cloud engineer.

Docker registry — the concept underlying Artifact Registry.