5 ms·

>I think the habit for most folks (and the best practice) is to use one of the "official" Ruby images. Ah, I didn't realize there was a blessed subset of repos

>I think the habit for most folks (and the best practice) is to use one of the "official" Ruby images. Ah, I didn't realize there was a blessed subset of repositories for which the Docker team has independently verified the identity. Are these signed with some sort of crypto and known-good keys, similar to package signing keys attached to a package repo, or are we taking Docker's word for it? Is there a way to filter to "official" repositories only, or tell Docker to only fetch from a whitelist of repositories (so that private ones can be included)? While it is nice that there are a few known-good repositories for projects popular enough to secure the approval of Docker Inc., the habit of casually importing images is still rampant, afaict. >Far from opaque, the official images are typically well-documented, and the source code is available from the various Git repositories linked to from the library. Well, here's an example [0] of a base Dockerfile. I had to go 3 levels up from the link on the Docker Hub page to get to this one because most of the images are FROM:something. After chasing the tree up, this is a) still derived from some other upstream Dockerfile (must this file also be validated by Docker to qualify as an "official repo"?) and b) a good example of the "brilliance" of the Dockerfile format. That massive set of line continuations is necessary because if you implement the Dockerfile "naively", by making each modification a "RUN" command, you end up with an image that is very bloated due to the way Docker's caching layer functions. Bonus feature: if any of those commands is to return a non-0 exit code, the line will abort. Is this "transparency" only the case on "official" images? As far as I can see Docker Hub just stores the pushed binary blob and not the Dockerfile required to build it, so if you're not picking your image base carefully, there may not be a way to verify its contents (short of introspecting the image). [0] https://github.com/docker-library/ruby/blob/752c5f7cf44870ceae77134b346d20093053c370/2.4/Dockerfile https://github.com/docker-library/ruby/blob/752c5f7cf44870ce...

mwpmaybe 10y ago
> Are these signed with some sort of crypto and known-good keys, similar to package signing keys attached to a package repo, or are we taking Docker's word for it? I'm not sure. You can find more information about them here[0]. > Is there a way to filter to "official" repositories only, or tell Docker to only fetch from a whitelist of repositories (so that private ones can be included)? I'm not sure about this either. It looks like Rancher and OpenShift support whitelisting registries, so this may have to be handled at a higher level. I believe you can always tell whether something being pulled from Docker Hub is official because it won't have a leading path component indicating the contributor (e.g. mwpmaybe/ruby:2.4-alpine is a non-official image whereas ruby:2.4-alpine is official). > the habit of casually importing images is still rampant This is just my two cents, but that seems like a policy problem, not a technology problem. Enforce a rule for your project/team/organization that containers have to use an official image, or a private image based on an official image. I do agree that a simple per-registry namespace whitelist would be a nice feature to have in dockerd. > a) still derived from some other upstream Dockerfile (must this file also be validated by Docker to qualify as an "official repo"?) I believe official images must be based on other official images. > b) a good example of the "brilliance" of the Dockerfile format I don't think it was ever meant to be brilliant, just simple. I'm definitely looking forward to the next generation of Dockerfile formats that ameliorate this issue and many others. > Is this "transparency" only the case on "official" images? As far as I can see Docker Hub just stores the pushed binary blob and not the Dockerfile required to build it, so if you're not picking your image base carefully, there may not be a way to verify its contents (short of introspecting the image). I believe so. This is a complaint I have with Docker Hub. I personally feel that the Dockerfiles used to create public images should always be published along with the images. 0. https://docs.docker.com/docker-hub/official_repos/ https://docs.docker.com/docker-hub/official_repos/
- cookiecaper 10y ago
  >This is just my two cents, but that seems like a policy problem, not a technology problem. Software that makes dangerous things too easy is a technology problem. This is why Linux distros require signed packages by default. Furthermore, one of Docker's popular appeals is "never get stuck in dependency hell again: just install someone's container!" You see more and more projects saying "The best way to install this is just to use our Docker container." The culture is definitely not leading to a security-minded perspective. Compare with something like Ansible Playbooks, where the commands executed are always visible. >I don't think it was ever meant to be brilliant, just simple. Requiring long continuations for reasonable image sizes is not simple. Without the continuations, final image sizes regularly bloat to be larger than a typical distro ISO. On the other hand, exchanging the cached layers for size nullifies some of Docker's claimed value, specifically wrt atomicity and build time.
  - mwpmaybe 10y ago
    > Requiring long continuations for reasonable image sizes is not simple. We're just arguing semantics at this point. I mean "simple" like Assembler is simple: rudimentary instructions requiring a certain amount of understanding and sophistication to wield correctly. Not "simple" as in easy, intuitive, and footgun-free.
xnxn 10y ago
> Is there a way to filter to "official" repositories only, or tell Docker to only fetch from a whitelist of repositories (so that private ones can be included)? In Kubernetes land, you can use the ImagePolicyWebhook admission controller. https://kubernetes.io/docs/admin/admission-controllers/#imagepolicywebhook https://kubernetes.io/docs/admin/admission-controllers/#imag... I agree that Dockerfiles are awful.
deizel 10y ago
I believe most of your questions have a (mostly) positive answer. Admittedly the Docker project moves fast, so I've tried to provide a link or two for each: > Are these signed with some sort of crypto and known-good keys, similar to package signing keys attached to a package repo, or are we taking Docker's word for it? The official images are all signed with Notary[0] (released <2 years ago). The "Content Trust" feature makes use of TLS plus a number of keys[1]. It can be enabled in required environments to prevent the pulling of non-signed images (`export DOCKER_CONTENT_TRUST=1`). > I had to go 3 levels up from the link on the Docker Hub page to get to this one because most of the images are FROM:something. There is a helpful Chrome extension, OctoLinker[2], that makes the `FROM parent` clickable (among other non-Docker things). I'm sure there are similar extensions, but this is the one I currently use. > a) still derived from some other upstream Dockerfile (must this file also be validated by Docker to qualify as an "official repo"?) The `FROM` line in the Dockerfile would likely be the first thing to undergo scrutiny, for obvious reasons. Also, all the layers go through security scanning[3], some issues can be fixed[4] and others are tracked upstream (e.g. by Debian in the case of the Ruby image you linked[5]). > you end up with an image that is very bloated due to the way Docker's caching layer functions You can now use `docker build --squash`[6] to combine multiple image layers while still benefiting from layer caching during builds. Also, the final image won't contain files that are added in previous layers and removed in later ones. (And with multi-stage builds recently merged, soon multiple inheritance will be easier.) > Is this "transparency" only the case on "official" images? As far as I can see Docker Hub just stores the pushed binary blob and not the Dockerfile required to build it I would say groups or sole developers that want others to use their images will usually provide documentation and links to the Dockerfiles. Of course, this isn't always possible or desired (e.g. see closed-source projects like Windows Server Core[7], or the countless people using Docker Hub as a free image host.) [0]: https://github.com/docker/notary https://github.com/docker/notary [1]: https://docs.docker.com/engine/security/trust/trust_key_mng/ https://docs.docker.com/engine/security/trust/trust_key_mng/ [2]: https://octolinker.github.io/ https://octolinker.github.io/ [3]: https://docs.docker.com/docker-hub/official_repos/#how-do-i-know-the-official-repositories-are-secure https://docs.docker.com/docker-hub/official_repos/#how-do-i-... [4]: https://github.com/docker-library/official-images/pulls?utf8=%E2%9C%93&q=CVE%20in%3Atitle https://github.com/docker-library/official-images/pulls?utf8... [5]: https://github.com/docker-library/ruby/issues/117 https://github.com/docker-library/ruby/issues/117 [6]: https://docs.docker.com/engine/reference/commandline/build/#squash-an-images-layers---squash-experimental-only https://docs.docker.com/engine/reference/commandline/build/#... [7]: https://hub.docker.com/r/microsoft/windowsservercore/ https://hub.docker.com/r/microsoft/windowsservercore/

mwpmaybe 10y ago

> Are these signed with some sort of crypto and known-good keys, similar to package signing keys attached to a package repo, or are we taking Docker's word for it? I'm not sure. You can find more information about them here[0]. > Is there a way to filter to "official" repositories only, or tell Docker to only fetch from a whitelist of repositories (so that private ones can be included)? I'm not sure about this either. It looks like Rancher and OpenShift support whitelisting registries, so this may have to be handled at a higher level. I believe you can always tell whether something being pulled from Docker Hub is official because it won't have a leading path component indicating the contributor (e.g. mwpmaybe/ruby:2.4-alpine is a non-official image whereas ruby:2.4-alpine is official). > the habit of casually importing images is still rampant This is just my two cents, but that seems like a policy problem, not a technology problem. Enforce a rule for your project/team/organization that containers have to use an official image, or a private image based on an official image. I do agree that a simple per-registry namespace whitelist would be a nice feature to have in dockerd. > a) still derived from some other upstream Dockerfile (must this file also be validated by Docker to qualify as an "official repo"?) I believe official images must be based on other official images. > b) a good example of the "brilliance" of the Dockerfile format I don't think it was ever meant to be brilliant, just simple. I'm definitely looking forward to the next generation of Dockerfile formats that ameliorate this issue and many others. > Is this "transparency" only the case on "official" images? As far as I can see Docker Hub just stores the pushed binary blob and not the Dockerfile required to build it, so if you're not picking your image base carefully, there may not be a way to verify its contents (short of introspecting the image). I believe so. This is a complaint I have with Docker Hub. I personally feel that the Dockerfiles used to create public images should always be published along with the images. 0. https://docs.docker.com/docker-hub/official_repos/ https://docs.docker.com/docker-hub/official_repos/

cookiecaper 10y ago
>This is just my two cents, but that seems like a policy problem, not a technology problem. Software that makes dangerous things too easy is a technology problem. This is why Linux distros require signed packages by default. Furthermore, one of Docker's popular appeals is "never get stuck in dependency hell again: just install someone's container!" You see more and more projects saying "The best way to install this is just to use our Docker container." The culture is definitely not leading to a security-minded perspective. Compare with something like Ansible Playbooks, where the commands executed are always visible. >I don't think it was ever meant to be brilliant, just simple. Requiring long continuations for reasonable image sizes is not simple. Without the continuations, final image sizes regularly bloat to be larger than a typical distro ISO. On the other hand, exchanging the cached layers for size nullifies some of Docker's claimed value, specifically wrt atomicity and build time.
- mwpmaybe 10y ago
  > Requiring long continuations for reasonable image sizes is not simple. We're just arguing semantics at this point. I mean "simple" like Assembler is simple: rudimentary instructions requiring a certain amount of understanding and sophistication to wield correctly. Not "simple" as in easy, intuitive, and footgun-free.

xnxn 10y ago

> Is there a way to filter to "official" repositories only, or tell Docker to only fetch from a whitelist of repositories (so that private ones can be included)? In Kubernetes land, you can use the ImagePolicyWebhook admission controller. https://kubernetes.io/docs/admin/admission-controllers/#imagepolicywebhook https://kubernetes.io/docs/admin/admission-controllers/#imag... I agree that Dockerfiles are awful.

deizel 10y ago

I believe most of your questions have a (mostly) positive answer. Admittedly the Docker project moves fast, so I've tried to provide a link or two for each: > Are these signed with some sort of crypto and known-good keys, similar to package signing keys attached to a package repo, or are we taking Docker's word for it? The official images are all signed with Notary[0] (released <2 years ago). The "Content Trust" feature makes use of TLS plus a number of keys[1]. It can be enabled in required environments to prevent the pulling of non-signed images (`export DOCKER_CONTENT_TRUST=1`). > I had to go 3 levels up from the link on the Docker Hub page to get to this one because most of the images are FROM:something. There is a helpful Chrome extension, OctoLinker[2], that makes the `FROM parent` clickable (among other non-Docker things). I'm sure there are similar extensions, but this is the one I currently use. > a) still derived from some other upstream Dockerfile (must this file also be validated by Docker to qualify as an "official repo"?) The `FROM` line in the Dockerfile would likely be the first thing to undergo scrutiny, for obvious reasons. Also, all the layers go through security scanning[3], some issues can be fixed[4] and others are tracked upstream (e.g. by Debian in the case of the Ruby image you linked[5]). > you end up with an image that is very bloated due to the way Docker's caching layer functions You can now use `docker build --squash`[6] to combine multiple image layers while still benefiting from layer caching during builds. Also, the final image won't contain files that are added in previous layers and removed in later ones. (And with multi-stage builds recently merged, soon multiple inheritance will be easier.) > Is this "transparency" only the case on "official" images? As far as I can see Docker Hub just stores the pushed binary blob and not the Dockerfile required to build it I would say groups or sole developers that want others to use their images will usually provide documentation and links to the Dockerfiles. Of course, this isn't always possible or desired (e.g. see closed-source projects like Windows Server Core[7], or the countless people using Docker Hub as a free image host.) [0]: https://github.com/docker/notary https://github.com/docker/notary [1]: https://docs.docker.com/engine/security/trust/trust_key_mng/ https://docs.docker.com/engine/security/trust/trust_key_mng/ [2]: https://octolinker.github.io/ https://octolinker.github.io/ [3]: https://docs.docker.com/docker-hub/official_repos/#how-do-i-know-the-official-repositories-are-secure https://docs.docker.com/docker-hub/official_repos/#how-do-i-... [4]: https://github.com/docker-library/official-images/pulls?utf8=%E2%9C%93&q=CVE%20in%3Atitle https://github.com/docker-library/official-images/pulls?utf8... [5]: https://github.com/docker-library/ruby/issues/117 https://github.com/docker-library/ruby/issues/117 [6]: https://docs.docker.com/engine/reference/commandline/build/#squash-an-images-layers---squash-experimental-only https://docs.docker.com/engine/reference/commandline/build/#... [7]: https://hub.docker.com/r/microsoft/windowsservercore/ https://hub.docker.com/r/microsoft/windowsservercore/