Artifact Registry and Container Management

Artifact Registry is a fully managed, regionalized service for storing and managing container images and language packages. It replaced Container Registry as the primary artifact store on Google Cloud. The service supports multiple artifact formats:

Artifact Registry is essential for any CI/CD pipeline because it provides a secure, immutable, and versioned store for build artifacts. It integrates natively with Cloud Build, GKE, Cloud Run, and other GCP services. The key reason for its existence is to ensure that the exact artifact used in development is the same one deployed to production, preventing "works on my machine" issues.

Artifact Registry uses a regional storage backend backed by Cloud Storage buckets. When you push a container image, the service: 1. Authenticates the request using IAM. 2. Validates the image manifest and layers. 3. Stores each layer as a separate object in a Cloud Storage bucket managed by the service. 4. Creates a metadata entry in the Artifact Registry database (Cloud SQL) that maps the image tag to the manifest digest. 5. Enables vulnerability scanning using the Container Analysis API, which checks each layer against known CVE databases.

The service is immutable: once an image or package is stored, its content cannot be modified. Only new versions or tags can be added. This immutability is enforced at the storage layer by using write-once-read-many (WORM) semantics. Deleting an artifact requires explicit permission (artifactregistry.versions.delete) and is not reversible without backup.

To create a Docker repository:

gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1 --description="My Docker repo"

To configure authentication for Docker:

gcloud auth configure-docker us-central1-docker.pkg.dev

To push an image:

docker tag my-image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag
docker push us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag

To list images and their vulnerabilities:

gcloud artifacts docker images list us-central1-docker.pkg.dev/my-project/my-repo --include-occurrences

To set a cleanup policy:

gcloud artifacts repositories set-cleanup-policies my-repo --location=us-central1 --policy=policy.json

Example policy.json:

{
  "policies": [
    {
      "id": "keep-recent-5",
      "action": "DELETE",
      "condition": {
        "versionAge": {
          "olderThan": "30d"
        }
      }
    }
  ]
}

Artifact Registry uses the Container Analysis API, which is built on Grafeas. The scanning process: 1. When an image is pushed, the service extracts the list of installed packages (OS packages, language dependencies). 2. It compares the package versions against a constantly updated database of CVEs. 3. The scan results include severity (CRITICAL, HIGH, MEDIUM, LOW) and fix availability. 4. You can view results in the Console under Artifact Registry > Images > select image > Vulnerabilities tab. 5. You can also use the gcloud artifacts docker images list --show-occurrences command to get a JSON output with occurrence details.

Note: Scanning is automatic and free. There is no option to disable it for individual repositories, but you can disable the Container Analysis API entirely (not recommended).

A global e-commerce company deploys its microservices across multiple GKE clusters in us-central1 and europe-west1. They use Artifact Registry with regional repositories in each region to minimize latency and egress costs. Each region has its own repository (e.g., us-central1-docker.pkg.dev/prod/backend and europe-west1-docker.pkg.dev/prod/backend). The CI/CD pipeline (Cloud Build) pushes images to both repositories simultaneously. GKE node pools are configured with a service account that has artifactregistry.reader on the specific regional repository. This ensures that nodes in Europe pull from the European repository, not crossing regions. Common misconfiguration: using a single repository in one region causes nodes in other regions to pull across regions, incurring egress charges and increased latency. To fix, they use a virtual repository that aggregates both regional repos, but that still requires proper IAM. The solution is to use regional repos and configure GKE with a node-level Docker daemon config that points to the correct regional endpoint.

A financial institution must ensure that only signed and vulnerability-free images are deployed to production. They use Artifact Registry integrated with Binary Authorization. All images are built by Cloud Build, which signs them using a KMS key. The Binary Authorization policy requires that images be signed by the 'build' attestor and have no CRITICAL vulnerabilities. Artifact Registry's vulnerability scanning provides the CVE data that Binary Authorization evaluates. If an image has a CRITICAL vulnerability, the deployment is blocked. The team also uses cleanup policies to automatically delete images older than 90 days to comply with data retention policies. Common pitfall: forgetting to grant the Binary Authorization service account access to the Container Analysis API, causing attestation failures.

A SaaS company uses both Google Cloud and on-premises Kubernetes clusters. They want to cache Docker Hub images locally to reduce internet dependency and improve pull speeds. They create a remote repository in Artifact Registry that proxies Docker Hub. The remote repository caches pulled images in their GCP region. On-prem clusters pull from this remote repository via a VPN. This reduces egress costs and provides a consistent image source. They also use a virtual repository that aggregates the remote repository and a local repository for custom images. Misconfiguration: not setting up proper VPC peering for on-prem access, causing timeouts. They resolved by using Private Service Connect.