Artifact Registry

Artifact Registry is Google Cloud’s registry for container images. ZopDay pushes to repositories you already have. It creates none, grants no IAM roles on them, and sets no cleanup policy or tag setting.

What does the registry step on a GKE cluster job do

Every GKE cluster job has a registry step. It runs once the cluster is ready, and after the DNS step when you picked a domain. On GCP that step makes no call to Google Cloud. It works out a registry path from the region, the project and the cluster name, such as us-central1-docker.pkg.dev/my-project/shop for a cluster called shop. It keeps only the cluster name in the job’s record. The path itself is not saved, and nothing pushes to it.

On AWS and Azure the same step creates an ECR repository or an Azure Container Registry. On GCP the cluster job leaves no repository behind, and cluster teardown has none to delete.

Inputs: region and cluster name from the job; project from the connected cloud account
Created in Artifact Registry: nothing

Where do the images actually go

Builds push to the registry set on the environment, or to one derived from the environment’s registry integration. An integration may give only a host, such as us-central1-docker.pkg.dev. Then ZopDay appends the space’s GCP project and the integration’s name. For a project called my-project and an integration called my-images, that gives us-central1-docker.pkg.dev/my-project/my-images. That repository must already exist. Create it in Artifact Registry with the integration’s name before the first build.

How does a build sign in to Artifact Registry

ZopDay does not create or store a registry password for Artifact Registry. For each build it exchanges the connected service account’s key for a short-lived OAuth access token with the cloud-platform scope. It hands that token to Docker as the password, with the username oauth2accesstoken. So a build can push whatever IAM allows that service account on the repository. Removing that permission removes the access.

Can GKE nodes pull the images

ZopDay grants no pull role. The node pool it creates sets the cloud-platform OAuth scope and no node service account, so GKE runs the nodes as the project’s default compute service account. Whether those nodes can read a repository depends on the IAM already in your project. Workload Identity is enabled on the node pool. Pods use it only when they are bound to a Google service account.

What is left for you to set up

• The API. The cluster job does not turn on the Artifact Registry API. If it is off on the project, turn it on before the first build pushes an image.
• The repository. Create it in the region you build in, named after the registry integration.
• Cleanup and tag immutability. ZopDay sets neither. Image storage grows with every push. Add a cleanup policy on the repository in Google Cloud (for example, delete untagged images). Also decide there whether tags may be overwritten.