containerregistry
containerregistry copied to clipboard
google
[WIP] Add SSL Certificate Support to Fast Pull and Push
This PR allows specifying SSL certificates (client key and cert chain) for a specific domain (or set of domains). The transport pool wrapper now exposes a add_certificate method that mimics the underlying httplib2.Http transports that it's wrapping.
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
- If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
- In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.
@mattmoor Does this approach seem reasonable? And should it be expanded to all uses of the transport pool?
Also, I'll open up a pr against docker_rules if/when this guy gets merged. I've got a branch that threads through the arguments.
tl;dr I'm worried this is going to end up making rules very verbose.
What does a docker_push look like in the end-state? What does a k8s_object look like (has its own push client)?
An alternative would be to make the client support something like this. I think my bias is generally towards adopting compatibility with the solutions folks are using with conventional clients, unless there are strong reasons against (maybe there are).
Are you guys using anything like this for certs?
There's also precedent for defining certs using flags on the Docker client: https://docs.docker.com/engine/reference/commandline/cli/
I'm happy with either solution. Is there a clean way to depend on certs in /etc/docker/certs.d? That's actually the solution we use today for Docker pull/push today, we require engineers install those certs.
@ahirreddy my biggest concern is the root requirement for reading that directory :(
drwx------ 2 root root 4096 Jan 20 2017 docker
Since this is daemon-side auth and the daemon runs as root, it can read this ACL'd this way. We don't (want to) require root, so we cannot (as-is).
I think we basically want what you have, but instead of passing the certs it would enable reading them from this standard directory (WDYT?).
@KingEmet I don't think there are environment variables controlling this because it's daemon-side. I think the environment variables control certs for talking to the daemon. Please correct me if I'm mistaken. :)
@ahirreddy In summary, if you can also require making that directory user-readable, then the flag option is viable and less verbose.
@mattmoor looks like it, yeah. Seems like /etc/docker/certs.d/... is for daemon <-> registry communications
Um...the merge-base version for this is a bit old cough. I am trying to rebase and fix the problems.
Ok, rebased and pushed to https://github.com/abergmeier/containerregistry/tree/container-push-pull-cert. It now semi-depends on https://github.com/google/containerregistry/pull/51. @mattmoor @ahirreddy Can you take a look and see whether its good?
Sorry, I've been swamped with other things. I'm planning to take a look next week!
@mattmoor It occurred to me, it's unclear where to look for the certificates on OS X. Docker for Mac doesn't seem to support client certs, and docker-machine stores them inside the VM.
