Home Explore Blog Models CI



docker

2nd chunk of `content/manuals/security/for-admins/hardened-desktop/registry-access-management.md`
b750af349a00930c52068678ee2c7e6dee1c146a24a83c600000000100000c60
 - Docker Hub. This is enabled by default.
 - Amazon ECR
 - GitHub Container Registry
 - Google Container Registry
 - GitLab Container Registry
 - Nexus
 - Artifactory

## Prerequisites

You must [enforce sign-in](../enforce-sign-in/_index.md). For Registry Access
Management to take effect, Docker Desktop users must authenticate to your
organization. Enforcing sign-in ensures that your Docker Desktop developers
always authenticate to your organization, even though they can authenticate
without it and the feature will take effect. Enforcing sign-in guarantees the
feature always takes effect.

## Configure Registry Access Management permissions

{{< tabs >}}
{{< tab name="Admin Console" >}}

{{% admin-registry-access product="admin" %}}

{{< /tab >}}
{{< tab name="Docker Hub" >}}

{{% include "hub-org-management.md" %}}

{{% admin-registry-access product="hub" %}}

{{< /tab >}}
{{< /tabs >}}

## Verify the restrictions

The new Registry Access Management policy takes effect after the developer
successfully authenticates to Docker Desktop using their organization
credentials. If a developer attempts to pull an image from a disallowed
registry via the Docker CLI, they receive an error message that the organization
has disallowed this registry.

## Caveats

There are certain limitations when using Registry Access Management:

- You can add up to 100 registries/domains.
- Windows image pulls and image builds are not restricted by default. For
Registry Access Management to take effect on Windows Container mode, you must
allow the Windows Docker daemon to use Docker Desktop's internal proxy by
selecting the [Use proxy for Windows Docker daemon](/manuals/desktop/settings-and-maintenance/settings.md#proxies)
setting.
- Builds such as `docker buildx` using a Kubernetes driver are not restricted.
- Builds such as `docker buildx` using a custom docker-container driver are not
restricted.
- Blocking is DNS-based. You must use a registry's access control mechanisms to
distinguish between “push” and “pull”.
- WSL 2 requires at least a 5.4 series Linux kernel (this does not apply to
earlier Linux kernel series).
- Under the WSL 2 network, traffic from all Linux distributions is restricted.
This will be resolved in the updated 5.15 series Linux kernel.
- Images pulled by Docker Desktop when Docker Debug or Kubernetes is enabled,
are not restricted by default even if Docker Hub is blocked by RAM.
- If Docker Hub access is restricted by RAM, pulls on images originating from Docker Hub are restricted even if the image has been previously cached by a registry mirror. See [Using Registry Access Management (RAM) with a registry mirror](/manuals/docker-hub/image-library/mirror.md).

Also, Registry Access Management operates on the level of hosts, not IP
addresses. Developers can bypass this restriction within their domain
resolution, for example by running Docker against a local proxy or modifying
their operating system's `sts` file. Blocking these forms of manipulation is
outside the remit of Docker Desktop.

## More resources

- [Video: Hardened Desktop Registry Access Management](https://www.youtube.com/watch?v=l9Z6WJdJC9A)

Title: Registry Access Management Configuration, Verification, and Caveats
Summary
This section details the configuration of Registry Access Management (RAM) via the Admin Console or Docker Hub, emphasizing the prerequisite of enforcing sign-in. It explains how to verify the policy's enforcement and outlines several limitations, including restrictions on the number of registries, Windows image pulls, and certain build types. It also highlights that blocking is DNS-based and lists specific considerations for WSL 2 and Docker Debug/Kubernetes usage. Finally, it provides a link to a video resource on Hardened Desktop Registry Access Management.