Yes. The Docker registry documentation says a production registry must be protected by TLS and should ideally use an access control mechanism, and that apart from registries on secure local networks, access restrictions should always be implemented. An open registry lets anyone read, and possibly overwrite, your images.
What an open registry exposes
A registry holds your built images. Those images often contain application code, configuration defaults, internal hostnames and sometimes secrets that were baked in by mistake. Anyone who can pull can read all of it.
If push is also open, the risk is worse. Someone who can push to a tag your deployments trust can replace the image behind it. Your cluster then runs their code on the next pull.
"Secure local network" is the one exception the docs give, and it is narrower than it sounds. Flat office networks, shared CI runners and VPN pools all count as places where a stray laptop or a compromised build agent can reach the registry.
The minimum setup
The deployment guide describes three steps in order.
- Terminate TLS. Put a CA issued certificate and key in place and point the registry at them with
REGISTRY_HTTP_TLS_CERTIFICATEandREGISTRY_HTTP_TLS_KEY. Self-signed certificates and insecure registries are described as testing tools. - Turn on authentication. The registry supports
htpasswd,tokenand a development onlysillyprovider. Only one can be configured at a time. - Test the result from outside. An unauthenticated request to
/v2/should return401with aWWW-Authenticatechallenge.
That third step is the one people skip. A registry that answers 200 to an anonymous request is open, whatever the config file says.
| Provider | Use for | Note |
|---|---|---|
htpasswd | Small teams, simple setups | bcrypt hashes only; use only with TLS |
token | Many users, central identity | More work to set up |
silly | Local development | Checks that a header exists, not its value |
Who gets which rights
Authentication answers who you are. It does not by itself separate people who may pull from people who may push or delete. Basic htpasswd has no such split. If you need read only users for deploy tooling and write access for CI, plan for token auth or an authenticating proxy in front, both of which the docs mention for more advanced needs.
Common mistakes
- Leaving the default development config in place. The deployment guide notes the default configuration is meant for development.
- Running basic auth over plain HTTP, which sends credentials in headers in clear text.
- Sharing one account across every pipeline, so a leaked credential gives full access and the logs cannot tell who did what.
- Never testing from a machine outside the trusted network.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the scan and note how much an image reveals about what is inside it. That is what an anonymous puller gets.
If you want to know what your images actually contain, Safeguard can scan container images and produce an SBOM, and there is a free scan at gold.safeguard.sh/scan.
Quick check
Is a registry on an internal network safe without a login?
Not by default. The docs only relax the advice for secure local networks, and most internal networks have CI runners, laptops and VPN users that you do not fully control.
Is htpasswd good enough?
For a small team over TLS, yes. It has no per user rights model, so use token auth or an authenticating proxy when you need separate read and write roles.
Sources
Last reviewed: 19 October 2026.
