[netsectoday]

You can run your own private Docker registry but you will still depend upon the base images pulled from hub.docker.com in your deploy chain unless you make sure to clone the base image Dockerfile from github and build it yourself. Even with this protected setup; you still have exposure from poisoned Github repos after this attack because of the compromised Github access keys. I'm not sure you can eliminate this threat, even with third-party services. What a mess.

[lskillen]

It might be OK for the Docker Hub aspect at least, with a caveat later on; the GitHub aspect is unfortunate and I completely agree. Direct access to source is rather dangerous territory.

Back to the images bit first:

Base images are only referenced/pulled at build time. So if you've already built your own image and stored it, it'll contain all of the layers necessary to run it without explicitly pulling from Docker Hub.

In the case that you're building new images (likely), it'll need to pull the base images from Docker Hub. However, if you pull the base image(s) from Docker Hub first, you can tag them and store them in your local (or hosted) registry, then refer to those explicitly instead.

For example (using a Cloudsmith hosted registry):

  docker pull alpine:3.8
  docker tag alpine:3.8 docker.cloudsmith.io/your-account/your-repo/alpine:3.8
  docker push docker.cloudsmith.io/your-account/your-repo/alpine:3.8

Now, instead of the usual FROM directive:

  FROM alpine:3.8

You can refer to your own copy of alpine:

  FROM docker.cloudsmith.io/your-account/your-repo/alpine:3.8

As you can see Docker's syntax doesn't make this extremely pleasant, and you'll have to change existing Dockerfiles to point at the base images, but it's certainly possible to mirror your dependencies without rebuilding.

Caveat: The downside is that you have to trust those dependencies at the exact point you pull them down, so I concede it is still not perfect without rebuilding the lot. :-)