Ubuntu16.04でLet’sEncryptを使用してGitLabを保護する方法

投稿日: 2022-07-13 2022-10-16
タグ: git, Let's Encrypt, Security, ubuntu, Ubuntu 16.04

ステータス：非推奨

この記事では、Let’sEncryptを使用してGitLabを手動で構成する古い方法について説明します。 GitLabバージョン10.5以降、Let’sEncryptのサポートはGitlab内でネイティブに利用できます。

Ubuntu 16.04にGitLabをインストールして構成する方法に関するガイドが更新され、GitLab内の関連する構成設定が含まれるようになりました。今後はそのガイドを参照することをお勧めします。

序章

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ブラウザーで信頼されている認証局によって署名された証明書を提供します。

このガイドでは、Let’sEncryptから取得した信頼できるSSL証明書を使用するようにUbuntu16.04にインストールされたGitLabインスタンスを構成する方法を示します。これにより、ユーザーへのすべての発信通信が保護され、パスワード、コード、およびその他の通信が外部の第三者によって読み取られたり改ざんされたりするのを防ぐことができます。

前提条件

このガイドを完了するには、GitLabインスタンスをUbuntu16.04サーバーにインストールする必要があります。この設定を行うには、 Ubuntu16.04ガイドにGitLabをインストールして構成する方法に従っていることを前提としています。

Let’s Encryptから証明書を取得するには、サーバーを完全修飾ドメイン名（FQDN）で構成する必要があります。まだドメイン名を登録していない場合は、そこにある多くのドメイン名レジストラの1つに登録できます（例： Namecheap、GoDaddyなど）。

まだ作成していない場合は、ドメインがサーバーのパブリックIPアドレスを指すAレコードを作成してください。これが必要なのは、Let’s Encryptが、証明書を発行しているドメインを所有していることを検証する方法のためです。たとえば、次の証明書を取得する場合 gitlab.example.com、検証プロセスが機能するには、そのドメインがサーバーに解決される必要があります。このガイドを正常に完了するには、サーバーを指す有効なDNSレコードを持つ実際のドメインが必要です。

Let’sEncryptクライアントであるCertbotをインストールします

GitLabインストール用のSSL証明書を取得する前に、公式のLet’sEncryptクライアントであるCertbotをダウンロードしてインストールする必要があります。

Certbot開発者は、ソフトウェアの最新バージョンを使用して独自のUbuntuソフトウェアリポジトリを維持しています。 Certbotは非常に活発に開発されているため、このリポジトリを使用して、Ubuntuが提供するよりも新しいCertbotをインストールする価値があります。

まず、リポジトリを追加します。

sudo add-apt-repository ppa:certbot/certbot

を押す必要があります ENTER 受け入れるために。その後、パッケージリストを更新して、新しいリポジトリのパッケージ情報を取得します。

sudo apt-get update

そして最後に、Certbotをインストールします apt-get:

sudo apt-get install certbot

Certbotがインストールされたので、証明書を発行する前にLet’sEncryptが必要とするドメイン所有権検証テストにサーバーが正常に応答できるようにサーバーを準備できます。

Let’sEncryptWebルートドメイン検証の準備

Let’s Encrypt認証局からSSL証明書を受け取るには、証明書が提供されるドメインを所有していることを証明する必要があります。ドメインの所有権を証明する方法は複数あり、それぞれがサーバーへのルートまたは管理者アクセスを必要とします。

GitLabには、アプリケーション自体を提供するための内部管理されたNginxWebサーバーが含まれています。これにより、インストールはかなり自己完結型になりますが、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構成ファイルにカスタムディレクティブを挿入する行を追加する必要があります。ファイルのGitLabNginx セクションまでスクロールダウンするのがおそらく最善ですが、行はどこにでも配置できます。

次の行に貼り付けます。

/etc/gitlab/gitlab.rb

. . .
nginx['custom_gitlab_server_config'] = "location ^~ /.well-known { root /var/www/letsencrypt; }"
. . .

Let’s EncryptのWebルート検証メソッドは、ファイルを .well-known 認証局がそれを検証できるように、ドキュメントルートのディレクトリ。この行は、Nginxに次のリクエストを処理するように指示します /.well-known 少し前に作成したWebルートから。

終了したら、ファイルを保存して閉じます。

次に、アプリケーションを再構成して、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 your_domain

メールアドレスの入力を求められます。有効な電子メールアドレスを含めることが重要です。これは、証明書の有効期限やその他の重要な情報に関する電子メールを確実に受信する唯一の方法です。また、Let’sEncryptの利用規約に同意するよう求められます。

完了したら、所有権を正しく検証できた場合、Let’sEncryptはドメインの証明書を発行する必要があります。次のような出力が表示されます。

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

を見ると、作成されたすべての証明書とキーを見つけることができます。 /etc/letsencrypt/live/your_domain ディレクトリと sudo 特権：

sudo ls /etc/letsencrypt/live/your_domain

Outputcert.pem  chain.pem  fullchain.pem  privkey.pem

私たちの構成では、へのフルパスを知る必要があるだけです。 fullchain.pem と privkey.pem ファイル。

Let’sEncrypt証明書を使用するようにGitLabを構成する

Let’s Encryptから信頼できる証明書を取得したので、すべてのトラフィックにTLS/SSLを使用するようにGitLabを構成できます。

GitLab構成を編集する

GitLab構成ファイルをもう一度開くことから始めます。

sudo nano /etc/gitlab/gitlab.rb

上部で、 external_url. 現在、それはおそらく指している http://your_domain. 変更する必要があります http に https:

/etc/gitlab/gitlab.rb

. . .
external_url 'https://your_domain'
. . .

次に、 GitLabNginxセクションまでスクロールして戻ります。次の行のコメントを外して変更するか、単に追加します。

リダイレクトラインは、HTTPポート80に対して行われたリクエストをHTTPSポート443に自動的にリダイレクトするようにNginxに指示します。 The ssl_certificate 線は、のフルパスを指している必要があります fullchain.pem ファイル、 ssl_certificate_key 線は、のフルパスを指している必要があります privkey.pem ファイル：

/etc/gitlab/gitlab.rb

. . .
nginx['redirect_http_to_https'] = true
. . .
nginx['ssl_certificate'] = "/etc/letsencrypt/live/your_domain/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/your_domain/privkey.pem"
. . .

終了したら、ファイルを保存して閉じます。

ファイアウォールを通過するHTTPSトラフィックを許可する

次に、GitLabのNginx構成をリロードする前に、HTTPSトラフィックがサーバーのファイアウォールを通過できることを確認してください。次のように入力すると、この目的でポート443を開くことができます。

sudo ufw allow https

OutputRule added
Rule added (v6)

次のように入力して、ポート443が開いていることを確認します。

sudo ufw status

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)             
80 (v6)                    ALLOW       Anywhere (v6)             
443 (v6)                   ALLOW       Anywhere (v6)

ご覧のとおり、ポート443が公開されています。

SSLを有効にするためにGitLabを再構成します

次に、GitLabを再構成して、変更を実装します。

sudo gitlab-ctl reconfigure

これで、信頼できるLet’sEncrypt証明書を使用してHTTPS経由でGitLabインスタンスにアクセスできるようになります。これをテストするには、GitLabサーバーのドメイン名にアクセスします。 HTTPをHTTPSにリダイレクトするため、これはプロトコルを明示的に指定しなくても機能するはずです。

http://your_domain

ブラウザは、HTTPSを使用するように自動的にリダイレクトする必要があります。サイトがアドレスバーに保護されていることを示す表示が表示されるはずです。

これで、GitLabのインストールがTLS/SSL証明書で保護されます。

Certbotの自動更新の確認

Let’s Encryptの証明書は、90日間のみ有効です。これは、ユーザーが証明書の更新プロセスを自動化することを奨励するためです。 The certbot インストールしたパッケージは、systemdタイマーを介して「certbotrenew」を1日2回実行することで、これを処理します。非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を使用してリポジトリへの各コミットを自動的にテストする方法については、 GitLabCIを使用した継続的インテグレーションパイプラインの設定に関する記事をご覧ください。

getdocs

13036