Protected containers: Push protection for admin users

• Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA

What does this MR do and why?

• Consider admin mode and admin user when pushing a protected container image to the container registry.
• Currently, the admin user is not able to push a container image when the container repository is protected by a container protection rule; this is (or can be considered) a bug because the GitLab documentation states that "GitLab administrators have all privileges"

🛠 with ❤ at Siemens

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

MR Checklist (@gerardo-navarro)

• Changelog entry added, if necessary
• Documentation created/updated via this MR
• Documentation reviewed by technical writer or follow-up review issue created
• Tests added for this feature/bug
• Tested in all supported browsers
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the javascript style guides
• Conforms to the database guides

Screenshots or screen recordings

Before this MR

When pushing a container image (that is protected by a container protection rule) with an admin user then it will be blocked, see console output below. This is not expected because admin users are supposed to have all privileges, see https://docs.gitlab.com/ee/user/permissions.html .

➜  docker_container_hello_world git:(main) ✗ docker push registry.test:5000/flightjs/flight/13
Using default tag: latest
The push refers to repository [registry.test:5000/flightjs/flight/13]
12660636fe55: Preparing 
denied: Pushing to protected repository path forbidden

After this MR

When pushing a container image (that is protected by a container protection rule) with an admin user then it will be possible to do so because the container protection rules are ignored for admin users, see console output below.

➜  docker_container_hello_world git:(main) ✗ docker push registry.test:5000/flightjs/flight/13
Using default tag: latest
The push refers to repository [registry.test:5000/flightjs/flight/13]
12660636fe55: Mounted from flightjs/flight/14 
latest: digest: sha256:a8ea96bb64d60208d6a56712042d1cf58aa4a7d3751b897b9320b0813c81cbb4 size: 524

How to set up and validate locally

1. Enable the container registry, see https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/registry.md (<= setup as HTTP and not HTTPS)
2. In rails console, enable the feature flag :container_registry_protected_containers

Feature.enable(:container_registry_protected_containers)

3. Open a new browser, sign in with the admin user "root" and go to http://gdk.test:3000/flightjs/Flight/-/settings/packages_and_registries
4. Ensure that the admin user "root" is an owner of the project "flightjs/Flight"
5. Create a container protection rule in the frontend: http://gdk.test:3000/flightjs/Flight/-/settings/packages_and_registries

• repository_path_pattern: "flightjs/flight"
• minimum_access_level_for_push: "Admin"
• minimum_access_level_for_delete: "Admin"

5. In a new terminal session, login to the container registry with a token (with the scope :admin_mode), see https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/registry.md#using-the-docker-client

# The token "ypCa3Dzb23o5nvsixwPA" is the seeded token for the user `root` in th gdk instance
docker login registry.test:5000 -u root -p "ypCa3Dzb23o5nvsixwPA"
docker pull hello-world:latest
docker tag hello-world:latest registry.test:5000/flightjs/flight:v1.0

6. Push the container image => This will be successful 💚 because admin users (like root) have all priviledges even though a matching container protection rule exists.

docker push registry.test:5000/flightjs/flight:v1.0

7. Now checkout the branch master and push the container image again => This will fail ❌ because the container protection rule prevent this

Related to #427546