Restrict access to repository by IP address/range

General
1

Hi,

Is it possible to restrict access to Gitlab Cloud (SaaS product) based on IP address/ range (i.e. the network in our office)?

A colleague informs me that it indeed is possible but only for HTTPS and not for SSH. Is this true? I’ve been looking at the documentation and it never mentions anything about being protocol specific.

Thanks,

Mark

1 Like
2

Yes your colleague is right. Only https because you then configure nginx to restrict by url. SSH is a shell protocol not a web server so it cannot block urls.

You best bet is use a firewall and block port 22 (ssh) to only authorised IP addresses maybe the same with 443 https. Far less complicated.

3

Thanks so much for getting back - the firewall option is pretty the conclusion we came to.

I just find this (and the page it links to) a little misleading;

image
image1306×329 94.4 KB

So, really there’s no way to demonstrate for a Security Review/Audit that the most rudimentary steps have been taken with the SaaS product to prevent code leaving the organisation. Something that’s impossible to enforce 100% I admit - but these things are mostly optics.

So, an “on-premise” solution looks like the only way to enforce this.

Thanks once again - much appreciated.

4

I’m using gitlab-ce and it’s in the cloud at a hosting provider. Correct firewall rules utilising iptables, or if you have other such abilities - eg: AWS has the ability to configure firewall access outside of the VPS/instance, other hosting providers also do offer this. DoS/DDoS protection and other additional products to enhance and protect even further.

So there is a very easy way to demonstrate security review/audits by utilising additional products. You cannot blame gitlab for that. A collection of products are able to do that, it’s not the role of Gitlab to be a firewall, intrusion detection device, web application firewall or whatever in addition to what it is doing right now.

Your image above shows what the EE version does when you pay for additional functionality, of course would need to read the “Feature Details” to find out what exactly it’s doing to see if it fits your needs. But even in addition to this, you should be looking at additional external products for security and not relying solely on gitlab’s functionality.

5

Something else to add. This is what I would be doing:

  1. Depending on distribution, iptables, nftables, firewalld and creating appropriate rules allowing port access - being general access via HTTPS or even just for your internal IP’s thus blocking your server as if it was an on-site internal access only server.
  2. Additional layer between the internet and your AWS instance, or VPS, or whatever hosting platform for your server so a firewall in-between for additional protection - maybe with even additional filtering.
  3. Fail2ban can also be used on the server, with appropriate rules in place to block access automatically for IP addresses that attempt to force their way into your server somehow. Be it authentication failures or something else.
  4. GeoIP database utilised with iptables also - something I have also used, to block access from countries that generally attempt to attack servers.
  5. If your hosting provider offers IDS/IDP/IPS or WAF functionality, take advantage of it to secure even further. Need to ensure that it’s going to do what it says, too often I see IDS/IPS or WAF integrated but with way too lax rules which don’t under scrutination actually do anything. Or the other extreme with it blocking too much.

Something to think about.

6

Thanks again for taking the time to reply - it’s really appreciated.

Oh, not blaming Gitlab for anything - just trying to understand the capabilites as my colleague is adamant it’s not possible in any version (Cloud, Self-hosted, CE, or paid for) to totally restrict access by IP address using the Gitlab feature. Also, just looking for some quick wins to mitigate some issues at the minute.

But, as you point out this still wouldn’t be an alternative to a complete security solution - but it could provide part of a proper layered approach.

As we’re AWS based we might have to bite the bullet and install our own version - presume the AWS Martketplace offering takes a lot of the setup pain away?

7

No problem and hope the info helps with your implementation. As for AWS Marketplace, I haven’t used it personally, so can’t really comment on that. I have however done the basics, set up an instance, attach a public IP and set the appropriate firewall rules that AWS allows. That can certainly help for the beginning, and you can then take it from there based on your requirements for security, etc.

8

One should be looking everywhere for security. Redundancy is a key weapon.