Ubuntu16.04でLet’sEncryptを使用してGitLabを保護する方法
ステータス:非推奨
この記事では、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’sEncryptが証明書を発行しているドメインを所有していることを検証する方法のために必要です。 たとえば、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
そして最後に、apt-get
を使用してCertbotをインストールします。
- 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 セクションまでスクロールダウンするのがおそらく最善ですが、行はどこにでも配置できます。
次の行に貼り付けます。
. . .
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 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
sudo
権限を持つ/etc/letsencrypt/live/your_domain
ディレクトリを確認すると、作成されたすべての証明書とキーを見つけることができます。
- 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
に変更するだけです。
. . .
external_url 'https://your_domain'
. . .
次に、 GitLabNginxセクションまでスクロールして戻ります。 次の行のコメントを外して変更するか、単に追加します。
リダイレクト行は、HTTPポート80に対して行われた要求をHTTPSポート443に自動的にリダイレクトするようにNginxに指示します。 ssl_certificate
行はfullchain.pem
ファイルのフルパスを指している必要があり、ssl_certificate_key
行はprivkey.pem
ファイルのフルパスを指している必要があります。
. . .
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日間のみ有効です。 これは、ユーザーが証明書の更新プロセスを自動化することを奨励するためです。 インストールした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を使用した継続的インテグレーションパイプラインの設定に関する記事をご覧ください。