Introduce dedicated permission for Google Cloud Artifact Registry

🐦 Context

In &12365 (closed), we have been implementing the support for the Google Cloud Artifact Registry.

In the first iterations, we didn't really look at user permissions. Given that we are implementing things mainly to list docker images, we simply re-used the read_container_image. This permission is granted to:

1. reporter+ users.
2. anymous+ users for public projects.

(1.) is exactly what we want to access the objects of the Google Cloud Artifact Registry: only reporter+ users. However, (2.) is not what we want (Artifact Registry objects are private by default = we don't want to "open" a public access to these because the GitLab project is public).

So, we need:

• introduce a new permission.
• grant it to only reporter+ users.
• update all the code/logic of the Google Cloud Artifact Registry support to use that new permission.

That is this MR. The related issue is GAR Integration: Add permission to read artifac... (#436652 - closed).

⚙ What does this MR do and why?

• Introduce read_google_cloud_artifact_registry. Granted only to reporter+ users (no matter the visibility).
  • In addition, the Google Cloud support is gated behind a saas only feature and this permission will also use that gate.
• Introduce admin_google_cloud_artifact_registry. Granted only to maintainer+ users. This is similar to the admin_container_image permission that we currently use on master.
• Update the Artifact Registry support code to use that new permission.
• Update all related specs.

The Artifact Registry support is behind a saas only feature and several feature flag. Hence, no changelog for this MR.

🚲 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.

✅

🌈 Screenshots or screen recordings

No UI changes

⚙ How to set up and validate locally

1️⃣ Setup

1. Create a new project.
2. Follow the instructions in !142289 (merged)
3. Enable the related feature flags:

   Feature.enable(:gcp_artifact_registry)

4. Simulate a SaaS instance in the local GDK.
5. Have a guest user and a reporter+ user.

2️⃣ With reporter+ user

On the left side bar, the Google Artifact Registry is enabled:

Now, let's trigger a some GraphQL request from /-/graphql-explorer:

query {
  project(fullPath: "<project full path>") {
    id
    googleCloudArtifactRegistryRepository {
      artifacts {
        nodes {
          ... on GoogleCloudArtifactRegistryDockerImage {
            name
          }
        }
      }
    }
  }
}

It works ✅

2️⃣ With guest user

On the left side bar, we don't see any Google Artifact Registry:

Let's check the GraphQL request from previous section.

It returns

{
  "data": {
    "project": {
      "id": "gid://gitlab/Project/<project id>",
      "googleCloudArtifactRegistryRepository": null
    }
  }
}

✅

3️⃣ With anonymous user

Make sure that the project is public.

On the side bar, the Google Artifact Registry menu entry is not available:

Notice that the Package Registry is available. It follows identical rules as read_container_image (eg. permission granted to anonymous users on public projects).

Let's check the GraphQL request.

It returns

{
  "data": {
    "project": {
      "id": "gid://gitlab/Project/<project id>",
      "googleCloudArtifactRegistryRepository": null
    }
  }
}

✅

🔮 Conclusions

This change is behaving as we wanted. 🎉