How GitLab protects your IP

How safe is your IP?

One of the main assets of any company is stored in the shape of code. The originality of the code makes it intellectual property, and thus companies would like it to be protected. But storing it safely away from others will hinder the same effort that brought it to life: Collaboration. So how can companies keep their IP safe while allowing their employees to work on its maintenance and development? GitLab repos, whether hosted online or privately, store one of the most valuable things your company is able to create: The digital assets used to build software products and services. GitLab is designed to make versioning and the collaboration over those assets as seamless and productive as possible. Albeit that, is GitLab a safe place to store such valuable assets? Let's explore user access within GitLab and to what extent these users can access your company's IP.

Ways to access GitLab

LDAP, active directory, SAML, SSO

For the self-managed solution, GitLab is able to connect to any Lightweight Direct Access Portal (LDAP) service that is already set up and validate which users have access permissions. Users that access GitLab instances with LDAP on will have access only to the groups and projects assigned to them. The same is applicable to active directory. If you are using GitLab.com, Security Assertion Markup Language (SAML) technology will mostly do the same described above. System for Cross-domain Identity Management (SCIM), the open standards running beneath SAML, is currently supported for Okta and and Azure but it will have broader support in the future. For example, check single sign-on (SSO) for enterprises or the general direction of this category.

How users are organized in GitLab

Assigning roles with permissions is an easy way to know which user will be able to access and make changes to the IP. There are six roles: | Guest | Auditor | Developer | Reporter | Maintainer | Owner | |:--|:--|:--|:--|:--|:--| | | | | | | | By default all users have the following permissions in a project:

• Create issues
• Leave comments
• Clone or download the project code But these are the specific definitions for each user role:

1. Guests are not active contributors in private projects. They can only view, and leave comments on issues.
2. Auditors are given read-only access to all projects, groups, and other resources on the GitLab instance.
3. Reporters are read-only contributors: They can't write to the repository, but can write on issues.
4. Developers are direct contributors, and have access to everything to go from idea to production, unless something has been explicitly restricted (e.g., through branch protection).
5. Maintainers are super-developers: They can push to main (master) and deploy to production. This role is often held by maintainers and engineering managers. So what's happening at the project level? Well, the meat of it: Collecting requirements, defining user stories, prune and groom backlog, and merge requests are popping up like branches. It is at the project level where these four roles interact. But they don't do it only with the permissions their role provides them. There are other features at this level that can stop them or enable them to do certain things that will allow the project owners to parcel and control who's doing what to the IP hosted in the repo. Let's look at these features.

Where is my IP stored?

Intellectual property is stored in repos, projects, and groups. Let's first step back and explain what the structure of these elements in GitLab looks like. Once we have a clear understanding of what and where information is stored, we can then jump to explaining who can access what information.

Repos

A repo is a folder that lives either on your machine or on GitLab.com. It is what Git tracks every time you add and commit a change. It hosts your code and all the branches.

Projects

Repos are the core part of every project. This is where GitLab's core version control and collaboration capabilities shine. GitLab has project management features such as epics, subepics and issues, Wikis, GitLab pages, a Web IDE and many more features that make the repo the central part of a fully-featured source code workflow.

Groups

Groups are a collection of projects. Members of groups with permissions will keep those permissions on every project included in the Group. 5. Admin-only features can only be found in /admin. Outside of that, admins are the same as the highest possible permission (owner). 6. Owners are essentially group-admins. They can give access to groups and have destructive capabilities. Watch the video below for a deep dive into repos, projects, and groups.