Subgroup scan execution policy UI can't parse top-level Runner tags

Summary

A customer recently reported odd behaviour in their workflows, where within a subgroup with a scan execution policy, they cannot see a top-level group runner's tags in the configuration. Attempting to manually define the Runner tag results in a YAML parsing error. This appears to cause a follow-on effect where a project in the subgroup can't run a scan execution policy that breaks the parsing error.

Steps to reproduce

Preparation

Create a top-level group (parent), either on SaaS or Self-Managed, with an Ultimate subscription applied.
Create a subgroup (parent/subgroup)
Create a project (parent/subgroup/project)
Create a top-level Group Runner on parent. Configure the Runner with a tag, such as sep-example-tag.
In the subgroup, go to Security > Policies. Select New Policy > Scan execution policy.

Rule Mode

Attempt to configure a policy with the configuration settings:

Run a SAST scan
Runner tags.

Attempt to set this to has specific tag. The UI behaviour will lock-out this option and present a UI error when hovering over it:

No tags available Scan will automatically choose a runner to run on because there are no tags exist on runners. You can create a new tag in settings.

YAML mode

Switching to YAML mode, attempt to configure the policy using the example below:

type: scan_execution_policy
name: name
description: ''
enabled: true
rules:
  - type: schedule
    cadence: '*/10 * * * *'
    branches:
      - "*"
actions:
  - scan: sast
    tags:
    - sep-example-tag

Switching back to Rule mode will:

Return the message: "Non-existing tags have been detected in the policy yaml. As a result, rule mode has been disabled. To enable rule mode, remove those non-existing tags from the policy yaml."
Remove the tags: configuration from your YAML.

You can re-paste the configuration and choose to Configure with a merge request, which will save accept the configuration and take you to the group's security policy project. Merge the MR.

The prepared YAML in .gitlab/security-policies/policy.yml becomes:

scan_execution_policy:
- name: name
  description: ''
  enabled: true
  rules:
  - type: schedule
    cadence: "*/10 * * * *"
    branches:
    - "*"
  actions:
  - scan: sast
    tags:
    - sep-example-tag

Project-level testing

With the security policy now 'enforced' via manually adding and saving the YAML, navigate to your Project. In Secure > Policies, you should see the inherited Scan execution policy from the subgroup. The UI will indicate it accepted the Runner tag:

Note that the project has access to the top-level group runner, so should be able to run the jobs:

Example Project

A public example has been made available at:

Please let me know if you'd like permissions to view/edit/manage the security settings.

What is the current bug behavior?

This is two-fold, in that:

UI performance prevents setting the group-runner tag without manually invoking it in the YAML; but
This also seems to prevent the logic from applying scan execution policies on a project

From the project's perspective, the policy should run fine, either on a cadence or on branch activity, but this is not occurring.

What is the expected correct behavior?

Users can configure the YAML as expected, and scan execution policy works as expected.

Relevant logs and/or screenshots

Screenshots	Description
	Top-level Runner is shown to the subgroup with inherited toggle used
	Error message when trying to use the Runner tag in the UI in "Rule mode"
	The Runner successfully runs a "Hello World" job on the tagged Runner

Output of checks

This bug happens on GitLab.com

Possible fixes

The customer isn't sure when it first occurred, but sounds like it has been within the past two releases. Does this line-up with recent changes to how we scope or filter Runners?

Does it make sense given the behaviour that this will also prevent a policy from running on a project?

Possible Fixes

frontend update membership for Group.runner request to be ALL_AVAILABLE
- verify all usages of runner_tags_dropdown.vue want membership: ALL_AVAILABLE or create a prop to determine if membershp should be ALL_AVAILABLE or DESCENDANTS

Potential Patch

diff --git a/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/graphql/get_group_runner_tags.query.graphql b/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/graphql/get_group_runner_tags.query.graphql
index 2cff5bce372c..83c59d3f6ac0 100644
--- a/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/graphql/get_group_runner_tags.query.graphql
+++ b/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/graphql/get_group_runner_tags.query.graphql
@@ -1,7 +1,7 @@
-query getGroupRunnerTags($fullPath: ID!) {
+query getGroupRunnerTags($fullPath: ID!, $membership: String!) {
   group(fullPath: $fullPath) {
     id
-    runners {
+    runners(membership: $membership) {
       nodes {
         id
         tagList
diff --git a/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/runner_tags_dropdown.vue b/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/runner_tags_dropdown.vue
index 84c686fb5b02..6075baeb6938 100644
--- a/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/runner_tags_dropdown.vue
+++ b/ee/app/assets/javascripts/vue_shared/components/runner_tags_dropdown/runner_tags_dropdown.vue
@@ -43,6 +43,7 @@ export default {
       variables() {
         return {
           fullPath: this.namespacePath,
+          membership: 'ALL_AVAILABLE',
         };
       },
     },

Edited Jan 03, 2024 by Alexander Turinske