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
larskson Docker Hub. Nobody but me can create an image in thelarsksnamespace, 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(dneas in "does not exist", but anything works that isn’t a valid hostname), Docker will never be able to pull this image.