Ability to create roles and assign permissions according with the role
There usually are more roles other than guest, reporters, developers, etc in a developer team. An example of permissions: who works with what branch, who can commit, etc.
Also a screen to manage this.
Concerns: Security and complexity.
Update
There are no short-term plans to implement this functionality in GitLab. We are still interested in investigating it further, but certainly for the next 6-9 months, we won't be shipping a completely customised solution for roles.
We are dealing with some requests on a case-by-case basis, such as the ability to customise the capability of the developer role to allow that role to create projects: https://gitlab.com/gitlab-org/gitlab-ee/issues/2534
I'm going to use this issue to consolidate some similar questions/concerns our users/customers have. We've taken a pretty firm stance on changing the permission system and I think that's fine. As we're starting to get more feedback on this I think it's important to at least have that be visible to the team.
Create a proper RBAC system - gitlab-org/gitlab-ce#13173
Configurable permissions. As an example, in confluence wiki, I have the ability to add groups or users to a permission list and enable or disable a set of pre-defined permissions. The default groups/permissions don’t work for our use case. I need finer control to meet our business needs. For example, I would like to enable a group of user to view wiki pages and submit tickets but not have access to view or edit the code.
Regarding configurable security permissions, I can understand not wanting to increase the complexity of the system. However, from a cooperate security perspective, this can be a show stopper if the current system does not allow the flexibility to control content access according the corporation’s requirements. I think we may be able to make the current system work; I’m still evaluating. But it is not an ideal case for us. One other point, the complexity is in the system, not necessarily in the user experience. Under a configurable permission system, an admin could configure it to be less complex than the default configuration.
I was wondering if there’s such feature where we can have user groups or at least have more detailed global permissions for a user. For example, we had to work around the fact that the deploy keys in gitlab have read only access (unlike github where it has read/write access [they achieve this by creating a “bot” account; which afaik Gitlab doesn’t have such thing]) so we created an admin account for Jenkins so it can also automatically create tags onto any project in our Gitlab. However, this is a security concern because theoretically one could create a Jenkins job that deletes all projects for example.. Etc.
Is there a way to give users certain global permissions (like creating tags only onto any project)?
Or perhaps is there another way to achieve this without creating an admin user for Jenkins?
End goal here is to have the ability to create tags into any project.
@JobV I actually have an issue that can't be solved with more flexible deploy keys.
In my EE org, I need to allow Developers to create new projects (repos) in a group without giving them all the things that "Master" will give them on the projects in that group.
Also sometimes I need to give a use the ability to do X, but not A,B,C,E. To better map roles in the company with permissions in Gitlab would be worth gold to us.
In our case deploy keys would not solve the problem, e.g. I would like to let developers be able to create milestones and rewrite/remove git tags. Currently I am forced to give our users the master role which comes with way too many other options that my developers should not care about.
We are also in need of configurable permissions and user role. Currently, we are limited to roles and permissions in https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md, but it's not enough because a role either gives too much or not enough. We'd like an admin to pick and choose permissions from a general pool for each role. There can be a default set, but an admin must be able to fine tune them as needed. For example, our business people (currently reporters) tend to reopen all closed issues instead of creating a new issue (less key strikes for them I guess). I'd like to have a certain role not being able to reopen issues or being able to lock particular issues similar to GitHub from certain roles being able to enter comments or reopen them.
It's quite easy to add/remove permissions from the existing role. For example you could modify the list under def project_guest_rules to grant more permissions to guest users in your projects.
Of course you'd have to apply your changes with every new release of Gitlab. So it's really just a dirty workaround.
@mikehaertl Thanks so much man for pointing this out! We'll be hacking this file out for sure until the custom permissions/roles make their way into GitLab. Thank you.
Our business has a similar requirement to @plux.stahre.
We want to make use of protected branches however we want developers to be able to create new projects within existing groups.
In order to create projects they must be masters which means protecting branches in other projects in that group is useless.
Perhaps a first step towards a fully customisable permissions system (fully custom roles) would be adding the ability to add/remove individual permissions from the existing roles (except Owner).
unfortunately, in my enterprise, this issue just killed our evaluation of GitLab. We were hoping to use GitLab EE because it is 1/5th the cost of GitHub Enterprise. But this poor permissions system killed the evaluation about 2 hours into it. There is just no way I can get this past our enterprise security and our government auditing team. I need to strip about 1/3 of the permissions out of the existing groups, delete the guest group all together, and create about 2 or 3 new groups to be compliant with our government contracts.
Oh well, back to evaluating the insanely expensive GitHub, and most likely have to go with PerForce at 10x the price. Its sad, i really like this product.
we are currently using GitLab CE 7.3 for our internal projects on medium team.
We created a group where team members have "reporter" as standard permission.
Unfortunately, to create a project within a group, you need to be master of that group.
We would like to have the ability for a reporter within a group to create repos inside that group, because setting everybody master is too dangerous, and asking to an administrator to create a project for him/her is not efficient.
@mcamurri Under the current roles and permissions we will not implement this. We've had requests to do so before but it doesn't make sense currently. The reason is the creator of a project is the 'Owner' of the project. This gives them full privileges within the project. However, as a reporter in the group, it's possible that they do not have such privileges on other projects within the group. This would allow the user to manage membership, project settings, push code to master, etc. If we change the behavior now, it would most certainly come as a surprise to many users. Some would want it, some would not.
Maybe this will be possible if we implement some custom roles. For now, requiring the elevated privilege, or requiring the user to request a new project from the group master/owners seems like the most logical way to handle the situation.
A user in GitLab, can always create a project under his personal namespace, upon which he/she have total ownership.
Not even another owner can transfer that project to a group, for instance.
What I'm asking is to to the same within a group: reporter in the group creates a project, obtaining automatically the role of master for that project alone, and keeps being reporter for all other projects. This procedure can now be done indirectly by another master with some effort.
BTW, I respect you decision, and I'm looking forward to have the custom roles.
Meanwhile, I will grant master access within the group to my colleagues.
oh where to being. Ill just start with a few of the easy ones. I met with Enterprise Security this afternoon about this and his initial reaction was "You're joking right?"
The user that creates the repo can not be the owner. I need to be able to disable any way possible that a flesh and blood person can create a new repo in one of the internal groups. (we have no public groups). The reason is, we have strict application inventory rules that must be adhered too. So you can not create a source repo without the associated bug tracking group in our bug tracker (disabling the built in issues system is already one of the first things on the install list if i can get this approved), requirements account in our requirements management system, development billing code in our accounting system, the records in the inventory control system, etc. We have a full blown automation system that handles all of this. But, the user that creates the repo in the automation system, thru the API, will not be the owner. The owner will be another group, that group will be the members of our build and deploy support team. Now I suppose I could write the script to create the repo, set everything up, then remove itself as the owner, but that seems like a lot of unnecessary work with great big holes for something to go wrong.
I need to remove some of the permissions that owners and masters have. I have to comply with SOC2 security compliance. That compliance states that 100% of code that makes it to servers must be code reviewed. Well, pull requests makes that easy. The problem is my auditors are giving me grief about the fact that the requirement can be disabled by masters and owners by being able to switch off the protected branches system. I need for either a global admin setting saying "This is the way of things" or a setting in the API where my automation system can say enable the protected branch settings at the time of creating the repo and once set, any power to be that you happen to pray to themselves can't change it.
Next, I need to be able to create an auditor role. This role needs to be able to do spot checks on a handful of our thousand or so repos every month. This user must be able to log into the admin console to view that the security and privacy settings are correct, but they can't be allowed to change anything. We have done this in the past by creating read only database groups and putting the auditor in that group, problem is you use a single user DB connection, which eliminates that as a possibility.
Rewrite and remove tags, i need to disable that completely across the board. Tags will become critical to our version handling and deployment systems and the git tags will drive about 3 or 4 other systems. I can't have people with the ability to just randomly change tags in the repo because it will wreck other traceability systems on down the line.
Allow our build system to tag the main branch. I need to figure out a way that our build system (we use UrbanCode) can tag the repo, basically in a way that bypasses all the stuff that i said was required already. UC tagging a repo is the only thing that is allowed to happen to the master branch without code reviewer intervention.
And thats after a 20 minute conversation with my security architect. There will be more to follow, i assure you. I'm trying very hard to use this because I believe its a great tool and far superior to github E and Bitbucket, and im trying to save my company from having to spend several hundred thousand a year on Collabnet or even more on Perforce, but this tinker toy of a security system isn't making it easy on me. I really hate to have to tell my boss that he has to spend 10X more on an SCM just to create a few roles and change some permissions, but im most likely going to have to.
@scphantm If you're evaluating EE for your organization, please reach out to us and we're happy to discuss your requirements to see if we can do some development to meet those needs. While I understand your frustration, please keep the conversation here productive.
That actually brings up a question.. Is it possible to "sponsor" improvements such as this? ie, @scphantm has mentioned that he's looking to use Gitlab in lieu of other software that may cost upwards of several hundred thousand dollars. If he, or someone else, were able to redirect those funds to Gitlab, could a feature such as this be sponsored?
If we change the behavior now, it would most certainly come as a surprise to many users. Some would want it, some would not.
Has gitlab inc, done any surveys to find out how many would not want this ability? The rest of the industry's stable of products work in such a way to allow a developer to create a project in a group namespace, and that gives them master on only that project.
One of the most prevalent patterns in development today, is a modular design approach for application development... especially when using tools like docker, which you now support. A single project/deliverable artifact could actually have many repositories.
When looking at this from a group perspective, that means the projects grow inside a group organically day-to-day. If your organization uses an inner-sourcing approach, they're hit with this hard control, and the owners/masters of an org become inundated with mundane tasks of creating repositories instead of doing real work.
This is anecdotal only, but I have seen hundreds of issues and forum posts asking for the ability for developers to create group projects, and very rarely do I see responses to those from users/admins who don't want to allow that. In nearly every case where I have seen that kind of response, the permissions don't fit their needs regardless because they need to be more strict (similar to the reasons @scphantm mentioned).
I realize that this change could impact users... but you've made other high-impact changes in the past (bundling software) that had big impacts on users.
As far as I've been able to tell... this is the most repeatedly duplicated issue/feature request, and it's one of the only things where you don't match up competitively with other market options.
Your users are clamoring for it, and it allows you to close a hole in your competitive advantage, and it removes barriers to the workflow gitlab org has been promoting in recent months.
Gitlab has been arguing with it's community about this topic for several years now. Isn't it time to prioritize this one instead of keeping it on the backlog?
The really frustrating thing about this as well, is I have written enough permissions systems in my career to know, that you can implement this in such a way that the typical user would never know you did it. The default permissions if you don't change things will work identical to the way you have now. But for people like me that have a 380 page book of local, state, and federal regulations i have to follow in order to write a freaking web page. I have 6 state contracts in the file cabinet beside me, along with 2 standards organizations documents on my desk that all dictate various levels of security we must maintain on all our systems. I have to lock it down to a level where my internal and external auditors can go from an angry scowl to an unhappy frown. Which is their version of happy.
With the way its built right now, you could redo the security system here with a fairly straight forward permission/group system without much problem. its not like you need to implement a full tree based security model complete with role inheritance.
And pay for work, doesn't work for us. My company has an archaic policy of any code they pay for, they own. So if we payed you $300k to rip the security system out and replace it with one that fits our needs, from my legal departments point of view, we would then own GitLab, or at least own a percentage of it. I know its ridiculous, my CTO put fixing that on my todo list for 2018. That should take me a year.
@scphantm Please adjust your tone. I think most people in an open community will not do what you want only because you yell at them.
have a 380 page book of local, state, and federal regulations
This is not GitLab's fault.
I have written enough permissions systems in my career to know
straight forward permission/group system without much problem
If it is without much problem and you know how to do it, why don't you post a merge request?
And pay for work, doesn't work for us.
Though that works for GitLab CE, I doubt it is making things very attractive for the company GitLab.
Just to make things clear: I am not representing GitLab, this is my personal opinion. I am only part of the open community and I don't like that negativity here.
Thanks, @winniehell. I agree, please keep the conversation productive.
@scphantm You're correct, we could keep the current/default behavior if we introduce some form of custom roles, and we probably would do just that, so it's the least disruptive. What we have to figure out is:
What do we want to do?
How do we want to do it?
When do we want to do it?
This would be a big change for GitLab and we want to do it right.
@JobV@regisF Can you please consider the custom roles. We are getting more and more interest/requests so we should look toward the future and see what we want to do.
I have a few thoughts on the How do we want to do that might even help answer the What:
Step 1 might be something along the lines of identifying the code and files that contribute to the existing permissions/roles, so that any contributors have an easily identifiable way to get up to speed with the low level codebase, and hopefully create a comfort level around refactoring such an integral component of your codebase.
Step 2... I would propose creating a draft of plain-english test cases that would need to pass, allow the community to contribute to that list of cases, and then together ratify those as requirements for any accepted MR.
Thanks to everyone trying to keep this conversation productive. I think @dblessing's questions are key here to understanding the scope of the effort.
I would like to point out a recent overhaul made by @jneen in the implementation of our permission/roles here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5796. It's a significant improvement that will enable us to provide a better permission system going forward. I encourage everyone to read the MR description at least to get a better idea of where we are today.
However, even with this MR, there is still a significant amount of work to make it possible for more customization of roles. For example, a lot of the permission checking is handled in the Ability class for performance reasons. There's also a lot of UI work to make this friendlier as well. I'm sure there are other assumptions in other parts of the code as well that need to be tweaked.
If it is without much problem and you know how to do it, why don't you post a merge request?
By the way, posting a MR here doesn't guarantee you it'll be merged, until the problem is "accepted" by core team members.
It's either going to be closed, or just ignored.
Just take a look at the MR page, at all of that opened and not yet merged MRs.
However, even with this MR, there is still a significant amount of work to make it possible for more customization of roles. For example, a lot of the permission checking is handled in the Ability class for performance reasons. There's also a lot of UI work to make this friendlier as well. I'm sure there are other assumptions in other parts of the code as well that need to be tweaked.
It would be nice to see a a step-by-step plan to get this problem solved (meta-ticket?) Like Iteration 1, Iteration 2 and so on.
So it would clarify for everyone what's the status of solving this problem.
What do you think about it?
We need to create users with read only permissions other than default types of users such as Master, Reporter, Guest etc.,. Users should only have view permissions to all branches and folders.
I recently found the need to allow user to have read/write access to a project wiki without having write access to project repository. I was able to use @mikehaertl method and edit the reporter role in ability.rb, but this seems like a fragile method as it will be overwritten every time I do an upgrade. There are a few other changes I may end up making, but even just having an equivalent to editing ability.rb that persists over upgrades would be a huge improvement (even if it's in a config file and not in the GUI).
Refactoring the complete permission system is a huge task. So how about the following interim solution which should be much easier to implement and is backwards compatible:
Create a new section "Roles" in the Admin / Overview page
On that page you'll find a list of roles, with predefined fixed roles "Guest", "Reporter", "Delevoper", "Master" on top of that list. You also have a button "Add New Role"
When you add a new role, you get a form with a Dropdown "Extend from role:", with the above predefined roles plus "None" as selectable options
Below that there is a list checkboxes with role permissions, labelled like "Add the following additional permissions to the new role". The list then lists the same permissions that we find in app/models/ability.rb ("Read Project", "Read Board", ...).
This way you don't have to refactor the permissions completely. You'd simply reuse the existing permissions but give a bit more freedom by letting the admin define custom roles. It should only require 1 extra table in the database to store the roles. The main columns in that table would be extends_from as a ENUM of the existing access_levelconstants and permissions as SET of abilities as we find them in ability.rb. The legacy roles would be added as undeletable entries to that table. In ability.rb you'd then simply load the respective permissions from that table.
@Boekhoff Note, that I'm not a developer, just a regular user of Gitlab. If you like my suggestion, maybe add a vote to my comment to convince the maintainers that this is worth implementing.
I'm sure the designer here would do something along those lines. But that isn't the problem. The problem is testing it. With a fixed permission system, testing is dead simple. With a variable permission system, the number of required tests for adequate coverage could and usually does go up exponentially.
@scphantm : It would be exponentially if you had to test all combinations of permissions. Otherwise its linear dependent on the number of permissions (assuming that the permissions are independent).
Just a peak of what i need for permissions, (without testing it), i think this change to the project policy would be what i need to accomplish on the base users. I can test these permissions when infrastructure gives me a permanent instance. then i need to create custom users that are able to do specific tasks and only those tasks. So far, my auditors have identified about 15 or 16 different roles we would need. But debugging and implementing the policy in this snip will get me auditor approval to install the product on a temporary basis until the ability to edit the roles and create custom roles is added.
Current thinking in terms of timeline is in about a year, Q3-Q4 2017.
Why? Custom roles are super complex. Broadly speaking:
they affect almost each piece of interface in GitLab;
require a very complex interface to configure;
have to be well tested in terms of performance
affect almost every single line of code in GitLab
encourage bad behavior (creating a custom role instead of using nice features such as protected branches), which in turn requires us to be better at product marketing and documentation
make our code permanently more complex
require many additional features to work well (think copying permissions, sharing or limiting them across scopes)
have to be easy to manage, hard to misuse
Might we do it earlier if the opportunity / requirements match? Sure! This is just a hunch. It would be a good feature for GitLab 10.
I do think we should keep looking how we'd go about doing this until then and just do it when we think the moment is right.
yup. Welcome to my daily life. ;-) As long as you stick to a straight opt in - opt out model, its not horribly bad. If you attempt to do an inheritance model, mental hospitals are full of developers that have tried to pull off inheritance model security systems.
In my java world, this is not that bad. we can create aspects and annotate the methods with aspects requiring a different permission to be true before you can execute the method. in that way, its more about error handling than making sure you code only executes with the permission. not sure if ruby has anything like that tho.
encourage bad behavior (creating a custom role instead of using nice features such as protected branches)
Being able to make effective use of protected branches is exactly why we want custom roles. The Developer role is too limited but we obviously don't want to give everyone Master.
A similar situation exists with 'Guest' access where the minimum set of rights is more than desired (e.g. grant a user read-only access to the registry but no access to issues).
There's another gap around the project management features. I'd love to be able to give someone milestone/wiki/issue-tracker access, but prevent them from editing files in the repository.
Thanks for all the feedback @d33tah@mdyer@jvstein. I think before we implement custom roles, we'll definitely look into improving and extending the current permission system. This is on top of mind for me and something the product team will be working on in the coming months.
We need this at my company as well. We outsource QA and would like the QA team to be able to modify issues but not view source. We would also be happy with a 'QA' role between Guest and Reporter. Seems like everybody needs something slightly different though so a configuration screen is likely the best answer. Good Luck :)
What I need for this (my other ticket was pointed here #26597 (closed)) is:
In my projects there are some non-developer people associated to the project, but I want them to be able to interact with issues as well as developers. This means I need a role between guest and reporter that extended to guest also can:
Assign issues
Move issues between lanes
Close issues
Maybe see when a commit was made but not see the actual commit (this is not important, but would be nice)
This is something I'd definitely like to see. I'd like to be able to set up individual "teams" (as I'll call them) that have defined roles. An artist should not necessarily have the ability to push to the code repository, a community manager might need to have edit capabilities on issues and the wiki, but not the ability to push code. At any rate, some teams might require different feature rights on different repositories. To be honest, I've seen this as a pretty standard practice in software applications (a la phpbb).
As far as the UI, here's what I would expect personally. On the group dashboard, there would be a list of teams, which would be pretty standard as far as having a list of teams, and the option of creating a new one. For each team, there would be these tabs:
General permissions/properties
"Members" for adding/removing specific members to/from the team (each member could be a member of multiple teams)
"Repositories" where you would add/remove repositories which the team has rights for, for each of which you could edit the specific capabilities the team has on the repository. If a group member is a member of multiple teams, they would get all the permissions given to them by the complete set of teams.
If you really want to be thorough, I'd include both teams and roles, where there would be multiple roles on a team (again, I'm thinking of phpbb). This would just mean there is another level to drill down. So for example, you could be an customer service rep on the team for product A, but a developer for product B.
As far as the creator being given ownership of the repo, I see no reason why this can't be a settings flag, in conjunction with the ability for teams to have permissions that could be set on all repositories, or default repository permissions or whatnot.
In addition: Would it be possible to limit certain boards or tags from certain groups? I sometimes have clients that want to be involved... but I don't want them too involved! Especially when it comes to technical conversations. =D
I just want to pile on here... we want to be able to build enterprise-wide modular build/release infrastructure on top of this, but the inability to restrict release tags to privileged service users makes it pretty fragile. I don't want random dev interns allowed to muck with release tags like v1.2.3. Build reproducibility, release workflows, source auditing and querying etc, will depend entirely on those tags. There needs to be a recognition of an infrastructure user, and maybe some options to restrict tags by regex or something.
We need custom roles too. We want to separate people who can accept merge requests in regular development and other set of people who can approve merge requests to fix bugs. That is, we need to have different set of people who can approve a merge request based on a branch.
Something like the below function in bitbucket.
https://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions/
@sidewinder12s Yes I know. We need it per branch within a project because we have different people responsible for development and bug fix branches - we don't want those responsible for just the development branch to accept merge requests on bug fix branches.
The team responsible for the develop branch and bug fix branch are different. There's several teams on the develop branch but only one for the bug fix branch.
We need it per branch within a project because we have different people responsible for development and bug fix branches
This is exactly what protected branches does. You can specify a branch, or a regex to match on branches, and specify a role, or even specific users that can merge and/or push. For a development branch you can specify certain developers while you can specify another team for the bug fix branches.
I wanted modify existing master role or I wanted to create new role Integrator with few permissions less than master. How can I achieve this ? Is there any way to restrict it using Protected branch feature
We are really needing custom roles/permissions also. The simple fact that you don't have a role that can create a MR but not approve them is extremely limiting.
Loving all the other improvements you are making, but I think it's about time this topic gets implemented.
@djthayer Have you looked at the 'developer' role plus protected branches? You can choose to restrict merge request acceptance to 'master' for certain branches. 'Developer' will still be able to create merge requests, though.
This comment is somewhat related to the above conversation but it would be awesome if certain admin features could be granted on demand to regular users.
Two examples:
If would be nice if HR personal could have an account on GitLab but only be granted the ability to create/edit users
If someone could be granted permissions to the runners tab out of the admin panel, as one person specializes in runners on our team and manages them.
But neither person should have god mode over all of GitLab. This allows for many people to handle and manage different parts of GitLab without also making them have powers over everything in GitLab.