A registry allowlist limits which registries developers reach, and Docker's Registry Access Management does that for Docker Desktop at the hostname level. It cannot stop determined bypass through local proxies or DNS changes, and some operations are not restricted. Treat it as one control, and add network and CI checks.
How it works
Docker's documentation describes Registry Access Management (RAM) as letting administrators control which registries developers can reach through Docker Desktop. It uses DNS-level filtering, so pulls and pushes are limited to an approved list. Admins add registries by address and nickname, and Docker Hub is enabled by default. The list can hold up to 100 registries or domains. A blocked pull fails with an error such as "registry access to [host] is not allowed."
Filtering is by hostname, not IP address, and redirect domains such as CDN or storage endpoints must be allowed too. The docs give AWS ECR as an example, where the registry host plus two Amazon storage domains are needed.
Documented gaps
The same page lists what RAM does not cover or can miss.
| Gap | What the docs say |
|---|---|
| Not signed in | RAM takes effect only for users signed in with organisation credentials |
| Propagation delay | Changes can take up to 24 hours |
| Multiple organisations | Only the first organisation's policy in the configuration file is enforced |
| Some tools | Buildx with the Kubernetes driver or a custom container driver, and some debug and Kubernetes pulls, are not restricted |
| Mirrors | Images already cached through registry mirrors may stay accessible |
| Local network changes | Users may bypass RAM through local proxies, DNS changes or network modifications outside Docker Desktop |
The docs recommend network-level controls for stronger enforcement.
What to add
- Enforce sign-in, because RAM depends on it.
- Put a network-level egress rule in place for build machines and servers, which do not run Docker Desktop at all.
- Check image references in pull requests. A rule that rejects an unapproved registry host catches the issue before a build runs.
- In clusters, use admission policy to restrict the registries pods may pull from.
- Log which registries your builds actually contact and compare with the allowlist now and then.
A reasonable allowlist
Start from what you really use. Collect the registry hosts in your Dockerfiles, Compose files and manifests, and add each host that has an owner and a reason. Remove the rest. Keep the list short, because the docs warn that too many domains may cause errors or hit system limits.
Allowlist is not the same as safe
Approving a registry approves a place, not every image in it. Public registries host both carefully maintained images and abandoned ones. Pair the allowlist with image-level checks: publisher, update history, a scan of the digest, and a pinned digest in your files.
Quick check
Does RAM protect servers and CI runners?
It applies to Docker Desktop users who are signed in. Servers and runners need network controls and CI checks.
Is filtering by IP address?
No. The documentation says filtering works at the hostname level, so redirect domains also need to be allowed.
Safeguard's policies and gates, dependency scanning and SBOM give you the image-level checks that sit alongside a registry allowlist. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
