7 ms·

Docker Issue #1988 is still an issue. While it is still an issue, and still neglected (or more likely arbitrarily ignored for profit) Docker will be a red flag

Docker Issue #1988 is still an issue. While it is still an issue, and still neglected (or more likely arbitrarily ignored for profit) Docker will be a red flag for any real corporate uses.

shykes 12y ago
I agree it's still an issue. Enterprise sysadmins should be allowed to block access to external registries, including Docker Hub. There is nothing contentious about it, and it has nothing to do with profit. If you send a properly implemented patch for it, the maintainers will merge it.
- justinsb 12y ago
  That's great news. What do you consider a "properly implemented patch"? I would think the most bulletproof & simplest patch would simply allow the default index (index.docker.io) to be reconfigured to something else in docker.conf. Would you support a patch that did that? Edit: And perhaps https://registry-1.docker.io/v2/ https://registry-1.docker.io/v2/ as well?
  - shykes 12y ago
    I think the best way is to allow a "whitelist mode" where only an explicitly specified list of URLs are allowed to be reached. Everything else would be blocked by default. This should give ops the peace of mind they need. Note that this is an ACL change, and not a namespace change. That is important because we want image names to have the same meaning everywhere, regardless of site-specific configuration. So for example, "docker pull ubuntu" should always mean "install ubuntu from the official docker library". This is crucial to the developer experience and to respect the principle of separation of concern between dev and ops. However, if ops chooses to block access to the standard library then "docker pull ubuntu" will fail with "access blocked by your administrator", which is totally acceptable. What we don't want is the operation silently substituting a site-specific image, without the knowledge of the end user, thereby breaking their build in a thousand invisible ways. I hope this helps. Does this mean I should look forward to a patch from you? :)
    - justinsb 12y ago
      I will happily provide a patch that implements the desired functionality :-) However, I think people want the option of not using the docker registry. It is not under their control, it is slow, and it is a single point of failure. Having to recompile Docker to remove the magic constants is painful. I can see that the ACL functionality would be useful, but I don't think it addresses those concerns. Even if you believe it is a bad idea to allow users to change the meaning of image names, you should allow users the freedom to choose their own path. I think this is a fairly basic tenet of open-source: that true innovation comes when people are allowed to try new things, even if they look like a bad idea at the time.
      - shykes 12y ago
        I totally agree that users should be given the freedom to choose their own path. For example that's why we added pluggable backends for storage and sandboxing very early, before even shipping 1.0 :) At the same time, I care a lot about design and usability - and good design requires constraints. So there is a fundamental tension between flexibility and usability. My approach to this problem is to put usability first, and improve flexibility over time. The rationale is simple: you can always make things more flexible over time - but once usability is broken, it's almost impossible to fix. So, to apply this in the topic at hand: * Usability first: no matter what, don't break the predictable meaning of image names. * Flexibility over time, step 0: allow admins to block access to the Hub. Since the standard library is only hosted on the Hub, this blocks access to the standard library. Note that you are not at all required to use the Hub. You can refer to any other registry, today, simply by "docker pull URL". * Flexibility over time, step 1: allow hosting the standard library outside the Hub. The standard library is actually community project, very similar to Homebrew. The fact that it can only be hosted on the Hub is a technical limitation. We should lift that limitation, so that even if you block access to the Hub, you can still access the standard library. This could be via a private mirror, community-controller mirrors, or perhaps a bittorrent transport :) * Flexibility over time, step 2: allow complete control over which images are downloaded from where. This means completely separating the naming of images from their transport. This allows a sysadmin to compose an image storage and transport setup that fits their needs: S3 for this namespace, high-performance NFS filer for that, public bittorrent transport for this authorized subset of public images, Hub for the the QA department, etc. The key technical requirement here is to make image self-describing, and make cryptographic signature and verification mandatory.
kanzure 12y ago
> Docker Issue #1988 is still an issue. These may help: https://github.com/docker/docker/issues/8326 https://github.com/docker/docker/issues/8326 https://github.com/docker/docker/issues/8329 https://github.com/docker/docker/issues/8329

Docker Issue #1988 is still an issue. While it is still an issue, and still neglected (or more likely arbitrarily ignored for profit) Docker will be a red flag for any real corporate uses.

shykes 12y ago

I agree it's still an issue. Enterprise sysadmins should be allowed to block access to external registries, including Docker Hub. There is nothing contentious about it, and it has nothing to do with profit. If you send a properly implemented patch for it, the maintainers will merge it.

justinsb 12y ago
That's great news. What do you consider a "properly implemented patch"? I would think the most bulletproof & simplest patch would simply allow the default index (index.docker.io) to be reconfigured to something else in docker.conf. Would you support a patch that did that? Edit: And perhaps https://registry-1.docker.io/v2/ https://registry-1.docker.io/v2/ as well?
- shykes 12y ago
  I think the best way is to allow a "whitelist mode" where only an explicitly specified list of URLs are allowed to be reached. Everything else would be blocked by default. This should give ops the peace of mind they need. Note that this is an ACL change, and not a namespace change. That is important because we want image names to have the same meaning everywhere, regardless of site-specific configuration. So for example, "docker pull ubuntu" should always mean "install ubuntu from the official docker library". This is crucial to the developer experience and to respect the principle of separation of concern between dev and ops. However, if ops chooses to block access to the standard library then "docker pull ubuntu" will fail with "access blocked by your administrator", which is totally acceptable. What we don't want is the operation silently substituting a site-specific image, without the knowledge of the end user, thereby breaking their build in a thousand invisible ways. I hope this helps. Does this mean I should look forward to a patch from you? :)
  - justinsb 12y ago
    I will happily provide a patch that implements the desired functionality :-) However, I think people want the option of not using the docker registry. It is not under their control, it is slow, and it is a single point of failure. Having to recompile Docker to remove the magic constants is painful. I can see that the ACL functionality would be useful, but I don't think it addresses those concerns. Even if you believe it is a bad idea to allow users to change the meaning of image names, you should allow users the freedom to choose their own path. I think this is a fairly basic tenet of open-source: that true innovation comes when people are allowed to try new things, even if they look like a bad idea at the time.
    - shykes 12y ago
      I totally agree that users should be given the freedom to choose their own path. For example that's why we added pluggable backends for storage and sandboxing very early, before even shipping 1.0 :) At the same time, I care a lot about design and usability - and good design requires constraints. So there is a fundamental tension between flexibility and usability. My approach to this problem is to put usability first, and improve flexibility over time. The rationale is simple: you can always make things more flexible over time - but once usability is broken, it's almost impossible to fix. So, to apply this in the topic at hand: * Usability first: no matter what, don't break the predictable meaning of image names. * Flexibility over time, step 0: allow admins to block access to the Hub. Since the standard library is only hosted on the Hub, this blocks access to the standard library. Note that you are not at all required to use the Hub. You can refer to any other registry, today, simply by "docker pull URL". * Flexibility over time, step 1: allow hosting the standard library outside the Hub. The standard library is actually community project, very similar to Homebrew. The fact that it can only be hosted on the Hub is a technical limitation. We should lift that limitation, so that even if you block access to the Hub, you can still access the standard library. This could be via a private mirror, community-controller mirrors, or perhaps a bittorrent transport :) * Flexibility over time, step 2: allow complete control over which images are downloaded from where. This means completely separating the naming of images from their transport. This allows a sysadmin to compose an image storage and transport setup that fits their needs: S3 for this namespace, high-performance NFS filer for that, public bittorrent transport for this authorized subset of public images, Hub for the the QA department, etc. The key technical requirement here is to make image self-describing, and make cryptographic signature and verification mandatory.

kanzure 12y ago

> Docker Issue #1988 is still an issue. These may help: https://github.com/docker/docker/issues/8326 https://github.com/docker/docker/issues/8326 https://github.com/docker/docker/issues/8329 https://github.com/docker/docker/issues/8329