12.1 Artifact Management and Vulnerability Scanning with Artifact Registry

Artifact Management and Vulnerability Scanning with Artifact Registry

In modern cloud architectures, compiled software artifacts, container images, and language-specific package dependencies represent the bridge between source code and production compute environments. Artifact Registry is Google Cloud's fully managed, universal package manager and container image registry.

Artifact Registry replaces the legacy Container Registry (gcr.io), providing enterprise-grade security boundaries, fine-grained Identity and Access Management (IAM), multi-format package hosting, upstream registry caching, automated vulnerability discovery, and declarative artifact lifecycle management.

---

Artifact Registry vs. Container Registry (gcr.io)

Google Cloud formally deprecated Container Registry in favor of Artifact Registry. Understanding the structural differences between these two services is essential for migration scenarios and certification questions:

---

Regional vs. Multi-Regional Repository Architecture

When provisioning an Artifact Registry repository, developers must choose between Regional and Multi-Regional locations:

Regional Repositories (Recommended for Production Workloads)

• Performance and Latency: By placing an Artifact Registry repository in the exact same region as your compute clusters (e.g., repository in us-central1 and GKE/Cloud Run workloads in us-central1), container pull times are minimized.
• Network Egress Cost Elimination: Pulling a container image across regional boundaries incurs standard Google Cloud inter-region network egress charges. In high-velocity environments with frequent horizontal pod autoscaling or node spin-ups, these costs compound rapidly. Colocating repositories in the workload's region reduces inter-region data transfer charges to zero.
• Data Sovereignty: Satisfies strict regulatory and legal compliance frameworks that mandate data residency within specific geographic borders.

Multi-Regional Repositories

• Geographic Redundancy: Replicates container images across multiple Google Cloud data center zones within a broad geographical area (us, europe, or asia).
• Global Footprint: Best suited for globally distributed fleets where nodes across various continents pull from a unified multi-regional endpoint.

Remote and Virtual Repositories

Enterprise software supply chains frequently face upstream failures, such as public Docker Hub rate-limiting (HTTP 429 Too Many Requests), upstream outage downtime, or malicious package tampering:

1. Remote Repositories: Act as caching pull-through proxies for public registries (Docker Hub, npmjs, Maven Central, PyPI). When a developer or CI/CD runner requests an external base image (e.g., alpine:latest), Artifact Registry checks its cache. If absent, it pulls the image from Docker Hub, stores a copy in your private Google Cloud perimeter, and serves subsequent requests directly from internal Google cache.
2. Virtual Repositories: Within one package format, consolidate compatible underlying repositories (such as an internal private production repository, an internal staging repository, and an external remote proxy) behind a single unified URL endpoint. Upstream repositories are evaluated according to a priority order, preventing dependency confusion attacks.

---

Authentication and IAM Permissions

Interacting with Artifact Registry requires configuring native authentication and assigning least-privilege IAM roles.

IAM Access Controls

Unlike Container Registry, Artifact Registry supports IAM bindings at both the project level and the individual repository level:

• roles/artifactregistry.reader: Read-only access to view and pull artifacts. Must be granted to runtime service accounts (e.g., GKE Node Service Account or Cloud Run Service Agent) so nodes can pull container images.
• roles/artifactregistry.writer: Read and write access to push artifacts. Assigned to Cloud Build service accounts, GitHub Actions runners, or release automation agents.
• roles/artifactregistry.repoAdmin: Repository artifact administration. Repository configuration and IAM policy changes require appropriate administrator permissions, such as Artifact Registry Administrator; do not infer them from the name repoAdmin.

Configuring the Docker Credential Helper

Developers and local workstations must authenticate Docker with Google Cloud before running docker push or docker pull. Instead of storing long-lived, static access keys on developer machines, Google Cloud uses the Docker Credential Helper:

## Configure Docker to authenticate against regional Artifact Registry hosts
gcloud auth configure-docker us-central1-docker.pkg.dev,europe-west1-docker.pkg.dev

This command updates ~/.docker/config.json. When Docker interacts with us-central1-docker.pkg.dev, it calls gcloud behind the scenes to fetch short-lived OAuth 2.0 access tokens, completely eliminating persistent static passwords.

---

Vulnerability Scanning with Container Analysis

Container security requires continuous inspection of operating system packages, system binaries, and language runtimes. In Google Cloud, vulnerability scanning is powered by the Container Analysis API.

Automatic Scanning vs. On-Demand Scanning

Google Cloud provides two distinct vulnerability scanning mechanisms:

+-----------------------------------------------------------------------------+
|                        Automatic Continuous Scanning                        |
|  - Triggered automatically whenever an image is pushed to Artifact Registry |
|  - Continuous Rescanning: When a new zero-day CVE is discovered, Container  |
|    Analysis re-indexes existing stored images without requiring a rebuild   |
|  - Scope: OS packages (Debian, Ubuntu, Alpine, RHEL) & Language runtimes   |
+-----------------------------------------------------------------------------+
                                      vs
+-----------------------------------------------------------------------------+
|                             On-Demand Scanning                              |
|  - Shift-Left: Executed locally on developer machines or early in CI steps  |
|  - Scans local container images before pushing to Artifact Registry         |
|  - Command: gcloud artifacts docker images scan [LOCAL_IMAGE_TAG]           |
|  - Blocks vulnerable images before they ever reach central registries       |
+-----------------------------------------------------------------------------+

Container Analysis Data Model: Notes and Occurrences

Container Analysis organizes metadata using an abstract metadata framework:

• Note: A high-level description of a known security concept. For vulnerabilities, a Note represents a distinct CVE (e.g., CVE-2024-6387), including its CVSS severity score, affected software packages, and remediation instructions. Notes are maintained globally by Google Cloud's security research teams.
• Occurrence: A specific, concrete instance of a Note linked to a particular container image manifest (identified by SHA256 digest). If your container image contains an affected OpenSSH package version associated with CVE-2024-6387, Container Analysis creates an Occurrence pointing to your image digest.

Vulnerability Discovery and Severity Classification

Vulnerabilities are categorized according to Common Vulnerability Scoring System (CVSS) baselines:

• CRITICAL: Highest CVSS severity band; the precise exploit conditions come from the advisory.
• HIGH: A high CVSS severity band, not a guarantee of one particular exploit type.
• MEDIUM: Moderate security exposure requiring specific conditions.
• LOW: Minor security discrepancies.

Querying Vulnerabilities via CLI

Developers and CI pipelines can query vulnerability Occurrences using gcloud:

## List all vulnerabilities discovered for a specific container image digest
gcloud artifacts docker images list-vulnerabilities \
    us-central1-docker.pkg.dev/my-project/apps/order-service@sha256:4a8b1... \
    --format="table(occurrence.vulnerability.effectiveSeverity, occurrence.vulnerability.shortDescription)"

## Query and filter for blocking CRITICAL or HIGH vulnerabilities in CI
gcloud artifacts docker images list-vulnerabilities \
    us-central1-docker.pkg.dev/my-project/apps/order-service@sha256:4a8b1... \
    --filter="occurrence.vulnerability.effectiveSeverity >= HIGH"

---

Artifact Lifecycle Management: Cleanup Policies

Continuous Integration pipelines push dozens of container image revisions daily. Over time, unused intermediate layers, untagged images, and obsolete release candidate builds accumulate, inflating storage costs.

Artifact Registry features native Cleanup Policies that evaluate stored images against declarative lifecycle conditions.

Cleanup Policy Concepts & Evaluation Logic

Policies consist of Conditions and Actions:

• Action: Either DELETE (purges matching versions) or KEEP (preserves matching versions, overriding any conflicting delete conditions).
• Tag State: Filter by TAGGED, UNTAGGED, or ANY.
• Age Conditions: olderThan (e.g., 30d) or newerThan.
• Prefix Filters: Match specific tag conventions (e.g., tagPrefixes: ["v", "release"]).
• Most Recent Versions: Keep the N most recently uploaded versions via keepCount: 10.

Concrete Example: Enterprise Cleanup Policy Specification

[
  {
    "name": "delete-untagged",
    "action": {
      "type": "Delete"
    },
    "condition": {
      "tagState": "untagged",
      "olderThan": "14d"
    }
  },
  {
    "name": "keep-production",
    "action": {
      "type": "Keep"
    },
    "condition": {
      "tagState": "tagged",
      "tagPrefixes": [
        "v",
        "prod-"
      ]
    }
  },
  {
    "name": "keep-recent",
    "action": {
      "type": "Keep"
    },
    "mostRecentVersions": {
      "keepCount": 5
    }
  }
]

## Applying the cleanup policy to an Artifact Registry repository
gcloud artifacts repositories set-cleanup-policies my-repo \
    --project=my-project \
    --location=us-central1 \
    --policy=cleanup-policy.json \
    --dry-run

Exam Trap: KEEP policies always take precedence over DELETE policies. If an image matches both a delete rule (e.g., olderThan: 30d) and a keep rule (e.g., keepCount: 5), the image is retained. Furthermore, developers can run cleanup policies with --dry-run to preview image deletion candidates in Cloud Logging before permanent deletion occurs.

Official references checked October 18, 2026: Google Cloud 1.