Google Container Registry (gcr.io) support

[evandbrown]

This change adds support for authenticated access to gcr.io.

Authentication is limited to VM service accounts, but specifying a service account key will be supported in the future. There's a few important things happening here:

• I moved from godep to dep because I could not for the life of me convince godep to vendor http://github.com/GoogleCloudPlatform/docker-credential-gcr/ in a way that allowed docker-credential-gcr to be built in the Dockerfile. I tried. I really tried.

• Moving to dep allowed remove of scripts/deps. Now that I think about that, maybe it should stay and just run dep ensure. Or the docs should be updated to talk about the (new) use of dep, assuming that change makes it through.

• This currently depends on the VM running check, in, or out being associated with a service account that has access to GCR. Support for specifying a service account key (json) with the right prems is next on the list.

One question: are there integration tests that verify check?

Thanks, and LMK what questions I can answer!

[vito]

Thanks for submitting this, but I'm pretty afraid to pull in substantial changes to this resource in light of a bunch of the points raised in #190

According to #73 (comment) folks can use GCR with a JSON key, at least, but it's kind of hacky.

More and more registries are showing up with their own auth schemes - it's becoming a sore point of this resource to have them all baked in to one big interface. (Not the biggest sore point, but it doesn't help.)

Dividing by registry type has been one idea for stemming the tide of complexity here. Would there be any interest in that approach? i.e. a smaller, nimbler gcr-image resource. Maybe one that could even integrate more deeply with GCP? Could it use Container Builder to avoid running a daemon internally? That's one of the pain points mentioned in #190, kind of related to caching semantics too.

If there is interest, I'd like to work together and work out what the interface should look like - a carbon copy of this resource would be a mistake, since it's already far too crazy. Starting small and focused on a particular workflow would go quite far IMO. Alternatively, if we divide this resource by workflow, maybe we could work out an auth interface that's easier to extend without bloating the rest of the interface.

If you don't have time and this feels like scope creep that's fine too!

[evandbrown]

Those issues you linked are helpful. It seems like a lot of the pain is in put; I don't think I've got a good perspective there as I've primarily used this as a task's image_resource.

A resource-per-registry is an interesting idea in the context of Container Builder, but there's probably a lot of boilerplate we'd want to share between registry implementations. I'm inclined to think a single resource that a) standardizes on Docker's credential helper; and b) has a convention for adding new providers and their configuration would be nice. If the existing docker-image-resource was refactored with those things in mind, would you expect to maintain backwards compatibility?

Oh, and replacing Docker with something like kaniko would be nice, too. Let me find some time this week to play around with that and try to wrap my head around put a little better, and to fiddle with kaniko.

Oh, and the JSON key support for authenticating to GCR does work. We're primarily trying to allow customers to authenticate from a VM associated with a service account and avoid populating credhub/vault with keys and rotating them.

Thanks for the feedback, Alex!

[jchesterpivotal]

I've definitely nagged anyone at GCP within earshot (eg @erjohnso) about my dream world where Google provides officially-supported Concourse resources for some or all of the GCP APIs, including chipping in for resources that are generic on the API.

As an aside, it would be interesting to experiment with using Google Cloud Builder step images as task images in Concourse.

[evandbrown]

@jchesterpivotal I’ve got plans to make your dream come true :)

Great feedback from a customer on all of this: they point out that essentially every published example (eg pcf-pipelines) use docker-image in task definitions. They use a private registry and every time the merge upstream examples they have to run transformation scripts to rewrite those task files. Probably worth thinking about how better multi-registry support intersects with this scenario.

[vito]

@evandbrown Just realized I never answered this:

If the existing docker-image-resource was refactored with those things in mind, would you expect to maintain backwards compatibility?

If we were to refactor this resource in-place, yeah, I think we'd have to. But I think it may be better in the long term to introduce smaller resources focused on particular workflows, so that they don't have the explosion of knobs present in this resource. If that ends up being more natural than splitting by registry, we can probably work out how to share common code around authentication. That would start us on a path towards deprecation for this resource.

[chrishiestand]

I don't know if this makes anything in this PR unnecessary, but for those who are stuck on this, it's already possible to push and pull from gcr.io with a gcp service account key:

The trick is:

username: _json_key

And the password is the full json of the key.

- name: my-image
  type: docker-image
  source:
    repository: us.gcr.io/my-project/image-name
    username: _json_key
    password: ((key-us-gcr-auth-rw))

[jchesterpivotal]

@chrishiestand's suggestion worked for me. However it required a fair amount of fiddling with permissions to get it to work, finally settling on a service account with the "Storage Admin" role.

I don't know if this is just a general thing for GCR or if it's particular to using the JSON key, but it makes me uncomfortable. Fine for spiking, but I'd want something more locked down for production.

[chrishiestand]

@jchesterpivotal Thanks for testing it. These are documented in GCP documentation.

Username/password:
https://cloud.google.com/container-registry/docs/advanced-authentication#json_key_file

IAM auth:
https://cloud.google.com/container-registry/docs/access-control

FWIW, I will be using this in production.

[vito]

@evandbrown Considering there are existing workarounds and given the concerns raised earlier, I'm gonna close this for now. Thanks for submitting it though!

FYI, I've started to work on a new resource type for interacting with Docker registries: https://github.com/concourse/registry-image-resource

I'd be interested in seeing what GCR support may look like in the new resource. It may feel much less scary since it's totally centered around registry operations and cuts out all the complexity with building.

Thanks again!

[larssb]

@jchesterpivotal

I've definitely nagged anyone at GCP within earshot (eg @erjohnso) about my dream world where Google provides officially-supported Concourse resources for some or all of the GCP APIs, including chipping in for resources that are generic on the API.

As an aside, it would be interesting to experiment with using Google Cloud Builder step images as task images in Concourse.

I've successfully used Google Cloud Builder container images in Concourse CI steps. E.g.:

• gcr.io/cloud-builders/npm