I’m trying to get around what I see as a security issue. If I am working on a project I call "example", I may build a docker image from it using docker build -t example .
, then run it using docker run example
. This will work properly, but if I forget to build first, or if I docker rmi
the image without rebuilding, then docker will query docker hub, and run that image instead.
I trust docker hub for images that I’m already aware of (I’m happy to run docker run nginx
or docker run postgres
, for example), but I’m worried about accidentally running arbitrary remote images if I forget to build my local docker image.
I know I could name my local images something esoteric so that collisions are unlikely, but that feels like security by obscurity.
2
Answers
Name your images with a registry or repository you control. In other words, don’t run:
Because that gets expanded to a Docker Official Image repo (aka docker.io/library/) that you don’t control. But you can create your own user account on Hub, allowing you to:
So that any image that doesn’t exist locally tries to pull from your namespace on Hub.
You don’t have to name your images something esoteric.
Use a namespace
Just register a namespace on docker hub, and then use that in your image names. E.g., I am
larsks
on Docker Hub. Nobody but me can create an image in thelarsks
namespace, so if I name a local imagelarsks/example
, I know that’s never going to resolve on Docker Hub unless I put it there.Use a bogus registry name
Maybe you don’t want to register with Docker Hub.
Recall that the fully qualified form of an image name is
registry/namespace/repository:tag
. If you name your local images with a nonexistent registry, Docker won’t be able to pull them from anywhere. E.g., if I name somethingdne/larsks/example
(dne
as in "does not exist", but anything works that isn’t a valid hostname), Docker will never be able to pull this image.