GitLab.com group IP restriction does not work for SSH requests
Problem to solve
https://docs.gitlab.com/ee/user/group/index.html#restrict-group-access-by-ip-address says IP restrictions apply to UI, API, and SSH
However, it also says:
To avoid accidental lock-out, admins and group owners are able to access the group regardless of the IP restriction.
Further details
Our testing shows that with IP restriction turned on:
- UI: A user with
Owner
permissions can still access the top-level group along with any subgroup within, but cannot access projects. - API: A user with
Owner
permissions can still access the related API endpoints. - SSH: A user with
Owner
permissions cannot access any projects via SSH to perform Git operations. - Pages: With Access Control enabled, IP addresses can be rejected and Pages can be inaccessible.
The root cause is that the source IP is not passed correctly https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/10954.
Summary: All HTTP
requests abide by the restriction (with the exception of owners not being able to access projects, this is by design), all SSH
requests fail and do not abide by the restriction.
Proposal
Patch GitLab.com implementation of OpenSSH so that user IP address is passed all the way to the application gitlab-com/gl-infra&425 (closed)
Who can address the issue
infrastructure group
Workaround - NOT RECOMMENDED
Adding the CIDR 10.0.0.0/8
(a private network space) to the Group IP restrictions field will allow SSH git
operations to work, with the important caveat that they will be accepted from ANY source IP.
If your security posture requires IP restrictions for all access to GitLab.com, this will not be an acceptable workaround.
10.0.0.0/8 present? |
SSH git operations |
HTTPS git operations |
---|---|---|
true |
SSH git operations will work from any IP address |
HTTPS git operations will work from IP addresses present in the IP restriction field |
false |
SSH git operations will NOT work |
HTTPS git operations will work from IP addresses present in the IP restriction field |
(Workaround was suggested in discussions below: #271673 (comment 436245630))
Other links/references
Original question came from customer (internal): https://gitlab.zendesk.com/agent/tickets/177588
Update
Looks like this may be a bug specific to GitLab.com due to https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/10954. This is tracked via gitlab-com/gl-infra&425 (closed)
01.31.2022 we believe implementing sshd will resolve this issue. That is actively being worked on.
Follow-up
-
Once this issue is fixed, update (and quite possibly revert) this doc change: !50801 (merged)
Customers
- https://gitlab.my.salesforce.com/00161000006g0cJAAQ
- https://gitlab.my.salesforce.com/0016100001F4xr9
- https://gitlab.zendesk.com/agent/tickets/295963
- https://gitlab.zendesk.com/agent/tickets/286612
- https://gitlab.zendesk.com/agent/tickets/274398
- https://gitlab.zendesk.com/agent/tickets/270576 (actually had an issue with pages and IP allowlisting, so may not be relevant)
- https://gitlab.zendesk.com/agent/tickets/269224
- https://gitlab.zendesk.com/agent/tickets/261937
- https://gitlab.zendesk.com/agent/tickets/254049
- https://gitlab.zendesk.com/agent/tickets/232931
- https://gitlab.zendesk.com/agent/tickets/213238
- https://gitlab.zendesk.com/agent/tickets/188845
- https://gitlab.zendesk.com/agent/tickets/187888
- https://gitlab.my.salesforce.com/0064M00000Z9rrR
- https://gitlab.my.salesforce.com/0014M00001sESup
- https://gitlab.my.salesforce.com/00161000004bZPD
- https://gitlab.my.salesforce.com/00161000004yKzL
- https://gitlab.my.salesforce.com/0014M00001jCB7B?srPos=0&srKp=001
- https://gitlab.my.salesforce.com/0064M00000XaVR5
- https://gitlab.my.salesforce.com/0064M00000YMWai?srPos=2&srKp=006