Google Container Registry

Quick Hit

Google Container Registry (GCR) is a compelling private (secure) container registry (that also currently includes free — as in beer — vulnerability scanning)

If you’re running containerized workloads on Google Cloud Platform compute (App Engine Flex, Kubernetes Engine, or rolling your own containers on Compute Engine) why leave Google’s network to push-pull containers when you can stay fast-and-local?

Like every GCP service, GCR is secure. This means that, when you’re using it, you’ll need to authenticate to the repo. So, a common pattern is:

PROJECT=[[YOUR-PROJECT]]
docker tag $(whoami)/my-image gcr.io/${PROJECT}/my-image
gcloud docker -- push gcr.io/${PROJECT}/my-image

The gcloud command wraps the docker CLI to provide authentication for GCR so that you can push the image to it. Google services can talk securely to GCR, so, for example, in Kubernetes, you can reference the image directly by its GCR name.

BUT, what happens if you can’t or don’t want to use the gcloud wrappers for docker? What if you’re using a library that assumes docker will be doing the push/pull directly? There are multiple ways you can achieve this with GCR. I’m going to show you the simplest:

PASSWORD=$(gcloud auth application-default print-access-token)
docker login \
  --username=oauth2accesstoken \
  --password=${PASSWORD} \
  https://gcr.io

Or, to avoid the security “WARNING!”, you may prefer to:

echo $(gcloud auth application-default print-access-token) \
| docker login \
  --username=oauth2accesstoken \
  --password-stdin \
  https://gcr.io

Now, while you need to continue to tag images appropriately for GCR, you can use docker push and pull directly with them:

docker tag $(whoami)/my-image gcr.io/${PROJECT}/my-image
docker push gcr.io/${PROJECT}/my-image

And, if you have tooling or code that assumes Docker (not Google Cloud SDK aka gcloud), this will now run as expected as long as you replace “docker.io” registry references with “gcr.io/${PROJECT}” references.

NB GCR is GCP Project specific hence the ${PROJECT} references. A common practice is for a Project to be designated as a container registry for your team, org or company and then that becomes a definitive name. Google does this. For example, Google Container Builder hosts the Google-provided “steps” in a project called “cloud-builders” so that the images are all available from “gcr.io/cloud-builders”.

Container Registry’s Docker Hub Mirror

Which brings me to the 2nd useful insight with GCR. I learnt today that Google provides a mirror of Docker Hub for frequently-requested images. You can configure Docker daemons to check GCR for images (saving time) before falling-back to Docker Hub.

https://cloud.google.com/container-registry/docs/using-dockerhub-mirroring

Neat!

Container Vulnerability Analysis

Lastly, I mentioned that GCR provides a new vulnerability analysis capability. The documentation is here. This is currently in Alpha so you’ve a little pre-work to do to get it running:

https://cloud.google.com/container-registry/docs/vulnerability-scanning#activating_vulnerability_scanning

PROJECT=[[YOUR-PROJECT]]
gcloud services enable containeranalysis.googleapis.com \
--project=$PROJECT

and:

Vulnerability Scanning

Then:

Images now include “Vulnerabilities”

And, it’s possible to drill into the details:

Some work for me to do!