前書き
GitLab、特にGitLab CE（Community Edition）は、主にGitリポジトリをホストするために使用されるオープンソースアプリケーションであり、問題追跡などの開発関連機能が追加されています。 GitLabプロジェクトでは、簡単なインストールメカニズムを使用して、ハードウェア上にGitLabインスタンスをセットアップするのが比較的簡単です。
デフォルトでは、GitLabは暗号化されていないプレーンなHTTP経由でページを提供します。 ログイン資格情報などの機密情報を処理するWebアプリケーションと同様に、GitLabは、TLS / SSLを介してページを提供し、送信中のデータを暗号化するように構成する必要があります。 ログイン資格情報を傍受できる誰かがプロジェクトのコードベースを変更する可能性があるため、これはGitLabにとって非常に重要です。
Let’s Encryptプロジェクトを使用すると、任意のWebサイトまたはWebアプリケーションの信頼できるSSL証明書を簡単に取得できます。 Let’s Encryptは、証明書を要求しているドメインを所有していることを証明できる場合、すべての最新のWebブラウザーで信頼されている認証局によって署名された証明書を提供します。
このガイドでは、Ubuntu 16.04にインストールされたGitLabインスタンスを設定して、Let’s Encryptから取得した信頼できるSSL証明書を使用する方法を示します。 これにより、ユーザーへのすべての発信通信が保護され、パスワード、コード、およびその他の通信が外部の第三者による読み取りや改ざんから保護されます。
前提条件
このガイドを完了するには、Ubuntu 16.04サーバーにGitLabインスタンスをインストールする必要があります。 GitLabをUbuntuにインストールして構成する方法16.04これをセットアップするためのガイド。
Let’s Encryptから証明書を取得するには、完全修飾ドメイン名（FQDN）でサーバーを構成する必要があります。 登録済みのドメイン名をまだお持ちでない場合は、多数のドメイン名レジストラーのいずれかに登録できます（例： Namecheap、GoDaddyなど）。
まだ行っていない場合は、ドメインがサーバーのパブリックIPアドレスを指す* Aレコード*を作成してください。 これは、Let’s Encryptが証明書を発行するドメインを所有していることを検証する方法のために必要です。 たとえば、 `+ gitlab.example.com +`の証明書を取得する場合、検証プロセスが機能するためには、そのドメインがサーバーに解決される必要があります。 このガイドを正常に完了するには、サーバーを指す有効なDNSレコードを持つ実際のドメインが必要です。
Let’s EncryptクライアントであるCertbotをインストールします
GitLabインストールのSSL証明書を取得する前に、公式のLet’s EncryptクライアントであるCertbotをダウンロードしてインストールする必要があります。
Certbotの開発者は、最新バージョンのソフトウェアを使用して独自のUbuntuソフトウェアリポジトリを維持しています。 Certbotは非常に活発に開発されているため、このリポジトリを使用してUbuntuが提供するよりも新しいCertbotをインストールする価値があります。
まず、リポジトリを追加します。
sudo add-apt-repository ppa:certbot/certbot受け入れるには `+ ENTER`を押す必要があります。 その後、パッケージリストを更新して、新しいリポジトリのパッケージ情報を取得します。
sudo apt-get update最後に、 `+ apt-get`でCertbotをインストールします。
sudo apt-get install certbotCertbotがインストールされたので、Let’s Encryptが証明書を発行する前に必要なドメイン所有権検証テストに正常に応答できるようにサーバーを準備できます。
Let’s Encrypt Web Root Domain Verificationの準備
Let’s Encrypt認証局からSSL証明書を受け取るには、証明書が提供されるドメインを所有していることを証明する必要があります。 ドメインの所有権を証明する方法は複数あり、それぞれがサーバーへのルートまたは管理者アクセスを必要とします。
GitLabには、アプリケーション自体を提供するための内部管理されたNginx Webサーバーが含まれています。 これにより、インストールはかなり自己完結型になりますが、Webサーバー自体を変更しようとすると、複雑さが増します。
現在、組み込みのNginxはGitLab自体の提供に利用されているため、最適なドメイン検証方法はWebルート方法です。 Certbotは既存のWebサーバーを使用して、ポート80でサーバーから既知のファイルを提供します。 これにより、認証局は、証明書を要求している人がWebサーバーの管理制御権を持っていることを証明し、サーバーとドメインの所有権を効果的に証明します。
GitLabのWebルートドメイン検証をセットアップするための最初のステップは、ダミーのドキュメントルートを作成することです。
sudo mkdir -p /var/www/letsencryptこれは通常のNginx操作では使用されませんが、Certbotではドメイン検証に使用されます。
次に、このディレクトリを使用するためにGitLabのNginx設定を調整する必要があります。 次のように入力して、メインのGitLab構成ファイルを開きます。
sudo nano /etc/gitlab/gitlab.rb内部では、GitLabのNginx構成ファイルにカスタムディレクティブを挿入する行を追加する必要があります。 ファイルの* GitLab Nginx *セクションまでスクロールするのがおそらく最善ですが、行はどこにでも配置できます。
次の行に貼り付けます。
/etc/gitlab/gitlab.rb
. . .
nginx['custom_gitlab_server_config'] = "location ^~ /.well-known { root /var/www/letsencrypt; }"
. . .Let’s Encrypt Webルート検証メソッドは、ドキュメントルートの `+ .well-known `ディレクトリ内にファイルを配置し、認証局が検証できるようにします。 この行は、先ほど作成したWebルートからの ` /。well-known +`のリクエストを処理するようにNginxに指示します。
終了したら、ファイルを保存して閉じます。
次に、アプリケーションを再構成して、GitLabのNginx構成に変更を適用します。
sudo gitlab-ctl reconfigureこれで、ドメインを正常に検証するようにサーバーを設定する必要があります。
Certbotで証明書をリクエストする
GitLabのNginxインスタンスに必要なロケーションブロックが構成されたので、Certbotを使用してドメイン名を検証し、証明書を要求できます。
証明書のみが必要であり、Webサーバーを自動的に構成したくないため、 + certonly`サブコマンドを使用します。 3つのオプションを指定します。 Webルート認証（ `+-webroot +）を選択し、ドキュメントルート（ +-webroot-path = / var / www / letsencrypt +）を渡し、 `+ -d +`コマンドを使用して渡す必要がありますドメイン名：
sudo certbot certonly --webroot --webroot-path=/var/www/letsencrypt -dメールアドレスを入力するように求められます。 有効な電子メールアドレスを含めることが重要です。これは、証明書の有効期限やその他の重要な情報に関する電子メールを確実に受信する唯一の方法です。 また、Let’s Encryptの利用規約に同意するよう求められます。
完了したら、Let’s Encryptはドメインの所有権を正しく検証できた場合、ドメインの証明書を発行する必要があります。 次のような出力が表示されます。
OutputIMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/gitlab.example.com/fullchain.pem. Your cert
will expire on 2017-07-26. To obtain a new or tweaked version of
this certificate in the future, simply run certbot again. To
non-interactively renew *all* of your certificates, run "certbot
renew"
- If you lose your account credentials, you can recover through
e-mails sent to [email protected].
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le`+ sudo `権限で ` / etc / letsencrypt / live / +`ディレクトリを見ると、作成されたすべての証明書とキーを見つけることができます。
sudo ls /etc/letsencrypt/live/Outputcert.pem chain.pem fullchain.pem privkey.pemこの設定では、 `+ fullchain.pem `および ` privkey.pem +`ファイルへのフルパスを知るだけで済みます。
Let’s Encrypt証明書を使用するためのGitLabの構成
Let’s Encryptから信頼できる証明書を取得したので、すべてのトラフィックにTLS / SSLを使用するようにGitLabを構成できます。
GitLab構成を編集する
GitLab構成ファイルを再度開くことから始めます。
sudo nano /etc/gitlab/gitlab.rb上部で、 + external_url +`を変更します。 現在、 `+ http：// +`を指している可能性があります。 `+ http`を + https`に変更するだけです：
/etc/gitlab/gitlab.rb
. . .
external_url 'http://'
. . .次に、スクロールダウンして* GitLab Nginx *セクションに戻ります。 次の行のコメントを解除して変更するか、単に追加します。
リダイレクト行は、HTTPポート80への要求をHTTPSポート443に自動的にリダイレクトするようにNginxに指示します。 `+ ssl_certificate `行は ` fullchain.pem `ファイルのフルパスを指し、 ` ssl_certificate_key `行は ` privkey.pem +`ファイルのフルパスを指している必要があります。
/etc/gitlab/gitlab.rb
. . .
nginx['redirect_http_to_https'] =
. . .
nginx['ssl_certificate'] = "/etc/letsencrypt/live//fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live//privkey.pem"
. . .完了したら、ファイルを保存して閉じます。
ファイアウォールを通過するHTTPSトラフィックを許可する
次に、GitLabのNginx設定をリロードする前に、サーバーのファイアウォールを通過するHTTPSトラフィックが許可されていることを確認してください。 次のように入力して、この目的でポート443を開くことができます。
sudo ufw allow httpsOutputRule added
Rule added (v6)次のように入力して、ポート443が開いていることを確認します。
sudo ufw statusOutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
80 ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)ご覧のとおり、ポート443が公開されています。
SSLを有効にするためにGitLabを再構成する
次に、GitLabを再構成して、変更を実装します。
sudo gitlab-ctl reconfigureこれで、信頼できるLet’s Encrypt証明書を使用してGitLabインスタンスにHTTPS経由でアクセスできるようになります。 GitLabサーバーのドメイン名にアクセスして、これをテストできます。 HTTPをHTTPSにリダイレクトするため、これはプロトコルを明示的に指定しなくても機能するはずです。
http://ブラウザは、HTTPSを使用するように自動的にリダイレクトします。 サイトがアドレスバーに保護されていることを示す何らかの表示が表示されます。
image：https：//assets.digitalocean.com/articles/gitlab_lets_encrypt_1604/https_connection_verification.png [GitLab SSL検証]
GitLabインストールは、TLS / SSL証明書で保護されるようになりました。
Certbotの自動更新の検証
Let’s Encryptの証明書は90日間のみ有効です。 これは、ユーザーが証明書の更新プロセスを自動化することを奨励するためです。 インストールした `+ certbot `パッケージは、systemdタイマーを介して1日に2回「certbot renew」を実行することでこれを処理します。 systemd以外のディストリビューションでは、この機能は ` / etc / cron.d +`に置かれたスクリプトによって提供されます。 このタスクは1日に2回実行され、有効期限の30日以内に証明書を更新します。
更新プロセスをテストするには、 `+ certbot +`でドライランを実行できます。
sudo certbot renew --dry-runエラーが表示されなければ、設定は完了です。 必要に応じて、Certbotは証明書を更新し、Nginxをリロードして変更を反映します。 自動更新プロセスが失敗した場合、Let’s Encryptは指定したメールにメッセージを送信し、証明書の有効期限が近づいていることを警告します。
結論
これで、GitLabインスタンスは、すべての最新のブラウザーで信頼されている安全なTLS / SSL証明書によって保護されるはずです。 組み込みのNginxインスタンスの構成は、スタンドアロンのNginx Webサーバーのセットアップよりも少し複雑ですが、GitLabは構成ファイル内のロケーションブロックをカスタマイズする機能を公開しているため、簡単に回避できます。
GitLabインスタンスは安全になったので、プロジェクトの管理、コードリポジトリのホスト、継続的インテグレーションの構成に安全に使用できます。 GitLabを使用してリポジトリへの各コミットを自動的にテストする方法については、https：//www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-pipelines-with-gitlab-の記事をご覧ください。 ci-on-ubuntu-16-04 [GitLab CIによる継続的統合パイプラインのセットアップ]。