# Context The container registry uses the GitLab API authorization framework as described in [the documentation](https://docs.gitlab.com/ee/user/packages/container_registry/#authenticate-with-the-container-registry). The document currently states: ```markdown # Authenticate with the Container Registry Before you can build and push images, you must authenticate with the Container Registry. To authenticate, you can use: - A personal access token. - A deploy token. Both of these require the minimum scope to be: - For read (pull) access, `read_registry`. - For write (push) access, `write_registry`. ``` ## Problem Pushing an image to the registry will technically only use `write_registry` for operations such as `PUT`, `POST` or `PATCH`. However, the `docker` client will perform a series of requests and some include some `HEAD` operations that would presumably try to verify a manfiest/blob existence in the registry, before trying to push the content to avoid unnecessary operations. You can se an example of a push operation using the `docker` client below:  A recent MR was raised to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88948+ to update the scope needed for pushing. While the `push` action alone does not require a `read_registry` scope, certain clients may request both permissions. This can also be seen in the [API request flow for a push](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/auth-request-flow.md#push). ## Proposed solution Seems like the `write_registry` scope is only accepted if the actions entitle pushing only. However, any read action will fail with an error such as `Denied container registry permissions` and some clients may request both scopes when trying to authenticate. An assumption is that `write_registry` scope should automatically give `read_registry` scope to a token (PAT or deploy token), but this is currently not the case. To do: - Allow a token with the `write_registry` scope to also perform `read_registry` operations.