Closed hsiliev closed 7 years ago
@hsiliev - thanks for the proposal, I think this is a great way to communicate given the distance :)
Some thoughts:
--skip-ssl-validation
apply to both the private and public registries. That would resolve your point in the Con column. (I also think that supporting external insecure registries is not necessarily something we need to worry about at this point).-dockerRegistryURL
-- is it a fixed IP? Is it a URL that we resolve using consul?I can propose a solution for both these things:
We register the private docker registry with Consul (we have examples of doing this with the file server). Then we would pass -dockerRegistryURL=http(s)://private_docker_registry.service.dc1.consul:PORT
.
To open up the container I can imagine two options:
private_docker_registry
services. This would return all registered IPs and ports and we could poke holes allowing access to all those IPs and ports.Thoughts?
@onsi: The registry client expects a []string with hosts that are insecure, but are allowed. Therefore docker builder should know upfront which hosts are insecure.
We can of course build the list dynamically and include the private and provided registry hosts when --skip-ssl-validation
is specified. This disables certificate checks for the public docker registry as well, so Diego/CF gets vulnerable to attacks.
If we want to be on the safe side we might hard-code docker URL in the builder or at least add it as default value in the configuration, which seems a bad idea. Instead I went the other way around and decided to white-list the insecure hosts - the approach originally used by Docker client.
Consul solution looks nice, especially since we want to enable HA registry setup. I'll include your proposal. I would vote for 1, since the second option looks like a lot of pain for operators.
@hsiliev thanks for the update. I think I agree that --skip-ssl-validation
should only apply to the private registry. We should only support secure external registries for now.
Let's go with option 1 for consul then. Great!
Added a new argument -consulAgentURL to:
Updated the proposal with:
insecureDockerRegistries
argumentThis all looks fine except for one thing: there is no need to add Egress rules when running. Garden downloads the DockerImage on the user's behalf (this does not happen in a container and, therefore, is not restricted by the egress rules). Only staging (which must fetch then re-upload the image inside a container) has this constraint.
Proposed opt-in config. Please review and comment.
https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/docker_registry_configuration.md
is the proposal Docker Registry configuration arguments