Support TLS Terminators in front of Omnibus GitLab
Oftentimes SSL termination is done not on the webserver (or GitLab server) serving the content, but on a separate reverse-proxy machine. The reason may be security, convenience, or both.
To make things clear, I am talking about a setup like this:
Client <===> reverse proxy <===> GitLab nginx <===> GitLab ruby
(https) (http) (http)
(internet) (lan) (unix socket)
The important part is a double reverse-proxy with https -> http protocol arrangement. Network classes (internet, lan, socket) are only examplary, but illustrate convenience of such a setup.
I have read somewhere that you, or perhaps someone else, use https in the second hop as well. In such a case GitLab 8.0.5-ce works. You would have still need to setup some certificates for Gitlab, and perhaps include them in the first level proxy. Also, depending on which headers it parses, ruby server might not get the client's real IP or it's protocol, if it were actually using http, spdy or whatever, but it will normally work without noticable issues.
It would be nice, if the omnibus gitlab package offered a simple way to set it up behind a TLS terminating reverse proxy. Currently it does not work, because enabling https for gitlab, while disabling https for it's nginx creates an incosistent configuration that usually results in CSRF failures on user login.
Example gitlab.rb:
external_url 'https://gitlab.example.eu'
nginx['listen_https'] = false
nginx['listen_port' ] = 80
Creates nginx gitlab-http.conf with:
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto http;
I believe these headers should not be changed in a second-level reverse proxy (GitLab's nginx), as it has no way of knowing them except via these same headers. Setting such headers is the duty of the first-level reverse proxy. Under normal circumstances GitLab's nginx should set those headers if and only if it is exposed directly.
In particular, I believe improperly setting X-Forwarded-Proto causes some, and may be involved in all of these issues:
- #489 (closed)
- gitlab-org/gitlab-ce#1331
- #331 (closed)
- #696 (closed)
- #669 (closed)
The usual simptom is a CSRF failure during login, or an occasional "The change you wanted was rejected" message.
As a solution I propose the addition of two boolean configure options
nginx['set_x_real_ip']
nginx['set_x_forwarded_proto']
with the default for both being true, no automagic detection and a rather obvious effect. It should also be added to other copies of nginx such as CI, if applicable.
They should be mentioned in the setup guide, but otherwise they are nearly self-documenting, and being default-on their presence in a configuration file should lead a person to at least consider whether they have something (a reverse-proxy) properly setting those headers.
For completeness, there is also a X-Forwarded-For
header,
but it is normally appended to, and it should be fine.