Manage your build artifacts with Artifact Registry

If you can hardly *contain* your excitement when it comes to containers, then this post is for you! If you disliked that pun, then this post is still for you, but don’t expect me to apologize for the dad jokes.

Everything in its place

I’ve moved quite a few times in my life. In the past ten years alone, I’ve lived in three different states, seven different cities, and eight different homes. Moving can certainly be stressful; something inevitably breaks, something else gets lost, and every part of the move costs more than anticipated. But there is one part of moving to a new place that’s very satisfying: getting organized. If you use Container Registry, I bet you enjoy getting organized, too! But more on that in a minute. Let’s continue this metaphor a bit longer because I’m pretty proud of coming up with it.

I finally just bought my first house and I’m really looking forward to settling in. I’ve spent a lot of time planning out how to automate and optimize my home.

Ooooo look at how it’s coming together!

I chose the perfect location for all of my cooking utensils. I invested in shades that I can raise a lower automatically. I have a Nest doorbell because I’ve had a couple packages sprout legs and walk away from my prior residences. And of course, I have enough Google Homes to ensure that Assistant is never more than a “Hey Google” away. When it comes to managing your team’s Docker images, I’m willing to bet that you want the same organization and automation that I have at home. Up until now, Container Registry has provided this automation, but it’s time to move in to the next generation of registries: Artifact Registry. See how I brought that full-circle?

Another photo of home improvement even though you didn’t ask

Moving up to the latest in pipeline automation

Container Registry has provided a single place for your team to manage Docker images, perform vulnerability analysis, and decide who can access what with fine-grained access control. Existing CI/CD integrations let you set up fully automated Docker pipelines to get fast feedback. In an effort to build upon this powerful foundation, Google Cloud has released the next generation of container management tools: Artifact Registry.

With Artifact Registry, you can manage your container images and language packages (i.e. build artifacts while integrating with Cloud’s build, test, and deploy suite and 3rd party CI/CD systems.

• Registry specific permissions — Artifact Registry offers more fine-grained permissions, allowing you to control access at the project or registry level
• Regional support — Create multiple regional repositories within a single Google Cloud project
• Multiple repositories with separate permissions — You can create multiple repos under a project, with independent Artifact Registry-specific permissions. You have control over where artifacts are stored and who can access them.

After hearing about Artifact Registry, I bet you can’t wait to get started! Well rest easy, gentle reader; I’ll show you how to create a new repository, list existing repositories, and configure access controls.

Artifact Registry Repositories

Enable the Artifact Registry API in the console. Then to create a new repository, follow these steps:

gcloud beta artifacts repositories create REPOSITORY \
— repository-format=FORMAT [ — location=LOCATION] \
[ — description=”DESCRIPTION”] [ — async]

Where

• REPOSITORY is the name of the repository.
• FORMAT is the repository format. Supported values are
• LOCATION is the regional or multi-regional location for the repository. You can omit this flag if you set a default. To view a list of supported locations, run the command gcloud beta artifacts locaitons list
• DESCRIPTION is a description of the repository.

The --async flag returns immediately, without waiting for the operation in progress to complete.

To view a list of repositories, you’ll want to run this command:

gcloud beta artifacts repositories list [ — project=PROJECT] \
[ — location=LOCATION]

Where

• PROJECT is the project ID. If this flag is omitted, the current or default project is used.
• LOCATION is a regional or multi-regional location. Use this flag to view repositories in a specific location. You can also use--location=all to list repositories across all locations.

If you omit this flag, the command uses the default location if a default is configured. Otherwise, omitting this flag lists repositories across all locations.

Access Controls

Although you can use the primitive roles Owner, Editor, and Viewer roles to grant access to repositories, using specific Artifact Registry roles enables you to apply the security principle of least privilege, so that users and service accounts only have the permissions that are required. For example, the artifactregistry.reader role allows a user to view and get artifacts just from a specific project’s repositories, whereas the roles/reader allows a user to view and get any existing resources and data from all Cloud components of the project.

Configuring permissions

To grant a permission for a user, naturally you grant a role that includes the permission. Where appropriate, use the Artifact Registry roles to control access to your repositories rather than project roles. You can grant the following Artifact Registry roles:

• Artifact Registry Reader: View and get artifacts
• Artifact Registry Writer: Read and write artifacts
• Artifact Registry Repository Administrator: Read, write, and delete artifacts
• Artifact Registry Administrator: Create and manage repositories and artifacts

If you are granting roles using the gcloud command, the following reference policy template is used for these examples. The reference policy file is named policy.yaml. You can find a reference template in the documentation which contains example user and service account names. Here is an example policy.yaml:

bindings:
- role: roles/owner
members:
- user: jenperson@thisemailisfake.com
- role: roles/artifactregistry.reader
members:
- serviceAccount: repo-readonly@iam.gserviceaccount.com
- user:fakeuser2@thisemailisfake.com
- role: roles/artifactregistry.admin
members:
- serviceAccount: ar-admin@iam.gserviceaccount.com

To add a team member to a project and grant them a Artifact Registry role:

gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml

Where

• PROJECT is the ID of the project or fully qualified identifier for the project.
• /PATH/TO/policy.yaml is the path and file name of the policy file.

To get the currently configured policy, run the following command:

gcloud projects get-iam-policy PROJECT

Where

• PROJECT is the ID of the project or fully qualified identifier for the project.

Ready to get started?

With just a few steps, you can be up and running with Artifact Registry! I wish organizing my junk drawer was just as straightforward! Ready to get started with Artifact Registry? Check out the documentation!