Instance-wide, mandatory project mirroring rules
Problem to solve
As a devops engineer managing an on-premise, enterprise GitLab environment, I would like the ability to limit what repositories GitLab users are allowed to mirror to and from. Some specific use cases:
- Prevent either push or pull (or both) from individual hosts, host globs, individual IPs, or CIDR blocks. For example, prohibit push mirroring to any host that's not in the 10.0.0.0/8 network block. Or only allow pull mirroring from gitlab.com, bitbucket.com, etc. (don't allow arbitrary repositories). Or prevent mirroring from a raw IP address (only allow hostnames).
- Require HTTPS or SSH mirroring (no unencrypted HTTP mirroring)
Additionally (perhaps as a follow-on feature, not in the MVP), I would like development teams to be able to add to (but not subtract) from these mirroring rules on a per-group basis. For example, if a financial system wants to prohibit any mirroring from Internet repositories in their projects, they should be able to configure this in the parent group for those projects.
Intended users
- Cameron (Compliance Manager)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Alex (Security Operations Engineer)
- Priyanka (Platform Engineer)
User experience goal
High-level goals:
- The GitLab administrator should be able to configure global mirroring rules in the Admin panel or config file. These rules should be mandatory (or administrator should have option to make them mandatory).
- Individual teams should be able to configure additional project-specific mirroring rules in a similar fashion to the GitLab administrator, but at the group level.
From a user's perspective, the high-level fail case looks as follows:
- The user configures the details of a push or pull mirror in the project settings.
- GitLab cross-references the git URL supplied in the configuration with the global mirroring rules.
- If there's a violation, GitLab flashes an error message and fails to save the mirror.
From the GitLab administrator's perspective, the violation should be logged.
The success case looks the same as the current behavior.
Proposal
A couple of possibilities:
- Add a UI into the Setting portion of the Admin console where the administrator can add rules similar to the Merge Request Approvers UI.
- Allow mirroring rules to be configured within the GitLab configuration file.
For example, in the first scenario, one possibility:
- Administrator navigates to Admin console > Settings > Repository > Mirror Rules (new section)
- User clicks "Add rule" and a modal appears.
- In the modal, there are four components:
- Allow or Reject (user chooses one)
- Push or Pull (user can select one or both)
- Protocol (user can select one or more of HTTP, HTTPS, SSH)
- Destination (user can enter a CIDR block, hostname, host glob, or leave it empty)
- Once modal is filled out, user clicks Submit and the rule is added.
In the interface, the user can re-order the rules. The first matching rule wins when GitLab is evaluating a new mirror configuration. If no rule matches, GitLab fails closed (mirror is not allowed). (Fail close vs fail open is debatable, I think either way is fine as long as it's documented).
So to configure some of the examples previously discussed in this issue, the rules might be:
- Reject | Pull or Push | HTTP | 0.0.0.0/0 (no HTTP mirroring allowed)
- Allow | Pull | HTTPS | gitlab.com (allow mirroring from approved hosts)
- Allow | Push | HTTPS, SSH | 10.0.0.0/8 (allow push mirroring only within corporate network)
- Reject | Pull or Push | HTTP, HTTPS, SSH | 0.0.0.0/0 (if the mirror rules are fail closed, this rule isn't needed)
Further details
The primary use cases for this feature are:
- Security and compliance. Developers should only be able to mirror code to/from approved sources. Developers should not be able to mirror over insecure protocols.
- Data Loss Prevention (DLP). It's pretty trivial to find high-profile examples of horror stories where people accidentally push credentials, sensitive mission/business data, etc. to public repositories.
Permissions and Security
As an MVP, this feature will require Admin-level permissions in GitLab to configure global mirroring rules.
For group-level rules, any user which can configure group settings will have privileges to configure mirroring rules.
The rules will affect any user which has permissions to create or modify project mirrors.
Documentation
TBD
Availability & Testing
TBD
What does success look like, and how can we measure that?
TBD
What is the type of buyer?
TBD
Is this a cross-stage feature?
TBD
Links / references
TBD