registry: Introduce DOCKER_REGISTRY_SSL_NO_VERIFY environment variable #5817

Closed
wants to merge 2 commits into
from

Projects

None yet
@ktap
ktap commented May 15, 2014

Currently docker registry http request may block by some gateway
(for example, company web proxy), because of the certificate issue.

[root@localhost docker]# docker pull ubuntu
Pulling repository ubuntu
2014/05/15 15:51:24 Get https://index.docker.io/v1/repositories/ubuntu/images: x509: certificate signed by unknown authority

This patch introduce a new environment variable DOCKER_REGISTRY_SSL_NO_VERIFY
to control secure certificate verify. The default value is false.

The environment variable name comes from git: GIT_SSL_NO_VERIFY
(Similarly, wget and curl both have env variable or option to control secure
verify)

Docker-DCO-1.1-Signed-off-by: Jovi Zhangwei jovi.zhangwei@gmail.com (github: ktap)

@ktap
ktap commented May 21, 2014

ping...

@SvenDowideit
Collaborator

This needs documentation, and personally, I don't like Env vars - using a cmdline option / cfg seems safer.

also, the double negative is awkward

@samalba
Contributor
samalba commented Jun 23, 2014
@shin-
Member
shin- commented Jun 23, 2014

Somewhat related? #2687

I am unsure whether this is a good idea overall.

@dmp42
Member
dmp42 commented Jun 24, 2014

@shin- is right, this looks like the same thing, and @shykes closed the other one for the lack of a consensus (#2687 (comment)) - though he somewhat greenlit it previously at #2600 :-)

I myself have mixed feelings about this.
The main argument against it seems to be that people would abuse it like they abuse similar options in curl, and that we shouldn't allow/encourage said abuse.

Though:

  • people will abuse things anyway, and at least having the opportunity to do it with docker will make it obvious what they do (preferably with an explicit arg rather than an env var, as this is more explicit)
  • "discouraging" is one thing - "forbidding" is another
  • there are situations were security is already compromised and there is no way for the user to fix it (I think this is what @ktap describes here) - and our current position for these seems to be "docker won't work in such setups" - is this really what we want?

Also, the sheer fact there has been (at least) two different PRs for this demonstrates there is definitely a need, and if we don't accept them, we should at least provide a decent alternative / guideline, which seems to not exist right now?

@shykes where do you stand with this now?

@meta-state

+1

@slde-incal

+1

@bshaw
bshaw commented Jun 28, 2014

+1

@vbatts
Contributor
vbatts commented Jul 1, 2014

@ktap can you rebase

@vbatts vbatts added the Trust label Jul 1, 2014
@OOPMan
OOPMan commented Jul 13, 2014

Lack of support for unverified SSL is a real pain. I like to try and keep my dev env as close to the production env as possible and this little "feature" makes that difficult.

@vbatts
Contributor
vbatts commented Jul 13, 2014

@oopman is that a +1 for this PR or not?

@OOPMan
OOPMan commented Jul 13, 2014

It is indeed a +1. I just spent an hour going through the process of setting up my own machine as a CA authority in order to try and provide Docker with certificates it likes only to have it spit on them.

+1 +1 +1 to supporting unverified SSL in some form or other because not doing so just seems spiteful.

@ckulla
ckulla commented Jul 28, 2014

+1

@vbatts
Contributor
vbatts commented Jul 28, 2014

@ktap can you rebase?

@tiborvass tiborvass Merge pull request #7286 from erikh/parsers
Move parsing functions to parsers/ and the specific kernel handling...
403df17
@ktap ktap closed this Aug 1, 2014
@ktap ktap deleted the unknown repository branch Aug 1, 2014
@ktap ktap restored the unknown repository branch Aug 1, 2014
@ktap ktap reopened this Aug 1, 2014
@ktap
ktap commented Aug 1, 2014

Sorry to response so later, now it's rebased.
Thanks.

@ktap
ktap commented Aug 1, 2014

ping @vbatts

@ktap ktap registry: Introduce DOCKER_REGISTRY_SSL_NO_VERIFY environment variable
Currently docker registry http request may block by some gateway
(for example, company web proxy), because of the certificate issue.

[root@localhost docker]# docker pull ubuntu
Pulling repository ubuntu
2014/05/15 15:51:24 Get https://index.docker.io/v1/repositories/ubuntu/images: x509: certificate signed by unknown authority

This patch introduce a new environment variable DOCKER_REGISTRY_SSL_NO_VERIFY
to control secure certificate verify. The default value is false.

The environment variable name comes from git: GIT_SSL_NO_VERIFY
(Similarly, wget and curl both have env variable or option to control secure verify)

Docker-DCO-1.1-Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com> (github: ktap)
afa8a0d
@vbatts
Contributor
vbatts commented Aug 6, 2014

#assignee=vbatts

@vbatts vbatts self-assigned this Aug 6, 2014
@vbatts vbatts commented on the diff Aug 11, 2014
@@ -287,6 +287,7 @@ Joseph Hager <ajhager@gmail.com>
Josh Hawn <josh.hawn@docker.com>
Josh <jokajak@gmail.com>
Josh Poimboeuf <jpoimboe@redhat.com>
+Jovi Zhangwei <jovi.zhangwei@gmail.com>
@vbatts
vbatts Aug 11, 2014 Contributor

Let's move this into it's own pull-request, please

@vbatts
Contributor
vbatts commented Aug 11, 2014

This does need to be documented somewhere, perhaps cli.md is the best place. I understand @SvenDowideit preferring flags, instead of env vars, but for something like disabling certificate validation, I wouldn't care for it to be obvious for use as a "regular use-case". There is a definite use-case for allowing this type of configuration.
@shykes ?

@SvenDowideit
Collaborator

@vbatts the thing about a rarely used option being an ENV var, is that if you set it, then go home for the weekend - what reminds you that its set later? surely, this is the kind of thing that needs to be in your face.

@vpopiol
vpopiol commented Sep 8, 2014

I can't pull images from my employer since there is an SSL intercepting firewall in place. Until this use case is addressed, it will be impossible for outfits like ours to consider using Docker and similar tools. Please help us. I was able to install the root certificate to the point of being able to curl https://some.site.com. But docker pull still responds with
docker@boot2docker:~$ docker pull hello-world
Pulling repository hello-world
2014/09/08 18:16:14 Get https://index.docker.io/v1/repositories/hello-world/imag
es: x509: certificate signed by unknown authority

Thanks

@baank
baank commented Sep 17, 2014

+1 for this.

Docker is currently unusable behind many corporate firewalls.

@joepuk
joepuk commented Sep 17, 2014

Another +1.

I've been waiting for this for 2 months now - it is blocking an evaluation of Docker behind a corporate firewall.

@crosbymichael
Member

@jlhawn @dmp42 what do you think about moving forward with this type of PR? Does it makes sense to you? I am almost convinced that this should be done.

@dmp42
Member
dmp42 commented Sep 17, 2014

@crosbymichael this is definitely needed.

@crosbymichael
Member

@tiborvass @unclejack @jfrazelle @aluzzardi

So I think we need something like this now. There are a few in favor of a --insecure flag on push, pull, etc.. instead of a daemon level env var or flag. What do you think is the best route that we should go down?

@jessfraz
Contributor

I prefer env variable over another flag

@unclejack
Contributor

@jfrazelle This needs to be a per command flag, not global.

@jessfraz
Contributor

but I can understand the flag if they are switching from home to work etc

@OOPMan
OOPMan commented Sep 17, 2014

I also prefer a flag

@crosbymichael
Member

Well right now the env var is applied to the daemon so there is no need to know what commands it should be applied to or not.

@unclejack
Contributor

The problem with the env var is that it applies globally. I can imagine there are use cases where you want to allow an insecure registry (corporate proxy) and make the others secure (local secure server).

@OOPMan
OOPMan commented Sep 17, 2014

I think a proper Secure SSL config is good in most production environments but in testing environments or some weird facist corporate environments (No offence intended dear corporate facist comrades!) it would be useful to just tell Docker to not think for itself :-) And hence a flag is nice.

@shykes
Contributor
shykes commented Sep 18, 2014
  • Yes on principle we need to allow a sysadmin to control ssl leniency
  • How we do it is critical. The wrong ui can cause all sorts of trouble
    (including security issues).
  • No env variables for configuration please. We have already discussed this
    in the past.
  • Passing it per-command seems too fine-grained. The end user should not be
    concerned with this: it is a site configuration issue. If for example the
    sysadmin enforces strict ssl check, should a client be allowed to override
    it? To me the answer is no, especially since images are cached and shared.
  • A global per-daemon flag is not ideal (no control per registry) but seems
    like an acceptable stopgap given the big demand for this (and how slowly we
    have addressed it).
  • The flag should never apply to the official Hub.
  • The long term solution I think will be to expand the daemon flag with a
    more powerful daemon config, which would allow per-host settings. When I
    get back to vacation I would like to tackle the general issue of daemon
    configuration: this is not the only place where it is needed, so a
    comprehensive config system will avoid fragmented custom solutions.

TLDR: let's do a global daemon flag for now, and talk next steps when i get
back.

On Wednesday, September 17, 2014, Adam Jorgensen notifications@github.com
wrote:

I think a proper Secure SSL config is good in most production environments
but in testing environments or some weird facist corporate environments (No
offence intended dear corporate facist comrades!) it would be useful to
just tell Docker to not think for itself :-)


Reply to this email directly or view it on GitHub
#5817 (comment).

@shykes
Contributor
shykes commented Sep 18, 2014

Last thing: since the daemon flag is a stopgap, please consider a flag name
which makes it clear that it affects all hosts, and will still make sense
even when per-host configuration is available. In the past we've been
bitten by successive "layers" of settings which interact with each other
but were designed at different times without thought for the others. The
result is utter confusion.

See for example CMD and ENTRYPOINT.

On Thursday, September 18, 2014, Solomon Hykes s@docker.com wrote:

  • Yes on principle we need to allow a sysadmin to control ssl leniency
  • How we do it is critical. The wrong ui can cause all sorts of trouble
    (including security issues).
  • No env variables for configuration please. We have already discussed
    this in the past.
  • Passing it per-command seems too fine-grained. The end user should not
    be concerned with this: it is a site configuration issue. If for example
    the sysadmin enforces strict ssl check, should a client be allowed to
    override it? To me the answer is no, especially since images are cached and
    shared.
  • A global per-daemon flag is not ideal (no control per registry) but
    seems like an acceptable stopgap given the big demand for this (and how
    slowly we have addressed it).
  • The flag should never apply to the official Hub.
  • The long term solution I think will be to expand the daemon flag with a
    more powerful daemon config, which would allow per-host settings. When I
    get back to vacation I would like to tackle the general issue of daemon
    configuration: this is not the only place where it is needed, so a
    comprehensive config system will avoid fragmented custom solutions.

TLDR: let's do a global daemon flag for now, and talk next steps when i
get back.

On Wednesday, September 17, 2014, Adam Jorgensen <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

I think a proper Secure SSL config is good in most production
environments but in testing environments or some weird facist corporate
environments (No offence intended dear corporate facist comrades!) it would
be useful to just tell Docker to not think for itself :-)


Reply to this email directly or view it on GitHub
#5817 (comment).

@ktap
ktap commented Sep 30, 2014

See new pull request: #8306
registry: Introduce --insecure daemon flag to control secure certificate verify with registry

@shreyu86

+1 this will be extremely helpful.

@crosbymichael
Member

Closing in favor of a solution like #8467 with a flag and explicit registry addresses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment