New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--insecure-registry should be on "docker pull" #8887

Open
abourget opened this Issue Oct 31, 2014 · 166 comments

Comments

Projects
None yet
@abourget

abourget commented Oct 31, 2014

Hi folks, thanks for all your great work.

I was previously running a "library/registry" on localhost:5000. With Docker 1.3+, I was required to run docker with --insecure-registry localhost:5000. Doing so did nothing, until I discovered I needed to run docker, as in daemon, with those parameters.

It would be very useful to have that handled directly by docker pull, and not have to restart the whole thing and tweak system-level settings when you discover you need to use a local unsecure registry. EDIT: As mentioned in the comments, it would also be very useful to allow any registry to be unsecure, not just named ones, as Docker sometimes provides random ports, and some environments have many registries popping in and out of existence.

It is currently read here: https://github.com/docker/docker/blob/master/docker/daemon.go#L43 (while running the daemon), and it's checked while pulling in https://github.com/docker/docker/blob/master/graph/pull.go#L116 .. maybe we could add yet another switch to pull like --insecure and tweak that would forcefully make it secure == false ?

I don't have a docker development setup ready, but if you think it's a good idea.. I could try to implement it.

Linux cerise 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Docker version 1.3.1, build 4e9bbfa
Containers: 5
Images: 607
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 618
Execution Driver: native-0.2
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.1 LTS
Debug mode (server): false
Debug mode (client): true
Fds: 10
Goroutines: 11
EventsListeners: 0
Init Path: /usr/bin/docker
Username: abourget
Registry: [https://index.docker.io/v1/]
WARNING: No swap limit support
@octalthorpe

This comment has been minimized.

Show comment
Hide comment
@octalthorpe

octalthorpe Oct 31, 2014

We run internal unsecured docker registries in all CI and production environments. I must say that it would be very usefull to simply enable access to all insecure registries without having to list them out one by one. We have multiple registries in each environment for HA. This change has made things much more complicated for us. I am going to open another issues ticket that specifically to address that, as this issue is more to move the option to the pull rather than on the daemon.

octalthorpe commented Oct 31, 2014

We run internal unsecured docker registries in all CI and production environments. I must say that it would be very usefull to simply enable access to all insecure registries without having to list them out one by one. We have multiple registries in each environment for HA. This change has made things much more complicated for us. I am going to open another issues ticket that specifically to address that, as this issue is more to move the option to the pull rather than on the daemon.

@proppy

This comment has been minimized.

Show comment
Hide comment
@proppy

proppy Oct 31, 2014

Contributor

And there is a bit of a chicken and egg problem when you don't use a fixed port for running the registry.

Since you don't know which port will get assigned by docker in advance, you can't really start the demo with a flag that reference it.

Contributor

proppy commented Oct 31, 2014

And there is a bit of a chicken and egg problem when you don't use a fixed port for running the registry.

Since you don't know which port will get assigned by docker in advance, you can't really start the demo with a flag that reference it.

@reinh

This comment has been minimized.

Show comment
Hide comment
@reinh

reinh commented Oct 31, 2014

👍

@abourget

This comment has been minimized.

Show comment
Hide comment
@abourget

abourget Oct 31, 2014

so I guess supporting --insecure on the docker pull command line, forcefully disabling security checks, obviously for this pull command, would also solve you problem @proppy and @octalthorpe right ? as running with this flag wouldn't check lists whatsoever

abourget commented Oct 31, 2014

so I guess supporting --insecure on the docker pull command line, forcefully disabling security checks, obviously for this pull command, would also solve you problem @proppy and @octalthorpe right ? as running with this flag wouldn't check lists whatsoever

@proppy

This comment has been minimized.

Show comment
Hide comment
@proppy

proppy Oct 31, 2014

Contributor

@abourget it also need to be supported in the remote API.

Currently docker-py expose an insecure_registry flag on the pull function, but it's only used to resolve the endpoint: https://github.com/docker/docker-py/blob/master/docker/client.py#L794

Contributor

proppy commented Oct 31, 2014

@abourget it also need to be supported in the remote API.

Currently docker-py expose an insecure_registry flag on the pull function, but it's only used to resolve the endpoint: https://github.com/docker/docker-py/blob/master/docker/client.py#L794

@proppy

This comment has been minimized.

Show comment
Hide comment
@proppy

proppy Oct 31, 2014

Contributor

The culprid seems to be 6a1ff02

But I couldn't find the corresponding PR or issues where that change was discussed.

@tiborvass any ideas?

Contributor

proppy commented Oct 31, 2014

The culprid seems to be 6a1ff02

But I couldn't find the corresponding PR or issues where that change was discussed.

@tiborvass any ideas?

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch Oct 31, 2014

Contributor

@proppy - This was handled as an embargoed security vulnerability and was not discussed in a public PR. The core team had visibility and vote on the issue.

I need to contemplate on the implications of such a change for localhost/127.0.0.1, but I'm not particularly keen on it. It's a non-standard, uncommon configuration and the solution is well-documented.

Contributor

ewindisch commented Oct 31, 2014

@proppy - This was handled as an embargoed security vulnerability and was not discussed in a public PR. The core team had visibility and vote on the issue.

I need to contemplate on the implications of such a change for localhost/127.0.0.1, but I'm not particularly keen on it. It's a non-standard, uncommon configuration and the solution is well-documented.

@proppy

This comment has been minimized.

Show comment
Hide comment
@proppy

proppy Oct 31, 2014

Contributor

@ewindisch on the other hand there is a lot of docker daemon already running, with registry container running on localhost.

If literally all those users will need to pass --insecure-registry localhost:5000, you might as well make it the default.

Contributor

proppy commented Oct 31, 2014

@ewindisch on the other hand there is a lot of docker daemon already running, with registry container running on localhost.

If literally all those users will need to pass --insecure-registry localhost:5000, you might as well make it the default.

@mmdriley

This comment has been minimized.

Show comment
Hide comment
@mmdriley

mmdriley Oct 31, 2014

Contributor

@ewindisch Do you folks have documentation or guidance for what constitutes an embargo-class vulnerability? This isn't remote, unauthenticated RCE. The danger here doesn't seem nearly acute enough to justify a breaking change in a point release with no warning.

Contributor

mmdriley commented Oct 31, 2014

@ewindisch Do you folks have documentation or guidance for what constitutes an embargo-class vulnerability? This isn't remote, unauthenticated RCE. The danger here doesn't seem nearly acute enough to justify a breaking change in a point release with no warning.

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch Oct 31, 2014

Contributor

@mmdriley - the definition according to Mitre/NST generally applies. In this case, a man-in-the-middle attack is viable which allows the execution of arbitrary untrusted code on affected systems, so yes, we do classify this as a RCE. This means that if you were to use Docker to pull images on a laptop in a cafe, for instance, that another user of that WiFi access point could potentially run arbitrary applications provided by an attacker. They could also potentially gain access your DockerHub account or other registries to which you would authenticate.

EDIT: adding link for CVE description: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

Contributor

ewindisch commented Oct 31, 2014

@mmdriley - the definition according to Mitre/NST generally applies. In this case, a man-in-the-middle attack is viable which allows the execution of arbitrary untrusted code on affected systems, so yes, we do classify this as a RCE. This means that if you were to use Docker to pull images on a laptop in a cafe, for instance, that another user of that WiFi access point could potentially run arbitrary applications provided by an attacker. They could also potentially gain access your DockerHub account or other registries to which you would authenticate.

EDIT: adding link for CVE description: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

@mmdriley

This comment has been minimized.

Show comment
Hide comment
@mmdriley

mmdriley Oct 31, 2014

Contributor

Yep, I was wrong to say this wasn't RCE. It's a bad bug, and a great testament to why robust image signing is a great idea. However, exploitation isn't trivial: it requires an active attacker to hang out at Starbucks hoping someone nearby will use Docker over insecure WiFi. This isn't going to be weaponized overnight -- and therefore doesn't merit a backwards-incompatible change with no warning.

As has been suggested above, there were obvious ways to improve security immediately without breaking compatibility. For example, disabling HTTPS fallback for index.docker.io and the handful of other popular public registries would have effectively solved the problem for most users. Adding a warning to the console output that HTTP fallback was happening would have mitigated the interactive case. HTTP fallback would be marked deprecated and removed in, say, next month's release. Finally, localhost and ::1 are obviously not vulnerable.

Again, I shouldn't have discounted the extent of the vulnerability, but I'm worried that the response process and the fix didn't put enough value on not breaking customers.

Contributor

mmdriley commented Oct 31, 2014

Yep, I was wrong to say this wasn't RCE. It's a bad bug, and a great testament to why robust image signing is a great idea. However, exploitation isn't trivial: it requires an active attacker to hang out at Starbucks hoping someone nearby will use Docker over insecure WiFi. This isn't going to be weaponized overnight -- and therefore doesn't merit a backwards-incompatible change with no warning.

As has been suggested above, there were obvious ways to improve security immediately without breaking compatibility. For example, disabling HTTPS fallback for index.docker.io and the handful of other popular public registries would have effectively solved the problem for most users. Adding a warning to the console output that HTTP fallback was happening would have mitigated the interactive case. HTTP fallback would be marked deprecated and removed in, say, next month's release. Finally, localhost and ::1 are obviously not vulnerable.

Again, I shouldn't have discounted the extent of the vulnerability, but I'm worried that the response process and the fix didn't put enough value on not breaking customers.

@jwthomp

This comment has been minimized.

Show comment
Hide comment
@jwthomp

jwthomp Nov 3, 2014

We our currently creating/destroying docker registries dynamically in an environment that does not have FQDN available to many of these instances. Supporting a --insecure-repository option for registry related requests (over remote API) would remove significant complications this security fix has created for us.

jwthomp commented Nov 3, 2014

We our currently creating/destroying docker registries dynamically in an environment that does not have FQDN available to many of these instances. Supporting a --insecure-repository option for registry related requests (over remote API) would remove significant complications this security fix has created for us.

@kruxik

This comment has been minimized.

Show comment
Hide comment
@kruxik

kruxik Nov 4, 2014

We have similar problem with Docker 1.3.1. We use local (private) Docker registry on the address http://docker:5000/. Until Docker 1.3.0 it worked just fine. With Docker version 1.3.1 it doesn't work anymore because Docker client automatically assumes Registry is reachable on HTTPS. But we don't use HTTPS at all.

It would be nice to implement a fallback mechanism which uses HTTP if a Docker Registry servers is not accessible via HTTPS.

kruxik commented Nov 4, 2014

We have similar problem with Docker 1.3.1. We use local (private) Docker registry on the address http://docker:5000/. Until Docker 1.3.0 it worked just fine. With Docker version 1.3.1 it doesn't work anymore because Docker client automatically assumes Registry is reachable on HTTPS. But we don't use HTTPS at all.

It would be nice to implement a fallback mechanism which uses HTTP if a Docker Registry servers is not accessible via HTTPS.

@tiborvass

This comment has been minimized.

Show comment
Hide comment
@tiborvass

tiborvass Nov 4, 2014

Collaborator

@kruxik if you use --insecure-registry docker:5000 when starting the daemon, it will fallback to HTTP.

Collaborator

tiborvass commented Nov 4, 2014

@kruxik if you use --insecure-registry docker:5000 when starting the daemon, it will fallback to HTTP.

@kruxik

This comment has been minimized.

Show comment
Hide comment
@kruxik

kruxik Nov 4, 2014

@tiborvass thank you for the suggestion. You are correct. But if you have a lot of developers with their workstations and notebooks, setting --insecure-registry on each station is a way impractical. At least let it as an optional parameter for pull/push operations would be sufficient for us ;)

kruxik commented Nov 4, 2014

@tiborvass thank you for the suggestion. You are correct. But if you have a lot of developers with their workstations and notebooks, setting --insecure-registry on each station is a way impractical. At least let it as an optional parameter for pull/push operations would be sufficient for us ;)

@epankala

This comment has been minimized.

Show comment
Hide comment
@epankala

epankala Nov 5, 2014

+1

This worked for us with 1.3.0, but with 1.3.1

docker version
....
Server version: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> ....If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add --insecure-registry 10.121.4.236:5000 to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at

Downgrade
Server version: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> container uploads without problems.

epankala commented Nov 5, 2014

+1

This worked for us with 1.3.0, but with 1.3.1

docker version
....
Server version: 1.3.1
....
docker push 10.121.4.236:5000/debian7/consul
-> ....If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add --insecure-registry 10.121.4.236:5000 to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at

Downgrade
Server version: 1.3.0
docker push 10.121.4.236:5000/debian7/consul
-> container uploads without problems.

@mhamrah

This comment has been minimized.

Show comment
Hide comment
@mhamrah

mhamrah Nov 5, 2014

For others having issues with the 1.3.0 to 1.3.1, I had to make the following changes for OS X with boot2docker:

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

then you should be able to do a docker pull.

If using fig, you also need Fig 1.0.1 and do:

$ fig up --allow-insecure-ssl

mhamrah commented Nov 5, 2014

For others having issues with the 1.3.0 to 1.3.1, I had to make the following changes for OS X with boot2docker:

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

then you should be able to do a docker pull.

If using fig, you also need Fig 1.0.1 and do:

$ fig up --allow-insecure-ssl
@jdongelmans

This comment has been minimized.

Show comment
Hide comment
@jdongelmans

jdongelmans Nov 6, 2014

@mhamrah Thanks! Spent hours trying to fix this...

jdongelmans commented Nov 6, 2014

@mhamrah Thanks! Spent hours trying to fix this...

@thockin

This comment has been minimized.

Show comment
Hide comment
@thockin

thockin Nov 6, 2014

Contributor

+1 to assuming localhost is secure. Is anyone actually against this?

Contributor

thockin commented Nov 6, 2014

+1 to assuming localhost is secure. Is anyone actually against this?

@jasonwatt

This comment has been minimized.

Show comment
Hide comment
@jasonwatt

jasonwatt Nov 6, 2014

Yea, assuming localhost is secure would help a lot. i use vagrant for my docker box, so updating the init script every time i destroy or bring up a box is just inefficient. I guess i will now have to puppetize my docker box so that i can modify the init on the vagrant up.

also using an --insecure flag on the pull and push would be nice so i could use the vagrant box IP if needed.

jasonwatt commented Nov 6, 2014

Yea, assuming localhost is secure would help a lot. i use vagrant for my docker box, so updating the init script every time i destroy or bring up a box is just inefficient. I guess i will now have to puppetize my docker box so that i can modify the init on the vagrant up.

also using an --insecure flag on the pull and push would be nice so i could use the vagrant box IP if needed.

@proppy

This comment has been minimized.

Show comment
Hide comment
@proppy

proppy Nov 6, 2014

Contributor

@Thocking: le assuming localhost is secure: please see #8898

Contributor

proppy commented Nov 6, 2014

@Thocking: le assuming localhost is secure: please see #8898

@gopalfreak

This comment has been minimized.

Show comment
Hide comment
@gopalfreak

gopalfreak Nov 7, 2014

To be honest I also was wondering why my automated Jenkins Containerbuilds failed in pushing...
(Good to have a testenv. before putting it to production).
I have to check if this "feature" was really annouced - if not I will be more paranoid on so extreme massive changes on daemons behaviour.

What I miss in this discussion:
Why I even have to tell the daemon to use "default" secure / unsecure mode for each host?

Shouldn't it be more productive to setup the registry with this default behaviour?
So depending on the setup if no --secure or --insecure parameter is given the daemon should request
if secure way is possible and if not that the fallback to unsecure was used .

One of the main things of docker is that it's completly easy to use and to setup a complete env. please don't kill this WOW effect with such "releases / decisions"...

just my 2 cents...

gopalfreak commented Nov 7, 2014

To be honest I also was wondering why my automated Jenkins Containerbuilds failed in pushing...
(Good to have a testenv. before putting it to production).
I have to check if this "feature" was really annouced - if not I will be more paranoid on so extreme massive changes on daemons behaviour.

What I miss in this discussion:
Why I even have to tell the daemon to use "default" secure / unsecure mode for each host?

Shouldn't it be more productive to setup the registry with this default behaviour?
So depending on the setup if no --secure or --insecure parameter is given the daemon should request
if secure way is possible and if not that the fallback to unsecure was used .

One of the main things of docker is that it's completly easy to use and to setup a complete env. please don't kill this WOW effect with such "releases / decisions"...

just my 2 cents...

@ajhodges

This comment has been minimized.

Show comment
Hide comment
@ajhodges

ajhodges Mar 15, 2017

+1, if having a client-side --insecure-registry flag is not an option, there should be a way to specify a trusted certificate to be used for docker pull and docker push. Not everyone has access to trust certificates on a OS-level, or access to play around with the Docker daemon.

Hosted CI servers (that are being used to build docker images and push to a private registry) are a great example of when you might not have that level of access.

ajhodges commented Mar 15, 2017

+1, if having a client-side --insecure-registry flag is not an option, there should be a way to specify a trusted certificate to be used for docker pull and docker push. Not everyone has access to trust certificates on a OS-level, or access to play around with the Docker daemon.

Hosted CI servers (that are being used to build docker images and push to a private registry) are a great example of when you might not have that level of access.

@ericpulvino

This comment has been minimized.

Show comment
Hide comment
@ericpulvino

ericpulvino commented Mar 23, 2017

+1

@tiborvass

This comment has been minimized.

Show comment
Hide comment
@ajhodges

This comment has been minimized.

Show comment
Hide comment
@ajhodges

ajhodges Mar 24, 2017

@tiborvass
Only works if you have sudo access...

ajhodges commented Mar 24, 2017

@tiborvass
Only works if you have sudo access...

@zadam

This comment has been minimized.

Show comment
Hide comment
@zadam

zadam Apr 3, 2017

+1 good way to discourage devs from using docker

zadam commented Apr 3, 2017

+1 good way to discourage devs from using docker

@PhilippHeuer

This comment has been minimized.

Show comment
Hide comment
@PhilippHeuer

PhilippHeuer Apr 7, 2017

+1, i would like to see --insecure-registry for docker login too.

I don't even see this as a security issue, since you are consciously doing it. And if someone unauthorized got root access this won't provide any security either. What merit does this restriction actually have?

If you had bad intentions you could just upload your malicious docker image to the DockerHub, which is trusted.

PhilippHeuer commented Apr 7, 2017

+1, i would like to see --insecure-registry for docker login too.

I don't even see this as a security issue, since you are consciously doing it. And if someone unauthorized got root access this won't provide any security either. What merit does this restriction actually have?

If you had bad intentions you could just upload your malicious docker image to the DockerHub, which is trusted.

@navels

This comment has been minimized.

Show comment
Hide comment
@navels

navels May 11, 2017

+1 and frankly this boggles the mind

navels commented May 11, 2017

+1 and frankly this boggles the mind

@Ichimonji10

This comment has been minimized.

Show comment
Hide comment
@Ichimonji10

Ichimonji10 May 11, 2017

+1 to the pain train.

Ichimonji10 commented May 11, 2017

+1 to the pain train.

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 11, 2017

WIP: Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

NOTE: This new test only works when the registry under test (think: pulp
and crane) are on the same system as the docker client, i.e. localhost.
Otherwise, an SSL error results. This is because the registries provided
by our Pulp + Crane test systems are available via HTTP, and `docker
pull` cannot be run over HTTP without some gymnastics. See:
moby/moby#8887

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 11, 2017

WIP: Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

NOTE: This new test only works when the docker client is on the same
system as the registry under test (think: pulp and crane). If the docker
client and the registry under test are on different systems, and SSL
error results. This is because the registries provided by our Pulp +
Crane test systems are available via HTTP, and `docker pull` cannot be
run over HTTP without some gymnastics. See:
moby/moby#8887

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 11, 2017

WIP: Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

NOTE: This new test only works when the docker client is on the same
system as the registry under test (think: pulp and crane). If the docker
client and the registry under test are on different systems, and SSL
error results. This is because the registries provided by our Pulp +
Crane test systems are available via HTTP, and `docker pull` cannot be
run over HTTP without some gymnastics. See:
moby/moby#8887

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 11, 2017

WIP: Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

NOTE: This new test only works when the docker client is on the same
system as the registry under test (think: pulp and crane). If the docker
client and the registry under test are on different systems, and SSL
error results. This is because the registries provided by our Pulp +
Crane test systems are available via HTTP, and `docker pull` cannot be
run over HTTP without some gymnastics. See:
moby/moby#8887
@harindaka

This comment has been minimized.

Show comment
Hide comment
@harindaka

harindaka May 12, 2017

Plus F*cking One!

harindaka commented May 12, 2017

Plus F*cking One!

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 12, 2017

WIP: Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

NOTE: This new test only works when the docker client is on the same
system as the registry under test (think: pulp and crane). If the docker
client and the registry under test are on different systems, and SSL
error results. This is because the registries provided by our Pulp +
Crane test systems are available via HTTP, and `docker pull` cannot be
run over HTTP without some gymnastics. See:
moby/moby#8887
@jaytaylor

This comment has been minimized.

Show comment
Hide comment
@jaytaylor

jaytaylor May 12, 2017

Is there a PR open for this?

jaytaylor commented May 12, 2017

Is there a PR open for this?

@Ichimonji10

This comment has been minimized.

Show comment
Hide comment
@Ichimonji10

Ichimonji10 May 12, 2017

Not AFAIK. The links above are generated because some of my own code references this issue. I'll pull that reference for a while to quiet down the spam here.

Ichimonji10 commented May 12, 2017

Not AFAIK. The links above are generated because some of my own code references this issue. I'll pull that reference for a while to quiet down the spam here.

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 16, 2017

Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

This new test only works when the docker client and the registry under
test (pulp + crane) are on the same system. An SSL error occurs when the
docker client and the registry under test are on different systems. This
is because the registry under test is available via HTTP, and `docker
pull` cannot be run over HTTP without some gymnastics.

See: moby/moby#8887

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 18, 2017

Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

This new test only works when the docker client and the registry under
test (pulp + crane) are on the same system. An SSL error occurs when the
docker client and the registry under test are on different systems. This
is because the registry under test is available via HTTP, and `docker
pull` cannot be run over HTTP without some gymnastics.

See: moby/moby#8887

Ichimonji10 added a commit to Ichimonji10/pulp-smash that referenced this issue May 19, 2017

Add test: pull docker repo by tag
Add method `test_02_docker_pull_by_tag` to `SyncPublishV2TestCase`. This
new test verifies that it is possible to execute `docker pull <url>`,
where `<url>` includes a tag ("latest").

See: PulpQE#555

This new test only works when the docker client and the registry under
test (pulp + crane) are on the same system. An SSL error occurs when the
docker client and the registry under test are on different systems. This
is because the registry under test is available via HTTP, and `docker
pull` cannot be run over HTTP without some gymnastics.

See: moby/moby#8887
@waldman

This comment has been minimized.

Show comment
Hide comment
@waldman

waldman Aug 10, 2017

+1 as well...

waldman commented Aug 10, 2017

+1 as well...

@mmchen

This comment has been minimized.

Show comment
Hide comment
@mmchen

mmchen commented Sep 26, 2017

+1

@eromoe

This comment has been minimized.

Show comment
Hide comment
@eromoe

eromoe Nov 10, 2017

+1 , it is very inconvenient to add setting to deamon.json and restart docker.

Different machines have different os . Some install docker from yumapt-get , and some directly using binary . So I have to detect that and restart dockerd correctly .... that 's a disaster

I just stress docker pull need --insecure-registry flag !

eromoe commented Nov 10, 2017

+1 , it is very inconvenient to add setting to deamon.json and restart docker.

Different machines have different os . Some install docker from yumapt-get , and some directly using binary . So I have to detect that and restart dockerd correctly .... that 's a disaster

I just stress docker pull need --insecure-registry flag !

@r-chris

This comment has been minimized.

Show comment
Hide comment
@r-chris

r-chris Dec 5, 2017

It's only been three years - let's not lose hope now

r-chris commented Dec 5, 2017

It's only been three years - let's not lose hope now

@justinclayton

This comment has been minimized.

Show comment
Hide comment
@justinclayton

justinclayton commented Feb 7, 2018

bump 🤣

@schwaizi

This comment has been minimized.

Show comment
Hide comment
@schwaizi

schwaizi commented Mar 27, 2018

+1

@sherif84

This comment has been minimized.

Show comment
Hide comment
@sherif84

sherif84 commented Apr 18, 2018

+1

@mmpfeffer

This comment has been minimized.

Show comment
Hide comment
@mmpfeffer

mmpfeffer Apr 26, 2018

The argument that this encourages users to set their registries as secure is not only presumptuous, it also missing a key point. It puts operations in the position where many people must have access to the root account in order to do their operations work, where docker registries are moving around a lot.
That coupling, from an operational security standpoint, creates greater security risk.

Secondly, in a private network (such as in a multi-tiered cloud-hosted application), the securing of registries is not necessary, and further complicates technology implementations which sit on top, requiring layers of security management (to handle automated docker authentication/refresh) wherever a secure docker registry is used.

At the very least, the docker daemon should be configurable to ALLOW insecure registry parameter to be passed in. That moves the security design to the proper place - in the hands of the administrator, and outside of docker itself.

mmpfeffer commented Apr 26, 2018

The argument that this encourages users to set their registries as secure is not only presumptuous, it also missing a key point. It puts operations in the position where many people must have access to the root account in order to do their operations work, where docker registries are moving around a lot.
That coupling, from an operational security standpoint, creates greater security risk.

Secondly, in a private network (such as in a multi-tiered cloud-hosted application), the securing of registries is not necessary, and further complicates technology implementations which sit on top, requiring layers of security management (to handle automated docker authentication/refresh) wherever a secure docker registry is used.

At the very least, the docker daemon should be configurable to ALLOW insecure registry parameter to be passed in. That moves the security design to the proper place - in the hands of the administrator, and outside of docker itself.

@mjambon

This comment has been minimized.

Show comment
Hide comment
@mjambon

mjambon Sep 13, 2018

FWIW I'd be happy with a command to "add some registry to the list of insecure registries", since patching json configs from shell scripts is a major pain point.

mjambon commented Sep 13, 2018

FWIW I'd be happy with a command to "add some registry to the list of insecure registries", since patching json configs from shell scripts is a major pain point.

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