Secure Artifact Registry Repositories and Pipelines

Implement Security and Access Controls in Artifact Registry (opens in a new tab) means protecting stored container images and language packages with identity, network, sourcing, scanning, and deployment controls. Artifact Registry centralizes build artifacts and dependencies so security policy applies in one place where artifacts are stored, requested, and deployed. Identity controls decide who can act, network controls decide where requests can come from, and scanning plus admission controls decide what can reach production.

1.1IAM Roles and Least-Privilege Access

IAM Roles and Least-Privilege Access in Artifact Registry control who can create, read, and write repositories, packages, and versions. Permissions can be granted at the project level for broad administration and narrowed to specific repositories for team or pipeline isolation. A least-privilege design gives build service accounts write access while runtime workloads receive read-only access, often with a dedicated service account per pipeline stage.

Cross-project access uses the same role model. Traffic flows from a Google Kubernetes Engine (GKE) cluster in one project to an Artifact Registry repository in another project only after the cluster node pool machine service account is granted roles/artifactregistry.reader in the registry project. IAM Conditions add attribute-based rules, such as allowing a pipeline trigger only when the request comes from a trusted Cloud Build trigger. Audit logs then record who accessed or modified data, models, and artifacts and when they did so.

1.2Network Isolation with VPC Service Controls

Network Isolation with VPC Service Controls places a service perimeter around Artifact Registry to prevent data exfiltration and block unauthorized networks. The perimeter sits between trusted Google Cloud services inside the boundary, such as Cloud Build, GKE, and Cloud Run, and untrusted callers outside the boundary. Builds, pulls, and pushes that originate inside the perimeter succeed, while requests from outside networks or exfiltration attempts to external destinations are denied even when the caller has valid IAM credentials.

Private connectivity keeps development and build traffic off the public internet through options such as private ingress or egress for development environments, private endpoints with Private Service Connect for prediction and deployment, and private IP addresses for training jobs. An organization policy with a resource locations constraint adds compliance control by allowing repository creation only in approved regions, which supports data-residency requirements.

1.3Safer External Dependencies with Remote and Virtual Repositories

Safer External Dependencies with Remote and Virtual Repositories reduce risk from public packages by caching them and controlling resolution order. Remote repositories act as caching proxies for preset external sources such as Docker Hub, Maven Central, the Python Package Index (PyPI), Debian, CentOS, and user-defined sources for supported formats. A build request flows from the client to the remote repository, and the remote repository fetches the artifact from the external source on first request and serves cached copies afterward.

Virtual repositories consolidate multiple upstream repositories of the same format behind a single endpoint and control the search order across them. Requests flow from the client to the virtual repository, and the virtual repository searches upstream repositories in priority order before returning a match. Prioritizing private standard repositories above remote repositories reduces dependency confusion attacks, where an attacker publishes a higher-version public package with the same name to trick a build into pulling the malicious copy.

1.4Continuous Vulnerability Detection with Artifact Analysis

Continuous Vulnerability Detection with Artifact Analysis (opens in a new tab) proactively finds vulnerabilities in artifacts stored in Artifact Registry. Scanning covers base container images and language packages in containers through on-demand scanning for a specific image and automated scanning when new images are uploaded. The initial scan extracts system-package inventory from the container, and continuous monitoring keeps results current as new vulnerability intelligence arrives.

When Artifact Analysis receives new and updated information from vulnerability sources, it updates each affected image in order:

1. Update the metadata of the scanned images to keep vulnerability data current.
2. Create new vulnerability occurrences for new notes from the vulnerability sources.
3. Delete vulnerability occurrences that are no longer valid.

This lifecycle means an image that was clean at upload can later show new findings without being rebuilt or rescanned manually. Teams can also generate a software bill of materials (SBOM) dependency list for images and upload Vulnerability Exploitability eXchange (VEX) statements to record whether a finding is actually exploitable in their environment.

1.5Policy Enforcement Before Deployment

Policy Enforcement Before Deployment connects vulnerability detection to build provenance and admission control so risky images do not run. Cloud Build can produce Supply-chain Levels for Software Artifacts (SLSA) Level 3 builds for container images with authenticated and non-falsifiable build provenance. That provenance records image digests, input source locations, toolchain, build steps, and duration, while security insights dashboards surface SLSA level, vulnerabilities, provenance, and SBOM data for sources, builds, artifacts, deployments, and runtimes.

Binary Authorization enforces deployment-time decisions on GKE and Cloud Run by checking configurable signatures called attestations before an image runs. An attestation verifies that a required process completed, such as:

• A specific build system or continuous integration (CI) pipeline created the container image.
• The container image is compliant with a vulnerability signing policy.
• The container image passes the criteria for promotion from development to quality assurance (QA) or production.

Only images with the required attestations deploy to the target environment, so vulnerable or unverified artifacts remain in the registry and cannot reach production.

Manage Lifecycle Policies and Multi-Regional Replication in Artifact Registry (opens in a new tab) controls how long artifact versions live and where repository data lives. A cleanup policy automatically deletes unneeded versions or keeps important versions indefinitely, while repository location in a region or multi-region controls latency, availability, and egress cost. Consumers such as GKE, Cloud Run, and Cloud Build benefit when retention and placement match their deployment pattern.

2.1Cleanup Policies

Cleanup Policies in Artifact Registry are named rules attached to a repository that automatically delete or preserve artifact versions. Each policy has an id set to POLICY_NAME and an action of DELETE or KEEP, and the repository evaluates the policies to decide which versions to remove. Policies can run in dry-run mode to audit impact before enforcement. When cleanup_policy_dry_run is true, Artifact Registry only logs which artifacts would be deleted, and when it is false, the policies delete or keep artifacts.

A DELETE policy for age combined with KEEP policies for protected packages is the common pattern for CI/CD cleanup. The KEEP rules prevent release or protected prefixes from being removed while old development versions expire.

2.2Automated Cleanup Criteria

Automated Cleanup Criteria in Artifact Registry filter versions by tag state, tag prefix, package prefix, age, and version count. The criteria apply per package in the repository, so different teams can protect release prefixes while aggressively cleaning untagged or development builds. Age is measured as time since upload to the repository.

The supported condition fields are:

• TAG_STATE: tagged, untagged, or any, where any applies to both tagged and untagged artifacts.
• TAG_PREFIX, TAG_PREFIX_N: tag prefixes that scope the policy to matching tags.
• PKG_PREFIX, PKG_PREFIX_N: package name prefixes that scope the policy to matching packages.
• TIME_SINCE_UPLOAD: duration since upload, with s for seconds, m for minutes, h for hours, or d for days.
• KEEP_COUNT: number of versions per package to retain in the repository.

2.3Multi-Regional Placement for Latency and Availability

Multi-Regional Placement for Latency and Availability is the choice of a supported region or multi-region where repository data is stored. A good location balances latency, availability, and bandwidth costs for data consumers, plus any compliance requirement for data residency. Placing the repository in the same region as GKE, Cloud Run, Cloud Build, and other consumers reduces pull latency and avoids network egress charges.

Egress from Artifact Registry to another Google Cloud service in the same region has no charge. Egress from a multi-region to a corresponding region is free only for a limited mapping, so the us multi-region to us-central1 or another United States region is not charged, but us to Canada or South America is charged. Similarly, the asia multi-region to asia-northeast1 or another Asian region is not charged, but asia to Australia is charged. Image streaming for GKE and Managed Service for Apache Spark requires container images in Artifact Registry repositories in the same region as the workloads or in a multi-region that corresponds to the workload region, and streaming lets workloads with larger images start before the entire image is downloaded.

2.4Restricting Repository Locations

Restricting Repository Locations in Artifact Registry is enforcement through a Google Cloud organization policy with a resource locations constraint. Artifact Registry only enforces the constraint after it is included in the organization policy, so only compliant regions allow new repository creation. The constraint does not move existing data, so artifacts in non-compliant repositories must be moved to a compliant-location repository and then the non-compliant repository must be deleted.

Configure Repository Types and Formats in Artifact Registry (opens in a new tab) means creating format-specific repositories with the correct mode for publishing, caching, or consolidated access. Each repository holds one format, such as Docker container images, Maven Java packages, npm Node.js packages, Python packages, Go modules, Helm charts, Apt Debian packages, Yum RPM packages, or Kubeflow pipeline templates. Each repository also has a mode that controls whether it stores private artifacts, caches public artifacts, or forwards requests to other repositories.

3.1Repository Modes

Repository Modes in Artifact Registry separate private storage, public caching, and consolidated access by how artifact requests flow through them:

A standard repository depends on publishers such as Cloud Build to upload versions, while a remote repository depends on its configured external source on first request and then serves later requests from cache. A virtual repository depends on its upstream repositories, so the virtual repository forwards a client request to each upstream repository in order until the artifact is found. Caching in remote repositories reduces download time and improves availability, and cached artifacts can receive vulnerability scanning when scanning is enabled.

3.2Standard and Remote Repositories for Deployment Patterns

Standard and Remote Repositories for Deployment Patterns place private publishing and public caching between builders and runtimes. A standard repository is the deployment source of record for private software. In a typical flow, Cloud Build uploads a Maven package to a standard Maven repository, uploads a built container image to a standard Docker repository, and GKE, Cloud Run, or another runtime pulls that private artifact for deployment.

A remote repository is a caching proxy for public dependencies. When a build requests a public Maven dependency, the request flows from the build to the remote repository and then to Maven Central on cache miss, and later requests are served from the remote repository cache. When GKE requests a public base image, the request flows from GKE through a Docker virtual repository to the remote repository and then to Docker Hub. Remote repositories for OS formats require an explicit public base and path, such as an Apt repository with base DEBIAN or UBUNTU and path debian/dists/stable, or a Yum repository with base CENTOS, CENTOS_DEBUG, CENTOS_VAULT, CENTOS_STREAM, ROCKY, or EPEL and path such as centos/8-stream/BaseOS/x86_64/os.

3.3Virtual Repositories and Dependency Management

Virtual Repositories and Dependency Management consolidate multiple repositories of the same format behind a single endpoint with an enforced upstream search order. Build tools and runtimes send all requests for that format to the virtual repository endpoint, and the virtual repository forwards each request first to the higher-priority upstream repository and then to the lower-priority upstream repository. Configuring the upstream policy to check the standard repository with private artifacts before the remote repository with cached public artifacts ensures that an internal package name resolves to the private version rather than a public package with the same name.

This consolidation simplifies dependency management because Maven, npm, Docker, and other clients need only one configured URL per format. The same virtual Maven repository can serve a private application package from the upstream standard repository and a public library from the upstream remote repository. The same virtual Docker repository can serve a private application image from the upstream standard repository and a public base image from the upstream remote repository. The trust boundary is explicit: private code comes from organization-owned standard repositories, and external code enters only through cached remote repositories in a controlled order.

3.4Repository Usage Across Development and Runtime Projects

Repository Usage Across Development and Runtime Projects shows how all three modes separate Java development (opens in a new tab) from container deployment while sharing dependencies. In this pattern, a development project holds Maven repositories and a runtime project holds Docker repositories, with Cloud Build and GKE as the producers and consumers:

1. Build Java application: in the development project, Cloud Build builds the Java application, requests public Java dependencies through the Maven virtual repository, and the virtual repository serves those dependencies from the remote repository that proxies Maven Central.
2. Containerize application: in the runtime project, Cloud Build requests the Java application through the same Maven virtual repository, and the virtual repository serves the package from the standard Maven repository in the development project.
3. Publish container image: in the runtime project, Cloud Build uploads the built container image to the standard Docker repository.
4. Deploy to GKE: GKE pulls images from the Docker virtual repository, which serves private application images from the upstream standard Docker repository and Docker Hub images from the upstream remote repository.

This flow shows the core dependency rule: publishers write only to standard repositories, while readers resolve through virtual repositories that fan out to standard and remote upstreams. Keeping all repositories, builds, and GKE clusters in the same region in this example reduces latency and avoids cross-region egress.

3.5Repository Location and Compliance

Repository Location and Compliance in Artifact Registry balances latency, availability, bandwidth cost, and compliance because a repository is created in one supported region or multi-region. Creating the repository in the same region as GKE, Cloud Run, Cloud Build, and other interacting Google Cloud services reduces latency and network egress cost, and there is no charge for egress from Artifact Registry to other Google Cloud services in the same region. Egress from a multi-region to a corresponding region is free only in limited cases: egress from the us multi-region to a United States region such as us-central1 is not charged, but egress to Canada or South America is charged.

Location also controls performance features and external access cost. Image streaming for GKE and Managed Service for Apache Spark works only when container images are stored in an Artifact Registry repository in the same region as the workloads or in a corresponding multi-region, and streaming lets workloads with larger images start before the entire image is downloaded. For consumers outside Google Cloud, such as developers downloading artifacts to workstations in Australia, a repository in an Australian region reduces latency and egress charges compared with a repository on another continent.

Key Facts

• Artifact Registry uses standard repositories to store private artifacts, remote repositories to cache public dependencies, and virtual repositories to serve both through one endpoint in priority order.
• A GKE cluster in one project can pull from an Artifact Registry repository in another project only after its node pool service account is granted roles/artifactregistry.reader in the registry project.
• VPC Service Controls creates a perimeter around Artifact Registry that denies requests from outside networks even when the caller has valid IAM credentials.
• Artifact Analysis detects vulnerabilities with on-demand and automated scans and updates findings over time, while Binary Authorization blocks GKE and Cloud Run deployments unless required attestations are present.
• Artifact Registry cleanup policies use DELETE with older_than and KEEP with package_name_prefixes or most_recent_versions and keep_count, and immutable tags prevent deletion of tagged artifacts.