Skip to content

GitLab Next

    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Menu
    Projects Groups Snippets
  • Get a free trial
  • Sign up
  • Login
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,111
    • Issues 43,111
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,369
    • Merge requests 1,369
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #34648
Closed
Open
Created Oct 22, 2019 by Jeremy Watson (ex-GitLab)@jeremy-glContributor

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
Time tracking