Feature specific permissions for the Package Registry
Context
When you are configuring your project, you can control feature-specific permissions for things like project issues or the repository. For example, in the below screenshot, you can see that the project is set to Public
and everyone with access can access the project's repository and issues.
Alternatively, I could have set the project to Private, which would restrict access to the project's repository and issues to project members only.
Problem to solve
The problem is that although you can control several features like this, for the GitLab Package Registry, you can only turn the feature on and off. You cannot set visibility to project members only or everyone with access.
For example, a large organization with many users and many projects may want to create a central registry with approved, vetted container images for distribution throughout the whole org. But that would require adding everyone to the project instead of just setting the group and underlying projects to Internal
as they do with code projects.
This type of workflow is common in large organizations and consulting companies that would like finer grain control over how they share their project's registries.
Proposal
Add feature-specific controls for the GitLab Package and Registry, so that Admin have more flexibility and control in how they can share their project's resources.
By default, each control will be set to project members only
.
Further details
- This issue has a related package registry bug: #332028 (closed). Due to the permissions of the repository and package registry being tied together, deploy tokens won't work in projects that were public and moved to private.
- This does not impact the container registry. See the below explanation:
The logic that "removes" all the "container" permissions are not tied to the
repository
feature: https://gitlab.com/gitlab-org/gitlab/-/blob/0e5fa4c28a55bd46d82000decb00fefa4d3c2864/app/policies/project_policy.rb#L500-502.We have an inconsistency then:
- for the
package
feature, we can see above that it's within (1.) and the logic that "removes" all the "package" permissions is tied to therepository
feature.- for the
container registry
feature, it's also within (1.) but the logic that "removes" all the "container" permissions is not tied to therepository
feature.
Metrics
We will start with the stricter project members only
setting, but we should measure how often this is changed and to what setting. This will help us to evaluate if we need to update the default setting.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.