GitLab makes use of an internal NGINX as a proxy to the services inside the tile. To ensure that client IPs are presented accurately to the service components, GitLab provides a method to add to the list of trusted proxies for the NGINX instance. GitLab prepopulate the list of trusted proxies with the addresses of the Pivotal Cloud Foundry (PCF) Gorouter addresses as a part of the tile, and provides a field to add additional trusted proxies that may be present as a part of the Infrastructure as a Service (IaaS) in use.
Throughout this document, GitLab mentions reverse proxies which is how Load Balancers route traffic to individual service instances. It is possible that your environment may have additional proxies that are not load balancers. Throughout this documentation, you can interchange “reverse proxy” with “load balancer.”
If this information is not provided, NGINX presents the addresses of the reverse proxies as that of the client.
This can result in the RackAttack
component of the GitLab instance behaving in a way that is in agreement with its design,
but not as you intended or expected.
If the addresses provided to RackAttack are that of the reverse proxies instead of the client,
behaviors such as request throttling and failed authentication could occur based on the proxies and not the end client.
This can result in spurious
Access Forbidden (
HTTP 403) responses from the server.
When configured so that all layers of proxies are included and trusted in these settings,
these erroneous behaviors do not occur.
This field accepts a comma-separated list of IP addresses and CIDR notation. The values in this field should be complete 4-octet addresses, with or without CIDR notation.
|192.168.10.18, 10.0.16.15, 10.0.16.23|
|192.168.10.1/24, 10.0.16.15, 18.104.22.168/22|
Depending on the IaaS in use, there may be one or more additional reverse proxies between your clients external to PCF and your GitLab instances. The location of these reverse proxies varies greatly between individual deployments. When collecting this information, tile administrators need to collect the necessary information from their infrastructure.
As a part of the PCF installation and configuration documentation for GCP, you will have created a Load Balancer.
The IP addresses of these load balancer instances should be added to this list.
There is a known subnet that these load balancers will be placed into (
however you might want to be more specific.
An excerpt from Google Cloud documentation below describes the complete subnet in which all GCP load balancers are placed:
You must create a firewall rule that allows traffic from 22.214.171.124/22 and 126.96.36.199/16 to reach your instances. This rule allows traffic from both the load balancer and the health checker.
To collect the IP address of the front-end load balancer from the GCP console, do the following:
Log in to the GCP console.
Select the appropriate project used to install PCF from the project drop-down.
From the Products & Services menu on the left of the page, under the Networking section, select Network services > Load balancing.
Find the load balancer in the list and click to expand the information panel underneath its row.
In that panel, the public IP address of the load balancer is listed under the “Frontend” section.
As a part of the PCF installation and configuration documentation for AWS, you created a Web Load Balancer. Any subnet that a load balancer has been created inside should be added to the list of Trusted Proxy Addresses
As a part of the PCF installation and configuration documentation for vSphere, you have configured either the Pivotal HAProxy Load Balancer or another. The IP addresses used here should be added to the list of Trusted Proxy Addresses.
Log in to the Azure portal (portal.azure.com).
Select the resource group PCF was installed in.
In the overview section, filter all items by type, clear everything, and select Load Balancers.
Click on the load balancer in the results list and the public IP address is listed in the overview section.