Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 34,895
    • Issues 34,895
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 1,230
    • Merge Requests 1,230
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #34648

Closed
Open
Opened Oct 22, 2019 by Jeremy Watson@jeremy🤠Maintainer

Allow group owners to disable projects forking outside of GMA-group

A modification to this feature was made apart from GMA and released in 13.3

Problem

Top-level groups using SAML SSO can enforce the use of group managed accounts (GMA) to require users to create unique users that are tied to that specific group. These user accounts are used when SSOing into the group, and are tied to the email address received from the configured identity provider.

Group managed accounts were intended as a solution for enterprises on GitLab.com looking for more control over user activity. One gap for these enterprises is the use of personal projects; a personal project could be forked or cloned in a personal namespace, outside of the control of a group's owner, and accidentally expose valuable code.

Some organizations prefer to have the group be the only place that a user's able to interact with projects associated with the enterprise. By keeping them in the group, they're able to assert control over them and audit activity.

Proposal

For organizations using group managed accounts, a group Owner should be able to toggle whether or not group managed accounts are able to create forks outside of the group.

  • When enabled, creating a fork should only be allowed if the fork is created inside the group associated with the group managed account.
  • When disabled, a group managed account should be able to fork anywhere.

This option should be enabled by default when enabling group managed accounts (changing behavior of existing groups is not desired).

Note that this restriction would only apply to attempts to create new forks and won't affect any existing forks that are already in personal namespaces, which we should make clear in the documentation.

Edited Dec 09, 2020 by Tim Poffenbarger
Assignee
Assign to
12.9
Milestone
12.9 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab#34648