Security policy scope applies an AND logical operator if projects and groups are both allowed
Summary
Attempting to apply a security policy to a project by adding the project id under projects in policy_scope fails if groups is also specified in that policy and the group that project is in is not listed.
The policy_scope docs say that the keyword is to "enforce the policy on only those groups, projects, compliance frameworks, or a combination, that you specify."
"or a combination" of groups and projects seems to imply an OR logical relationship -- that when checking to apply a policy, the project id should either by in the projects list OR a project within a groups id listed. However, the implementation seems to require an AND relationship.
Steps to reproduce
Example Project
https://gitlab.com/gitlab-org/ruby/gems/gitlab-exporter/
using policy inherited from:
https://gitlab.com/gitlab-org/gitlab-org-security-policy-project
What is the current bug behavior?
gitlab-exporter has project id 1507906, and is under the group gitlab-org/ruby/gems.
With the policy set as (clipping out only a relevant part):
policy_scope:
projects:
including:
# other projects...
- id: 1507906 # gitlab-org/ruby/gems/gitlab-exporter
groups:
including:
# other groups... but not gitlab-org/ruby/gems ...The policy is NOT applied to the gitlab-exporter project.
What is the expected correct behavior?
The policy SHOULD be applied to the project, as it specifically listed under including.
Or, if this is the desired functionality, the docs should be updated to specify how to use this, including adding more complex examples.
If this is the desired functionality, a new feature request might be created instead to add the ability to create an OR relationship between groups and projects instead of AND.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)(we will only investigate if the tests are passing)
Possible fixes
In this line, we can see the groups and projects are ANDed (&&) together, requiring that a particular project be both listed under projects AND within a group specified under groups. This implementation doesn't seem to match the language used in the docs and the yaml file. I would expect instead that a project be checked if it is in the project list first, OR, if it is in a group in the group list if not.
Patch release information for backports
If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.
Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.
High-severity bug remediation
To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.