Allow fork pipelines to run in parent project
Problem to solve
Currently, for merge requests coming from a forked project, no pipeline is created in the parent project. This is mostly around security concerns for those pipelines. It would expose the parent projects runner, CI variables and other items to the forked project - which is likely not desired by many.
However, there are many valid use cases where this should be allowed to happen. For instance, take an enterprise that uses a forking instead of a branching git workflow. We should provide a way to run a pipeline in this way, with the appropriate security considerations accounted for.
- Enterprise that uses forking workflow with GitLab (GitLab.com and on-premise)
- Open source users (Including GitLab contributors)
In the future we will also solve this issue for non-local repos
- Forked projects cannot create pipelines in the parent project by default.
- In parent project, there is a project-level config (Settings > CI/CD > General pipelines) called "Allow MRs/PRs from forked projects to create pipelines in parent". which is off by default. If this option is enabled, pipelines for merge requests/pull requests are created in parent project instead of forked projects.
- With the option enabled, forked projects can 1. Create/Read/Update pipelines 2. Read container registry, by default.
- With the option enabled, forked projects cannot access 1. Project/group-level secret variables 2. Clusters 3. Project/group-level specific runners, 4. Environments/Deployments, 5. Service Integrations, 6. Release by default.
- This rule is applied in both Public/Private fork workflow.
In a future release we will handle: the parent project can allow forked projects to access these resources by enabling additional checkboxes. NOTE:
- In PR workflow, we'd need service account in order to identify users/permissions. => More discussion in #5667
- In private-fork workflow, the parent project's runners do not need to have an ability to read repository from private-fork, because merge request refs (
refs/merge) are available in the parent project already.
By taking advantage of the "Run Pipeline for MR" button at https://gitlab.com/gitlab-org/gitlab-ce/issues/65940, we can introduce a way for members of the main (non-forked) project to run a pipeline for a fork. The way this would work is:
- The button would only be available to members of the non-forked project. This could be inconvenient in some cases, but is the only way to ensure a project member is able to review the MR and ensure there are no malicious contents.
- Upon clicking the button, a pipeline would run in the context of the MR containing the forked pipeline ref. The pipeline runs as the user who clicked on the button, with their permissions and access. This ensures the pipeline has the access it needs.
For users of the feature, there are two main ways of working to choose from here:
- Authors of the fork can be made a member of the source project, allowing them to run pipelines themselves.
- For arbitrary/untrusted forks, the author should reach out to a project member to run the pipeline.
Project membership is required, in order to use parent resources.
- Add "Allow forked projects to create pipelines" section to CI/CD > General pipelines screenshot
- Default checkbox to unselected
Permissions and Security
Because project membership is required, there is no back-door to gaining unauthorized access through this approach.
What does success look like, and how can we measure that?
What is the type of buyer?
This would be driven by organizational development practices, most likely set by a Director of Engineering or above.
Links / references
- See &957 for additional UX items around
only: merge requests
- Circle CI's use of forked projects
- Travis' use of forked projects
Interested Customers (internal only)
- Create a new project-level config "Allow fork pipelines to run in parent".
- Check pipeline triggerer's permission when the system collects variables.
- Check pipeline triggerer's permission when the system creates deployments/evnrionemtns.
- Allow fork MR pipelines to be created in the parent project.
- Disallow Project/Group-level runners to pick jobs if the pipeline triggerer doesn't have access to it.
- Remove a feature flag and update documentation (e.g. Important notes about merge requests from forked projects
- Create a new project-level config "Allow fork pipelines to run in parent"
This feature is behind the feature flag
allow_fork_pipelines_to_run_in_parent (with project scope).