gitlab 啓用HTTPS

NGINX設置 

啓用HTTPS 

警告 

Nginx配置會告訴瀏覽器和客戶端，只需在將來24個月經過安全鏈接與您的GitLab實例進行通訊。經過啓用HTTPS，您須要至少在24個月內爲您的實例提供安全鏈接。

默認狀況下，omnibus-gitlab不使用HTTPS。若是要爲gitlab.example.com啓用HTTPS，請將如下語句添加到/etc/gitlab/gitlab.rb：

# note the 'https' below external_url "https://gitlab.example.com" 

由於咱們的示例中的主機名是「gitlab.example.com」，因此omnibus-gitlab將分別查找名爲「 /etc/gitlab/ssl/gitlab.example.com.key和」的 密鑰和證書文件 /etc/gitlab/ssl/gitlab.example.com.crt。建立/etc/gitlab/ssl目錄並在那裏複製您的密鑰和證書。

sudo mkdir -p /etc/gitlab/ssl
sudo chmod 700 /etc/gitlab/ssl
sudo cp gitlab.example.com.key gitlab.example.com.crt /etc/gitlab/ssl/

如今運行sudo gitlab-ctl reconfigure。當從新配置完成後，您的GitLab實例應該能夠訪問https://gitlab.example.com。

若是您使用防火牆，您可能必須打開端口443以容許入站HTTPS流量。

# UFW example (Debian, Ubuntu)
sudo ufw allow https

# lokkit example (RedHat, CentOS 6)
sudo lokkit -s https

# firewall-cmd (RedHat, Centos 7)
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalld

重定向HTTP請求HTTPS 

默認狀況下，當您以「https」開頭指定一個external_url時，Nginx將再也不偵聽端口80上未加密的HTTP流量。若是要將全部HTTP流量重定向到HTTPS，您可使用該redirect_http_to_https 設置。

external_url "https://gitlab.example.com" nginx['redirect_http_to_https'] = true 

更改默認端口和SSL證書位置 

若是您須要使用除默認端口（443）以外的HTTPS端口，請將其指定爲external_url的一部分。

external_url "https://gitlab.example.com:2443" 

要設置SSL證書的位置建立/etc/gitlab/ssl目錄，將.crt與.key目錄中的文件，並指定如下配置：

# For GitLab nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.example.com.crt" nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.example.com.key" 

運行sudo gitlab-ctl reconfigure使更改生效。

更改默認代理標頭 

默認狀況下，當指定external_urlomn​​ibus-gitlab將會設置幾個在大多數環境中被認爲是完美的NGINX代理頭。

例如，omnibus-gitlab將設置：

"X-Forwarded-Proto" => "https",
  "X-Forwarded-Ssl" => "on"

若是您已經指定了https模式external_url。

不過，若是你遇到這樣的狀況你GitLab是一個更復雜的設置像後面的反向代理，您將須要調整代理頭，以免相似的錯誤The change you wanted was rejected或 Can't verify CSRF token authenticity Completed 422 Unprocessable。

這能夠經過覆蓋默認標頭來實現，例如。指定在/etc/gitlab/gitlab.rb：

nginx['proxy_set_headers'] = { "X-Forwarded-Proto" => "http", "CUSTOM_HEADER" => "VALUE" } 

保存文件並從新配置GitLab ，使更改生效。

這樣，您能夠指定您須要的NGINX支持的任何頭。

配置GitLab trusted_proxies和NGINX real_ip模塊

默認狀況下，NGINX和GitLab將記錄鏈接的客戶端的IP地址。

若是您的GitLab位於反向代理以後，您可能不但願代理的IP地址顯示爲客戶端地址。

您能夠經過將反向代理添加到real_ip_trusted_addresses列表中，使NGINX能夠查找不一樣的地址：

# Each address is added to the the NGINX config as 'set_real_ip_from <address>;' nginx['real_ip_trusted_addresses'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ] # other real_ip config options nginx['real_ip_header'] = 'X-Real-IP' nginx['real_ip_recursive'] = 'on' 

選項說明：

• http://nginx.org/en/docs/http/ngx_http_realip_module.html

默認狀況下，omnibus-gitlab將使用IP地址real_ip_trusted_addresses 做爲GitLab的信任代理，這將阻止用戶從這些IP中登陸。

保存文件並從新配置GitLab ，使更改生效。

配置HTTP2協議 

默認狀況下，當您指定您的Gitlab實例應經過HTTPS指定時external_url "https://gitlab.example.com"， http2協議也被啓用。

omn​​ibus-gitlab軟件包設置與http2協議兼容的所需ssl_ciphers。

若是您在配置中指定自定義ssl_ciphers，而且密碼位於http2密碼黑名單中，一旦您嘗試訪問GitLab實例INADEQUATE_SECURITY，您的瀏覽器將顯示錯誤。

考慮從密碼列表中刪除違規密碼。只有使用很是具體的自定義設置，才須要更改密碼。

有關爲何要啓用http2協議的更多信息，請查看http2白皮書。

若是更改密碼不是一個選項，能夠經過指定在/etc/gitlab/gitlab.rbhttp：

nginx['http2_enabled'] = false 

保存文件並從新配置GitLab ，使更改生效。

使用非捆綁的Web服務器 

默認狀況下，omnibus-gitlab使用捆綁的Nginx安裝GitLab。Omnibus-gitlab容許網絡服務器經過gitlab-www位於同一組名的用戶進行訪問。要容許外部Web服務器訪問GitLab，外部Web服務器用戶須要添加gitlab-www組。

要使用其餘Web服務器（如Apache）或現有的Nginx安裝，您必須執行如下步驟：

1. 禁用捆綁的Nginx

   在/etc/gitlab/gitlab.rb集合：

   nginx['enable'] = false 

2. 設置非捆綁的Web服務器用戶的用戶名

   默認狀況下，omnibus-gitlab沒有外部Web服務器用戶的默認設置，您必須在配置中指定它。對於Debian / Ubuntu，默認用戶是www-dataApache / Nginx，而對於RHEL / CentOS，Nginx用戶是nginx。

   注意：確保先安裝了Apache / Nginx，以便建立網絡服務器用戶，不然在從新配置時omnibus將失敗。

   比方說，網絡服務器用戶是www-data。在/etc/gitlab/gitlab.rb集合：

   web_server['external_users'] = ['www-data'] 

   注意：此設置是一個數組，所以您能夠指定多個用戶添加到gitlab-www組。

   運行sudo gitlab-ctl reconfigure使更改生效。

   注意：若是您使用SELinux，而且您的Web服務器運行在受限制的SELinux配置文件下，您可能必須鬆開Web服務器上的限制。

   *注意：確保網絡服務器用戶對外部Web服務器使用的全部目錄具備正確的權限，不然您將收到failed (XX: Permission denied) while reading upstream錯誤。

3. 將非捆綁的Web服務器添加到可信代理列表中

   一般，omnibus-gitlab將可信代理列表默認爲捆綁的NGINX的real_ip模塊中配置的代理。

   對於非捆綁的Web服務器，列表須要直接配置，若是Web服務器與GitLab不在同一臺機器上，則應包含該IP地址。不然用戶將被顯示爲從您的Web服務器的IP地址登陸。

   gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ] 

4. （可選）若是使用Apache，請設置正確的gitlab-workhorse設置

   注意：如下值在GitLab 8.2中添加，請確保已安裝最新版本。

   Apache沒法鏈接到UNIX套接字，而須要鏈接到TCP端口。容許gitlab-workhorse在TCP上偵聽（默認端口8181）編輯/etc/gitlab/gitlab.rb：

   gitlab_workhorse['listen_network'] = "tcp"
   gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"

   運行sudo gitlab-ctl reconfigure使更改生效。

5. 下載正確的Web服務器配置

   轉到GitLab配方存儲庫，並在您選擇的webserver目錄中查找omnibus配置。確保您選擇正確的配置文件，具體取決於您是否選擇使用SSL提供GitLab。您惟一須要更改的是YOUR_SERVER_FQDN使用您本身的FQDN，若是您使用SSL，SSL密鑰當前所在的位置。您還可能須要更改日誌文件的位置。

設置NGINX監聽地址或地址 

默認狀況下，NGINX將接受全部本地IPv4地址的傳入鏈接。您能夠更改地址列表/etc/gitlab/gitlab.rb。

nginx['listen_addresses'] = ["0.0.0.0", "[::]"] # listen on all IPv4 and IPv6 addresses 

設置NGINX監聽端口 

默認狀況下，NGINX將偵聽指定的端口external_url或隱式使用正確的端口（HTTP爲80，HTTPS爲443）。若是您在反向代理以後運行GitLab，則可能須要將監聽端口重寫爲其餘。例如，要使用端口8081：

nginx['listen_port'] = 8081 

支持代理SSL 

默認狀況下，若是external_url 包含，NGINX將自動檢測是否使用SSL https://。若是您在反向代理以後運行GitLab，則可能但願在另外一個代理服務器或負載均衡器上終止SSL。爲此，請確保external_url包含https://並應用如下配置gitlab.rb：

nginx['listen_port'] = 80 nginx['listen_https'] = false nginx['proxy_set_headers'] = { "X-Forwarded-Proto" => "https", "X-Forwarded-Ssl" => "on" } 

請注意，您可能須要配置反向代理服務器或負載平衡器來轉發特定的頭文件（例如Host，X-Forwarded-Ssl，X-Forwarded-For，X-Forwarded-Port（若是你使用一個和Mattermost）），以GitLab。若是您忘記了此步驟，您可能會看到不正確的重定向或錯誤（例如「422不可處理實體」，「沒法驗證CSRF令牌真實性」）。有關詳細信息，請參閱：

• http://stackoverflow.com/questions/16042647/whats-the-de-facto-standard-for-a-reverse-proxy-to-tell-the-backend-ssl-is-used
• https://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy

設置HTTP嚴格的傳輸安全性 

默認狀況下，GitLab啓用嚴格的傳輸安全性，通知瀏覽器他們應該只使用HTTPS聯繫網站。當瀏覽器訪問GitLab實例時，即便用戶顯式地輸入http://url，它也會記住再也不嘗試不安全的鏈接。這樣的URL將被瀏覽器自動重定向到https://變體。

nginx['hsts_max_age'] = 31536000 nginx['hsts_include_subdomains'] = false 

默認max_age設置爲一年，這是瀏覽器記住僅經過HTTPS鏈接的時間。設置max_age爲0將禁用此功能。有關更多信息，請參閱

• https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/

使用自定義SSL密碼 

默認狀況下，GitLab使用的SSL密碼是gitlab.com上的測試和GitLab社區貢獻的各類最佳作法。

可是，您能夠經過添加到更改ssl密碼gitlab.rb：

nginx['ssl_ciphers'] = "CIPHER:CIPHER1" 

並運行從新配置。

您還能夠啓用ssl_dhparam指令。

首先，生成dhparams.pem用openssl dhparam -out dhparams.pem 2048。而後，gitlab.rb添加生成文件的路徑，例如：

nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem" 

變動運行後sudo gitlab-ctl reconfigure。

啓用雙向SSL客戶端身份驗證 

要求Web客戶端使用受信任的證書進行身份驗證，您能夠經過添加到gitlab.rb如下方式啓用雙向SSL ：

nginx['ssl_verify_client'] = "on" 

並運行從新配置。

還能夠配置NGINX支持配置SSL客戶端身份驗證的其餘選項：

nginx['ssl_client_certificate'] = "/etc/pki/tls/certs/root-certs.pem" nginx['ssl_verify_depth'] = "2" 

進行更改運行後sudo gitlab-ctl reconfigure。

將自定義NGINX設置插入到GitLab服務器塊中 

請記住，若是您的gitlab.rb文件中定義了相同的設置，這些自定義設置可能會產生衝突。

若是您須要將自定義設置添加到serverGitLab 的NGINX 塊中，某些緣由可使用如下設置。

# Example: block raw file downloads from a specific repository nginx['custom_gitlab_server_config'] = "location ^~ /foo-namespace/bar-project/raw/ {\n deny all;\n}\n" 

運行gitlab-ctl reconfigure以重寫NGINX配置並從新啓動NGINX。

這將定義的字符串插入server塊 的末尾/var/opt/gitlab/nginx/conf/gitlab-http.conf。

筆記： 

• 若是您要添加新的位置，則可能須要包含

  proxy_cache off; proxy_pass http://gitlab-workhorse; 

  在字符串或包含的nginx配置中。沒有這些，任何子位置都將返回404。參見 gitlab-ce＃30619。

• 您不能將根/位置或/assets位置添加爲已存在的位置gitlab-http.conf。

將自定義設置插入NGINX配置 

若是您須要將自定義設置添加到NGINX配置中，例如要包括現有服務器塊，則可使用如下設置。

# Example: include a directory to scan for additional config files nginx['custom_nginx_config'] = "include /etc/nginx/conf.d/*.conf;" 

運行gitlab-ctl reconfigure以重寫NGINX配置並從新啓動NGINX。

這將定義的字符串插入http塊 的末尾/var/opt/gitlab/nginx/conf/nginx.conf。

自定義錯誤頁面 

您可使用custom_error_pages默認GitLab錯誤頁面修改文本。這能夠用於任何有效的HTTP錯誤代碼; 例如404,502。

做爲示例，如下內容將修改默認的404錯誤頁面。

nginx['custom_error_pages'] = { '404' => { 'title' => 'Example title', 'header' => 'Example header', 'message' => 'Example message' } } 

這將致使下面的404錯誤頁面。

運行gitlab-ctl reconfigure以重寫NGINX配置並從新啓動NGINX。

使用現有的Passenger / Nginx安裝 

在某些狀況下，您可能但願使用現有的Passenger / Nginx安裝來託管GitLab，但仍然可使用omnibus軟件包更新和安裝。

組態 

首先，你須要設置你的/etc/gitlab/gitlab.rbNginx和Unicorn內置的：

# Define the external url external_url 'http://git.example.com' # Disable the built-in nginx nginx['enable'] = false # Disable the built-in unicorn unicorn['enable'] = false # Set the internal API URL gitlab_rails['internal_api_url'] = 'http://git.example.com' # Define the web server process user (ubuntu/nginx) web_server['external_users'] = ['www-data'] 

確保運行sudo gitlab-ctl reconfigure更改才能生效。

注意：若是您運行的版本早於8.16.0，則必須手動刪除獨角獸服務文件（/opt/gitlab/service/unicorn）（若是存在）才能從新配置成功。

Vhost（服務器塊） 

而後，在您的自定義Passenger / Nginx安裝中，建立如下站點配置文件：

upstream gitlab-workhorse {
  server unix://var/opt/gitlab/gitlab-workhorse/socket fail_timeout=0;
}

server {
  listen *:80;
  server_name git.example.com;
  server_tokens off;
  root /opt/gitlab/embedded/service/gitlab-rails/public;

  client_max_body_size 250m;

  access_log  /var/log/gitlab/nginx/gitlab_access.log;
  error_log   /var/log/gitlab/nginx/gitlab_error.log;

  # Ensure Passenger uses the bundled Ruby version
  passenger_ruby /opt/gitlab/embedded/bin/ruby;

  # Correct the $PATH variable to included packaged executables
  passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

  # Make sure Passenger runs as the correct user and group to
  # prevent permission issues
  passenger_user git;
  passenger_group git;

  # Enable Passenger & keep at least one instance running at all times
  passenger_enabled on;
  passenger_min_instances 1;

  location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
    # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
    error_page 418 = @gitlab-workhorse;
    return 418;
  }

  location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
    # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
    error_page 418 = @gitlab-workhorse;
    return 418;
  }

  location ~ ^/api/v3/projects/.*/repository/archive {
    # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
    error_page 418 = @gitlab-workhorse;
    return 418;
  }

  # Build artifacts should be submitted to this location
  location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
      client_max_body_size 0;
      # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
      error_page 418 = @gitlab-workhorse;
      return 418;
  }

  # Build artifacts should be submitted to this location
  location ~ /ci/api/v1/builds/[0-9]+/artifacts {
      client_max_body_size 0;
      # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
      error_page 418 = @gitlab-workhorse;
      return 418;
  }

  # Build artifacts should be submitted to this location
  location ~ /api/v4/jobs/[0-9]+/artifacts {
      client_max_body_size 0;
      # 'Error' 418 is a hack to re-use the @gitlab-workhorse block
      error_page 418 = @gitlab-workhorse;
      return 418;
  }


  # For protocol upgrades from HTTP/1.0 to HTTP/1.1 we need to provide Host header if its missing
  if ($http_host = "") {
  # use one of values defined in server_name
    set $http_host_with_default "git.example.com";
  }

  if ($http_host != "") {
    set $http_host_with_default $http_host;
  }

  location @gitlab-workhorse {

    ## https://github.com/gitlabhq/gitlabhq/issues/694
    ## Some requests take more than 30 seconds.
    proxy_read_timeout      3600;
    proxy_connect_timeout   300;
    proxy_redirect          off;

    # Do not buffer Git HTTP responses
    proxy_buffering off;

    proxy_set_header    Host                $http_host_with_default;
    proxy_set_header    X-Real-IP           $remote_addr;
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto   $scheme;

    proxy_pass http://gitlab-workhorse;

    ## The following settings only work with NGINX 1.7.11 or newer
    #
    ## Pass chunked request bodies to gitlab-workhorse as-is
    # proxy_request_buffering off;
    # proxy_http_version 1.1;
  }

  ## Enable gzip compression as per rails guide:
  ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
  ## WARNING: If you are using relative urls remove the block below
  ## See config/application.rb under "Relative url support" for the list of
  ## other files that need to be changed for relative url support
  location ~ ^/(assets)/ {
    root /opt/gitlab/embedded/service/gitlab-rails/public;
    gzip_static on; # to serve pre-gzipped version
    expires max;
    add_header Cache-Control public;
  }

  error_page 502 /502.html;
}

不要忘記在上面的例子中更新「git.example.com」做爲您的服務器URL。

注意：若是您使用403禁止，可能您還沒有啓用/etc/nginx/nginx.conf中的乘客，只能取消註釋：

# include /etc/nginx/passenger.conf;

那麼，'sudo service nginx reload'

啓用/禁用nginx_status 

默認狀況下，您將有一個配置爲127.0.0.1:8060/nginx_status的nginx健康檢查端點來監視您的Nginx服務器狀態。

將顯示如下信息： 

Active connections: 1
server accepts handled requests
 18 18 36
Reading: 0 Writing: 1 Waiting: 0

• 活動鏈接 - 總共打開鏈接。
• 顯示3個數字。
  • 全部接受的鏈接。
  • 全部處理的鏈接。
  • 處理的請求總數
• 讀取：Nginx讀取請求頭
• 寫入：Nginx讀取請求體，處理請求或向客戶端寫入響應
• 等待：保持鏈接。該值取決於keepalive-timeout。

組態 

編輯/etc/gitlab/gitlab.rb：

nginx['status'] = {
  "listen_addresses" => ["127.0.0.1"],
  "fqdn" => "dev.example.com",
  "port" => 9999,
  "options" => {
    "stub_status" => "on", # Turn on stats
    "access_log" => "on", # Disable logs for stats
    "allow" => "127.0.0.1", # Only allow access from localhost
    "deny" => "all" # Deny access to anyone else
  }
}

若是您沒有發現此服務對您當前的基礎設施有用，能夠經過如下方式禁用它：

nginx['status'] = { 'enable' => false } 

確保運行sudo gitlab-ctl reconfigure以使更改生效。

警告 

爲了確保用戶上傳能夠訪問，您的Nginx用戶（一般www-data）應該添加到gitlab-www組中。這可使用如下命令完成：

sudo usermod -aG gitlab-www www-data 

模板 

除了乘客配置代替獨角獸和缺乏HTTPS（儘管能夠啓用），這些文件大致上與如下相同：

• 捆綁的Gitlab Nginx配置

不要忘記從新啓動Nginx以加載新配置（在基於Debian的系統上sudo service nginx restart）。

故障排除 

400錯誤請求：太多主機頭 

確保您沒有設置中的proxy_set_header配置 nginx['custom_gitlab_server_config']，而是使用文件中的 「proxy_set_headers」配置gitlab.rb。

javax.net.ssl.SSLHandshakeException：接收致命警報：handshake_failure 

從GitLab 10開始，默認狀況下，omnibus-gitlab軟件包再也不支持TLSv1協議。當與您的GitLab實例進行交互時，這可能會致使與一些較舊的基於Java的IDE客戶端的鏈接問題。咱們強烈要求您升級服務器上的密碼，與用戶評論中提到的類似。

若是不可能使此服務器更改，您能夠經過更改如下內容的值來默認返回到舊的行爲/etc/gitlab/gitlab.rb：

nginx['ssl_protocols'] = "TLSv1 TLSv1.1 TLSv1.2"