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

changed milestone to %12.6

added backend devopsmanage groupauthentication and authorization [DEPRECATED] saml labels

added workflowready for development label

This looks good!

marked this issue as related to #12377 (closed)

As a first iteration we could just say group managed accounts can't create personal projects. That would remove both the database work and UI work.

@chill104, what do you think about this? Are personal projects important for your users?

@jeremy well I started off saying that people should just branch from the upstream repo but have been shouted at that people still like to fork, traditionally.

Now this creates a position where it seems that better solution is to make the personal projects the property of the managed group instead of disallow them.

Queue @bleggett defending forks...

Letting people in a group managed account fork only to a space managed by that group is the behavior I'd want and expect.

For our specific use case we do want people inside the company with the Reporter role to be able to fork repos to corp groups or their corporate managed accounts, we just don't want them to be able to fork them outside of that scope.

Forks are an effective and proven way to allow non-project owners to work on and contribute back to a repo, without violating the principle of least privilege the way granting the entire company branching permissions on every repo does.

"If you're a corp managed account, you can fork to a corp managed group, or your own corp managed account" is the most obvious/secure/least surprising behavior that fits the original problem statement.

@jeremy I'm not quite sure what exactly we've decided to do here.

If you're a corp managed account, you can fork to a corp managed group, or your own corp managed account

How it's different from what we have now? If group has GMA enabled only GMA have access to the group => all group accounts are managed by a corp.

The ask here is to restrict personal projects. Accounts should be restricted to projects within the corporate group and if users do create projects those projects are within that group and are shared with the group.

@jeremy it's a bit unclear did we agreed on James suggestion for initial iteration or not? If we want to have a separate switch to disable personal projects that's more work on UI and DB compared to "disable personal projects for all group managed accounts" logic. Could you update issue description to what we agreed on? I'm working on this ticket and coming close to a point when this decision comes into play.

@pshutsin: I'm fine with that as a first iteration. If there's a proven need, we can introduce configuration but I think it makes sense to start without it.

I updated the description. I also mentioned that we should consider including a new error message.

I also mentioned that we should consider including a new error message.

This new error message adds more complexity because we'll have to differentiate between GMA case and regular "you've reached projects limit" case. Currently, when user has reached the limit we just hide "new project" buttons where possible so if we want to display custom error when the limit is caused by GMA we'll have to display buttons too and discuss proper UI here.

Since entire feature change here is temporary I'd recommend to keep this issue as simple as possible and focus on "right way" in #12420 (closed)

Since entire feature change here is temporary I'd recommend to keep this issue as simple as possible and focus on "right way" in #12420 (closed)

@pshutsin: What makes this the "right way"? Those seem to be solving different problems. Happy to discuss on a call if that would help.

added [deprecated] Accepting merge requests label

mentioned in issue #12377 (closed)

added to epic &1785

added estimationneeded label

added groupoptimize label and removed groupauthentication and authorization [DEPRECATED] label

assigned to @pshutsin

removed [deprecated] Accepting merge requests label

How it's different from what we have now? If group has GMA enabled only GMA have access to the group => all group accounts are managed by a corp.

@pshutsin: Thanks for the question. The problem we're trying to solve is that users are free to fork a group's projects into their personal namespace.

I'm free to create a personal fork of GitLab in Jeremy Watson > GitLab that GitLab, Inc. cannot control. I can add whoever I like to this personal project in my namespace and the group can't audit what I am doing with my personal fork. GitLab certainly doesn't care, but enterprises consider this a security concern that they'd like to close.

My understanding is that if we set projects_limit for a user to 0, it will return an error when I try to fork into my personal namespace.

I think this leads me to the question: could I then create a private group and fork there? We might have similar concerns there and might need to close that path off as well

@jeremy I have concerns that disabling personal forks will fit @bleggett needs.

For our specific use case we do want people inside the company with the Reporter role to be able to fork repos to corp groups or their corporate managed accounts, we just don't want them to be able to fork them outside of that scope.

If we disable personal forks GMA won't be able to fork anywhere except another subgroup in the same root group. I find it quite inconvenient since it will push people to create private subgroups inside a root group to be able to fork a repo there.

At the moment company can control GMA itself (enable\disable it), but can't control it's activity much. As I understood forking to private personal namespace is desired behavior, adding people outside of associated group isn't.

So I think instead of disabling personal forks for GMA we should think about limiting fork visibility and memberships control for GMA. E.g. something like:

GMA can fork to personal namespace as private project only.
GMA can invite users from the associated group only to their personal namespace projects.
GMA can create private projects only inside their personal namespace. (optional)

If we disable personal forks GMA won't be able to fork anywhere except another subgroup in the same root group.

And I think that would feel weird. Developers are accustomed to personal forks.

limiting fork visibility and memberships control

@jeremy, Pavel's 3-step plan makes sense to me. Unfortunately it's more complicated than the original proposal, but I think would result in the better (more natural/predictable) behavior. What do you think? Also, we may need a 4th step to handle existing personal namespace projects that are NOT private. Should we convert those to be private, or leave them alone?

Being able to convert "customer-controlled" group (I think we need a term for a group that have GMA enabled) opens a pandora box of questions like "what should we do with X when customer switches GMA off".

It would be simpler if we can start with "one way" conversion behavior from regular to GMA-group.

@jeremy, do you feel like we have enough information to make a judgment call here? If not, I'm happy to go gather some feedback if we can formulate A/B options.

I find it quite inconvenient since it will push people to create private subgroups inside a root group to be able to fork a repo there.

Aside from it being weird (I don't disagree that it's not a workflow I'd be used to/love), but is there any reason it wouldn't work? I'm fine with considering an iteration that focuses on #12420 (closed), but I definitely know of at least three large enterprises (2 on self-managed, 1 on GitLab.com) that simply want to disable personal projects entirely for their users.

At the moment, the self-managed users run a nightly cronjob to clean these up but would much rather disable this behavior entirely; on GitLab.com, we have no options since the group Owner can't assert any control over personal projects.

I'm still of the opinion that this is worth doing.

GMA can fork to personal namespace as private project only.

Unless I'm mistaken - this SHOULD be existing behavior. A group enforcing GMA is almost certainly private, which means all projects inside it also must be private. I tested an attempt to fork a private project and make it public, and I wasn't able to. I don't think that the visibility of a fork can be more relaxed than the upstream project.

I just tried this and the visibility setting of the fork is locked to Private.

Being able to convert "customer-controlled" group (I think we need a term for a group that have GMA enabled) opens a pandora box of questions like "what should we do with X when customer switches GMA off". It would be simpler if we can start with "one way" conversion behavior from regular to GMA-group.

I definitely agree with this (cc @lmcandrew @jamedjo). I don't anticipate that anyone's going to turn it off, but I don't think that's an option we should work to support. I think we should make this one-way to make iterating here simpler.

@djensen @pshutsin: Would you mind creating a simple issue here?

Would you mind creating a simple issue here?

Done: #39066 (closed)

I'm fine with considering an iteration that focuses on #12420 (closed), but I definitely know of at least three large enterprises (2 on self-managed, 1 on GitLab.com) that simply want to disable personal projects entirely for their users.

Ok I'll focus on simple temporary solution to disable personal projects in scope of this ticket and consider #12420 (closed) to be the ticket when we should do it "right way".

Ok I'll focus on simple temporary solution to disable personal projects in scope of this ticket and consider #12420 (closed) to be the ticket when we should do it "right way".

Thanks @pshutsin, but please let me know if I'm missing something here in the proposal. It's desired by our customers, but please let me know if I'm not understanding the workflow here correctly and this won't be a good experience for our users.

added direction label

added workflowsolution validation label and removed workflowready for development label

What the customer wants is to have their employees not be able to do anything but work for the company in their instance and not be able to take anything outside of it. This is critical in many top Financial Services companies with many of them doing work arounds for it. They should not have to and is a feature in GitHub.

changed the description

assigned to @jeremy

added gitlab.com label

@jeremy what is the status on this being on track for %12.6 ?

It looks like we had some open questions in the thread above. I'll have to defer to @pshutsin to see if this is still doable in %12.6, since I just responded to the comment thread above.

I'm aware that this is a significant one for the GitLab.com customer mentioned in this document.

To be clear - what we are looking at is

Users should be able to have personal projects and forks [but only from projects internal to the group]
User login should be governed by SSO

Will this feature satisfy these requirements?

Users should be able to have personal projects and forks, but only from projects internal to the group

@akshat.sharma: This issue would disable personal projects, so users would be required to create forks inside the group.

One problem we're trying to solve here is allowing an organization to maintain control over their projects. If a user forks into their personal namespace, the organization no longer has visibility over what that user is doing with the fork.

The current proposal would simply disable personal projects, which would require forks to stay within the group. Since the fork is inside the group, a group Owner can audit activity and stay informed.

What do you think? Is that an acceptable approach?

@jeremy We don't want to disable personal projects. We are migrating from Bitbucket and our users are used to having a personal namespace where they work on projects which don't necessarily fall under a defined organization group and also, - for inner sourcing - being able to fork in one's own space to contribute back is a regular practice across the organization.

I understand the audit part and we need it but we also don't want to restrict the users, specially when this was a feature working just fine in the Bitbucket world.

Now, a workaround I can think of is to have a top level 'users' subgroup where we assign each user their own subgroup - handled at initial user onboarding - but it isn't clean. Can something like this be in-built? As in you create a separate user space within the parent organization group and update their personal namespace path to that so their personal namespace exist within the organization parent group.

Thoughts?

@jeremy the idea suggested by @akshat.sharma would be better than simply disabling personal projects. could we require that SAML SSO users have their namespace under the group associated with the SAML SSO?

@choy.rim @akshat.sharma: I agree that this is a better solution. Based on my understanding of the proposal, it'd also be more expensive and would take us longer to ship.

Now, a workaround I can think of is to have a top level 'users' subgroup where we assign each user their own subgroup - handled at initial user onboarding - but it isn't clean. Can something like this be in-built? As in you create a separate user space within the parent organization group and update their personal namespace path to that so their personal namespace exist within the organization parent group.

Again, this would be really nice. Redirecting the personal namespace into a subgroup in a managed group would take some design work and some thinking through. Here are my thoughts:

Let's pursue this issue, which would now restrict forks from being created outside the group. This is configurable.
In a future iteration, that configuration would allow forking into a personal namespace, but that personal namespace would automatically be created inside the group.

If we try to do this all at once, it will probably be 3-4 releases before we can ship an improvement.

The best solution for this will be Workspaces, which we plan on adding around the first half of next year. If we're able to create an instance-within-an-instance, users would join that workspace and simply have their personal namespace within that scoped area of the application.

What do you think?

@jeremy

To be clear - for this iteration you will a) restrict external forks b) disable personal projects ?

Meanwhile we will create and maintain parent/users/user.name subgroup for every user.

To be clear - for this iteration you will a) restrict external forks b) disable personal projects ?

The current proposal currently only focuses on A, which is restricting of forks. When this option is enabled, a user will not be able to fork a project into their personal namespace; they'll be required to keep the fork in the group maintained by the organization.

ok, can you help us with release dates for both a and b; for us to plan for near future. @jeremy

There are currently no immediate plans for B.

For A, likely timing would be in early January on GitLab.com. Please monitor this issue and related merge requests for more specific timing (e.g. !22002 (merged)).

As mentioned in the issue description, this is optional behavior and shouldn't impact the behavior of existing groups.

@jeremy In a future iteration, that configuration would allow forking into a personal namespace, but that personal namespace would automatically be created inside the group.

This is what at least one corporate customer (us) actually wants, so please let us know when it is scheduled.

cc @chill104

This is what at least one corporate customer (us) actually wants, so please let us know when it is scheduled.

@bleggett: Does this issue not solve for the most pressing need? Users would still be able to fork, they'd just be compelled to fork within your group.

The behavior you quoted would be a good change, but it can be accomplished after this change by manually creating a specific sub-group for forks inside the top-level group.

@jeremy Fork to where within the group?

We're looking to kickstart an innersource program that lowers the barriers to entry for devs from teams in one group forking and contributing to team's internal projects in another group.

There might be good reasons why an individual dev might just wanna quickly fork something one afternoon and try hacking on it, and might be disinclined to fork it into their own team's subgroup and clutter things up/confuse the team.

The other option might be a companywide "personal fork space" as you mention, but that's rather cumbersome, not great UX (how do we tell everyone they need to fork there, and make sure that they do? Do they need to create subgroups with their username in there first to avoid collisions? Does that mean we need to give the entire company write permissions to a subgroup that can have forks from anywhere in the company in it?), and an extra chore to maintain.

For us, Option A solves one problem and creates several others, which is why Option B is the endgame.

Fork to where within the group?

@bleggett: Anywhere they have project creation permissions is fair game; just not anywhere outside of the group.

There might be good reasons why an individual dev might just wanna quickly fork something one afternoon and try hacking on it, and might be disinclined to fork it into their own team's subgroup and clutter things up/confuse the team.

Sure, I definitely understand. If there's a specific subgroup for these forked projects, I think the clutter is at least controllable - and since it's happening within the confines of a group, you're able to audit activity and assert ownership over these forks.

For us, Option A solves one problem and creates several others, which is why Option B is the endgame.

Option B (I think you're referencing "Option B" here) creates a tradeoff as well, though. It doesn't seem like it elegantly solves the forking problem (preventing personal project creation would also result in not being able to fork to a personal namespace), and it doesn't really provide a great solution for the audit/security concern either.

A user could just create their own private group and fork there, which would then be out of the organization's sphere of control.

I'm not intending to force a solution through that doesn't solve a problem. What I'm hearing is that none of the proposed solutions are acceptable steps forward for one reason or another, and maybe we should concentrate our efforts on a first iteration of Workspaces to solve this the right way.

If you can scope projects to a space and register users specific to that space, then you can create personal projects and have audit control over that space without managing these tradeoffs. It does mean that we wouldn't be able to solve this problem for a quarter or two, but is definitely the better solution.

@jeremy When I say option B, I'm asking for the UX around this: configuration would allow forking into a personal namespace, but that personal namespace would automatically be created inside the group.

And I'm asking for a way to make that work that doesn't require giving every employee in the company explicit permission to create groups directly under the corp group. That "personal group" would be autocreated for them under the corp group, their perms would be scoped to that personal group, and they would not have companywide group creation perms.

Sure, I definitely understand. If there's a specific subgroup for these forked projects, I think the clutter is at least controllable - and since it's happening within the confines of a group, you're able to audit activity and assert ownership over these forks.

What permissions should all our employees have in order to be able to fork to this group and create their own subgroups to fork under? Developer? Maintainer? With the current version of Gitlab, how can this be achieved without granting everyone that can fork to this group write perms outside of their personal space as well as inside of it? (it can't, AFAICT, which is my issue).

With the current permissions model, creating a megagroup that everyone has write access to for personal forks isn't workable from a permissions point of view.

What I literally want is the exact forking behavior and personal group behavior that Gitlab has now, except that if the user is a corp user, that personal group is autocreated by Gitlab beneath the toplevel corp group, instead of directly under gitlab.com.

That solves every problem I can see.

Thanks, @bleggett; that's helpful.

What permissions should all our employees have in order to be able to fork to this group and create their own subgroups to fork under? Developer? Maintainer? With the current version of Gitlab, how can this be achieved without granting everyone that can fork to this group write perms outside of their personal space as well as inside of it? (it can't, AFAICT, which is my issue).

Since the ability to create subgroups can be configured down to Maintainer:

Top-Level Group CyberDyne
- Subgroup Innersourcing
  - User-created subgroup MyGroup

A developer may be added to CyberDyne as a Guest, but could have the Maintainer role for Innersourcing. That member would then be able to fork projects, create subgroups, and use the Innersourcing subgroup as their namespace.

If the concern here shifts to maintainability, I can definitely understand; Innersourcing could get pretty messy with dozens of developers. But from a permissions model, I'm not sure that I see a major barrier yet.

What I literally want is the exact forking behavior and personal group behavior that Gitlab has now, except that if the user is a corp user, that personal group is autocreated by Gitlab beneath the toplevel corp group, instead of directly under gitlab.com.

Sure. If you think the above doesn't make this useful for the first iteration, we can think about making this a part of the scope; it definitely extends the timeline on this, since we'll also need to do some UX thinking around what that new experience might look like.

@jeremy We are giving everyone in the company's dev org read-only Reporter access by default under the top-level group.

This means the actual toplevel instance itself is the "innersourcing area", which means we'd have to create a secondary group named /corp/forkspace that would be more or less a dumping ground for forks.

Top-Level Group CyberDyne -> People dropped in here under corp SSO get Reporter access by default, which allows viewing and forking to personal namespace, but no write perms. All team projects and subgroups are under here, except for the ones that have cause to opt-out.
Subgroup RandomForkspace -> Everyone in here has to have Maintainer access, which means they have write access to all forks made by anyone across the entire org, which is not what we want.
- User-created subgroup MyUsernameScopedForkGroup - We have to coach people to create this manually.

We're going opt-out on innersourcing versus opt-in, so the maintainability and access issues are a fundamental problem with this approach.

Sure. If you think the above doesn't make this useful for the first iteration, we can think about making this a part of the scope; it definitely extends the timeline on this, since we'll also need to do some UX thinking around what that new experience might look like.

For us, it doesn't. That would be fantastic. I don't think the UX would change much from the current approach, but the backend logic around where to autocreate the user's personal space (based on the type of user) might.

I'll read up on the Spaces MR.

Everyone in here has to have Maintainer access, which means they have write access to all forks made by anyone across the entire org, which is not what we want.

Cool, that's very helpful. The maintenance of this setup sounds like it'd be too painful to be feasible (e.g. MyUsernameScopedForkGroup).

What I literally want is the exact forking behavior and personal group behavior that Gitlab has now, except that if the user is a corp user, that personal group is autocreated by Gitlab beneath the toplevel corp group, instead of directly under gitlab.com.

@pshutsin: What do you think about this direction?

@jeremy automatic creation of MyUsernameScopedForkGroup is less of the problem. There might be questions like "how to display these personal subgroups for others?". I think UX input will help.

However if we want to avoid to coach people how to use it ("You are not allowed to use your personal namespace, you should fork into your personal subgroup") we'll have to make MyUsernameScopedForkGroup act like a personal namespace and it opens pandora box of questions.

I'm also wondering if and how we would clean up these sorts of personal subgroups after we introduce Workspaces. Would we flag them now so we could identify them later? And then maybe convert them into Workspaces?

We are wrestling so much with this spec that I'm starting to align with the idea that "maybe we should concentrate our efforts on a first iteration of Workspaces to solve this the right way" (from #34648 (comment 262643176)).

@djensen we should minimize the requirements. This is what we MUST-HAVE: group owners must be able to prohibit projects inside the group from being forked to namespaces outside the group. (same as the proposal at the beginning)

If the easiest way to implement this is to disable personal namespaces for SAML SSO group members, then please do that. If it's easier to prohibit forking a project that originates from inside a SAML SSO group to outside the group when "external forking" disabled, then do that instead.

The gitlab API allows us to create namespaces for each group member. So we have a workaround for the lack of personal namespaces inside the group. So the creation of personal namespaces under the group can wait for workspaces. But the API (in the cloud) doesn't allow group owners any visibility into personal namespaces. So we have no way to auditing or prohibiting the forking of code from inside the group to outside.

workspaces sound like the ultimate solution but based on the spec, that implementation looks to be at least 6 months away. I assume the other options above are faster to implement.

@jeremy I think what's @choy.rim suggests is doable and looks like nice compromise. We can prohibit forking outside of root group, disable personal projects and leave the burden to create personal subgroups to clients who still want to use forking with GMA.

@choy.rim The gitlab API allows us to create namespaces for each group member. - What API is that?

Is this something that can be automated thru SAML SSO? Or is this just saying "well, you can use the Groups API to manually create personal spaces for each corporate user post-provisioning, one by one, for several thousand users"?

If it's the latter, you're essentially going to be initiating a breaking change that messes up our internal workflow until it's "properly" solved with workspaces. I understand if that's the call, but I do not agree with introducing a breaking change to every customer as a 6-month stopgap as we wait for a proper fix.

@bleggett,

... you're essentially going to be initiating a breaking change ...

no, the option to "prohibit forking to namespaces outside the root group" would be off by default. The option off would be the same as present behavior. So it is not a breaking change for existing users.

... is this just saying "well, you can use the Groups API to manually create personal spaces for each corporate user ...

Yes and no. Yes, you can use the gitlab API to create personal spaces for each user. No, you would use a script instead of doing it manually.

no, the option to "prohibit forking to namespaces outside the root group" would be off by default. The option off would be the same as present behavior. So it is not a breaking change for existing users.

Gotcha. Then I'm fine with this as a stopgap until workspaces happen. Thanks for reminding me that that was still part of the feature.

Yes and no. Yes, you can use the gitlab API to create personal spaces for each user. No, you would use a script instead of doing it manually.

Sorry, that's what I meant. Iterate thru all users and explicitly create a space for each one.

mentioned in issue #39066 (closed)

added frontend label

changed the description

mentioned in merge request !21546 (closed)

removed frontend label

added workflowin review label and removed workflowsolution validation label

changed the description

changed milestone to %12.7

added workflowin dev label and removed workflowin review label

changed title from Allow group owners to disable personal projects for group managed accounts to Allow group owners to disable projects forking outside of GMA-group

mentioned in merge request !22002 (merged)

added frontend label

@jeremy looking at direction where requirements go I'm concerned that we are trying to add too much of a behavior for a toggle at SAML configuration page. I feel like we are getting closer and closer to bigger concept of Workspace and binding that behavior somewhere deep in specific group settings page doesn't look like a good UX.

mentioned in issue #1112 (closed)

@jeremy are we still on track to deliver this important customer feature in 12.7?

@spouliquen1 unfortunately no

The details of the spec were a bit troublesome - we only reached consensus a few days ago. That hasn't left us much time for execution, so I expect this will slip to %12.8. On the bright side, we have a clear path forward and a small head start (MR !22002 (merged)). I'll coordinate to make sure we hit the ground running in %12.8.

/cc @jeremy @pshutsin @dennis

changed the description

marked this issue as related to #12420 (closed)

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

Problem

Proposal

Designs

Child items ...

Activity

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

Problem

Proposal

Relates to

Activity