Transcript
got a 404? Or had your own Git push rejected on a branch that you're pretty sure that you actually own? Well, if that sounds familiar, you are not alone. Hi, I'm Colleen Lake. I'm a developer advocate at GitLab, and today I'm going to walk you through three permission traps that fight most teams, especially when they move to GitLab from GitHub, Bitbucket, or any of the other DevOps platforms. Then we'll go over how to fix each one in just a few clicks. First let us talk about what I call the inheritance waterfall. This is how group roles in GitLab automatically flow down into every subgroup and project. In GitLab, permissions are strictly additive, and they flow downward. That means if you assign a role at the parent group, that becomes the effective floor for every subgroup and project underneath it until you remove or change that parent access. You could always give someone more access further down, but to give them less, you have to lower or remove their access at the parent where it started. If you were used to, let's say, GitHub orgs and teams, think of it like giving someone access at the org level, and suddenly they see a lot more than one repo. This is a major security trap. If a contractor only needs to see one microservice, adding them at the group level is a mistake. As a rule of thumb, always add users at the lowest possible point in the hierarchy, so you stay close to the principle of least privilege. Next, let's clear up the guest role confusion. On GitLab.com, the guest role is contextual. In a public project, guests can pull code. In a private project, they can't even see the repo by default. If stakeholders need to see private code, they must be at least a reporter, or on ultimate, they need a guest-based custom role that explicitly allows viewing code. That's a pretty big change if you're used to read-only roles on other platforms that automatically show you private repos. One very common and very annoying thing that may happen to you is going to a specific project and knowing that there's supposed to be something there, but not actually seeing it there. And what that usually means is the protected branch settings are not working in your favor there. By default, GitLab protects your branch and limits the merge, merge rights. So that's one thing that you can have an issue with, but it also limits what you can see. So what you have to do then is go to settings, check out your branch rules, and see if any of them are preventing your class of permissions from being able to see or push to that branch. If you're on GitLab Ultimate, you also need to watch out for custom roles. Your admin might have assigned you a junior dev role that looks a lot like a developer, but has very specific extra abilities added, or a guest-based role that has view code turned on for private repos. Custom roles are always built on top of a base role, and they only add permissions. They cannot remove what the base role already has. So if you're thinking, a developer should be able to do this, well, you might actually not be a full developer role. You might be a custom role that's based on a developer role, and not on the actual built-in developer role. If the standard roles are not behaving the way you expect, make sure you check your custom permissions profile. For self-managed users, instance administrators can override everything. So on GitLab.com, the group owner is the final authority for your namespace. There is no customer-side super admin who can bail you out if an owner leaves. So the best practice right there is to always have at least two active owners, or a dedicated service account with owner rights. To manage teams efficiently, use invite group. It's cleaner than inviting people one by one, and it makes audits much easier. When someone leaves a department, removing that one invite group instantly cleans up all of the access that came from that link across the project tree. If a user's access still looks wrong, open the members list and check the source column. In the current UI, that column shows whether their access is direct, inherited from a parent group, or coming from an invited group. That tells you exactly which parent group or invited group is responsible. You cannot downgrade them at this level. You have to go upstream to the source group to fix where the access actually comes from. So to recap, post-access-denied pain on GitLab comes down to three things. First, inherited group access. Second, how guests see private versus public projects. And third, default branch rules that block developers from pushing where they expect to push. Once you understand those three areas, you can usually fix permission problems yourself without opening a ticket. If you hit an edge case or you want a sanity check on your setup, go to forum.gitlab.com and tell us what's going on. People there have seen it all. And I'm there too. In this series, I'm covering the top GitLab snags and pitfalls. So subscribe if you want to see the next one. And if you just migrated from another platform and there's something that is just not intuitive to you, well then let me know in the comments and maybe I'll cover it next. Alright, well that's a wrap on groups and permissions. Happy building!
