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"