Ubuntu16.04でNginxを使用してSSLでConcourseCIを保護する方法

投稿日: 2019-11-08 2022-04-20
タグ: CI/CD, ubuntu, Ubuntu 16.04

序章

Concourse CI は、構成可能な宣言型構文を使用してパイプラインのテストを自動化するように設計された、最新のスケーラブルな継続的インテグレーションシステムです。 Concourseは、以前のCIシステムの成功を基に、パイプライン管理を簡素化し、「スノーフレーク」サーバーを排除して、テストサーバーが処理するコードと同様に規制されるようにすることを目的としています。

前のチュートリアルでは、Ubuntu16.04サーバーにConcourseCIインスタンスをインストールして構成する方法を示しました。最終的に、コマンドラインとWebインターフェイスの両方から管理および監視できる継続的インテグレーションサーバーが残りました。

このガイドでは、Nginxを使用してTLS / SSLリバースプロキシを設定することにより、ConcourseCIインターフェースを保護します。 ConcourseはSSLをネイティブに使用するように構成できますが、リバースプロキシは、将来のスケーリングとより堅牢な機能セットへのアクセスのための柔軟性を提供します。

前提条件

始める前に、少なくとも1GのRAMを備えたUbuntu16.04サーバーが必要です。以下のガイドを完了して、root以外のユーザーをセットアップし、Concourseをインストールして構成し、Nginxをインストールし、サーバーでTLS/SSL接続を構成します。また、Concourseサーバーを適切に保護するには、Concourseサーバーを指すドメイン名が必要です。

これらの前提条件に従うと、Concourseサーバーがポート8080で動作するようになります。さらに、Nginxはポート80と443で稼働します。ポート80へのトラフィックはポート443にリダイレクトされ、サーバーのドメイン名へのリクエストのトラフィックが暗号化されます。

始める準備ができたら、以下に進みます。

NginxをConcourseのリバースプロキシとして構成する

最初に行う必要があるのは、SSLサーバーブロックファイルを変更して、トラフィックをConcourseCIサーバーにルーティングすることです。

編集する正しいファイルを見つける

SSLで保護されたドメイン名でConcourseインターフェースを提供する必要があるため、現在ドメイン名を処理しているサーバーブロックファイルを見つける必要があります。アクティブなサーバーブロックのみに関心があるため、grepを使用して/etc/nginx/sites-enabledディレクトリ内を検索できます。

grep -R server_name /etc/nginx/sites-enabled

おそらく次のようなものが表示されます。

Output
/etc/nginx/sites-enabled/default:   server_name example.com;
/etc/nginx/sites-enabled/default:   return 301 https://$server_name$request_uri;
/etc/nginx/sites-enabled/default:   server_name example.com;
/etc/nginx/sites-enabled/default:#  server_name example.com;

上記の出力では、ドメイン名（この場合はexample.com）が/etc/nginx/sites-enabled/defaultファイル内で定義されています。ドメイン名に関連付けられているファイル（最初の列）を編集する必要があります。

次のようなものも表示される可能性があります。

Output/etc/nginx/sites-enabled/default:   server_name _;
/etc/nginx/sites-enabled/default:   return 301 https://$server_name$request_uri;
/etc/nginx/sites-enabled/default:   server_name _;
/etc/nginx/sites-enabled/default:#  server_name example.com;

通常、上記の出力にあるserver_name _;は、一致しない要求に一致するサーバーブロック定義です。ドメイン名に一致するserver_name定義が見つからない場合は、代わりにそのようなファイルを使用する必要があります。

コンコースサーバーブロックを定義する

ドメインを定義するファイルをテキストエディタで開き、開始します。

sudo nano /etc/nginx/sites-enabled/default

簡潔にするためにコメントを削除すると、前提条件セクションのチュートリアルに正しく従った場合、ファイルは次のようになります。

/ etc / nginx / sites-enabled / default

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    include snippets/ssl-example.com.conf;
    include snippets/ssl-params.conf;

    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;

    server_name example.com;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ /.well-known {
        allow all;
    }
}

わずかな違いがあるかもしれませんが、これはファイルの一般的な構造である必要があります。 2つの重要な編集を行うことで、これをConcourseサーバーへのプロキシに適合させることができます。

まず、ファイルの最初のserverブロックの前に、 concourseというupstreamブロックを作成します。これは、ConcourseWebプロセスが接続を受け入れる方法を定義します。継続的インテグレーションサーバーは、ポート8080で接続を受け入れます。

次に、文字列listen 443を持つブロックを探して、SSLコンテンツの提供を担当するサーバーブロックを見つけます。そのブロックで定義されているserver_nameがドメイン名と一致することをもう一度確認します（findで検索したときにドメイン名と一致する結果が見つからなかった場合は、server_name _;に設定されます） ]）。

このサーバーブロック内で、location /ブロックを調整して、Nginxがすべてのリクエスト（他の場所で明示的に定義されていない）をConcourseサーバーに渡すようにする必要があります。これを行うには、外部ファイルからのパラメーターを含め、いくつかの追加パラメーターを設定し、必要なプロキシヘッダーを定義してから、前に定義したupstreamにリクエストを渡します。

location /ブロック内で定義されているtry_filesディレクティブを、次の例の行に置き換えます。完了すると、完成したファイルは次のようになります。

/ etc / nginx / sites-enabled / default

upstream concourse {
        server 127.0.0.1:8080;
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    include snippets/ssl-example.com.conf;
    include snippets/ssl-params.conf;

    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;

    server_name example.com;

    location / {
        include proxy_params;
        proxy_http_version 1.1;
        proxy_read_timeout 90;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_pass http://concourse;
    }

    location ~ /.well-known {
        allow all;
    }
}

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

新しい構成をテストしてアクティブ化する

新しい構成を使用する前に、Nginxに次のように入力して構文エラーをチェックさせます。

sudo nginx -t

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

上記の成功メッセージの代わりにエラーメッセージが表示された場合は、編集したファイルに戻って間違いがないか確認してから続行してください。

新しい構成を実装するには、Nginxを再起動します。

sudo systemctl restart nginx

Nginxは、ドメイン名のリクエストをConcourseサーバーに転送するように構成されました。

ローカルループバックインターフェイスにバインドするようにConcourseを設定する

NginxがトラフィックをConcourseサーバーに転送するように設定されたので、Concourseが接続を受け入れる場所を制限する必要があります。現在、Concourseはすべてのインターフェースでポート8080への接続を受け入れるため、ユーザーは統合サーバーに直接接続することでSSL暗号化をバイパスできます。

Concourse Web構成を変更することにより、この動作を変更できます。テキストエディタで/etc/concourse/web_environmentに作成したwebプロセスの構成ファイルを開きます。

sudo nano /etc/concourse/web_environment

CONCOURSE_EXTERNAL_URLパラメーターを見つけて、ユーザーがConcourseWebインターフェースにアクセスするために使用する必要があるURLを反映するように変更します。これには、https://で指定されたプロトコルと、それに続くドメイン名が含まれます。

その後、CONCOURSE_BIND_IPという新しい環境変数を127.0.0.1に設定します。デフォルトでは、Concourseはすべてのインターフェースをリッスンしますが、この設定はConcourseにローカルインターフェースにのみバインドするように指示します。リモート接続は、SSLを適用できるNginxを介してプロキシする必要があります。

/ etc / concourse / web_environment

. . .
CONCOURSE_EXTERNAL_URL=https://example.com
CONCOURSE_BIND_IP=127.0.0.1

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

Concourse webプロセスを再起動して、新しい設定の使用を開始します。

sudo systemctl restart concourse-web

次のように入力して、Concoursewebインターフェイスがローカルループバックインターフェイスのみをリッスンしていることを確認します。

sudo netstat -plunt | grep 8080

Output
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      20932/concourse

上記の出力は、Concoursewebプロセスがローカルインターフェイスでのみリッスンしていることを示しています。

これで、ファイアウォール設定を変更して、ポート8080の例外を削除できます。これは、すべての外部リクエストがNginxを介してルーティングされるためです。

sudo ufw delete allow 8080

secondary_label Output]
Rule deleted
Rule deleted (v6)

これで、Webインターフェイスに安全にログインできます。

Webインターフェイスのテスト

選択したWebブラウザーで、サーバーのドメイン名にアクセスします。

https://example.com

最初のConcourseCIページにアクセスできるはずです。

Concourse CI initial screen

ブラウザのアドレスバーを見ると、安全な接続を介して統合サーバーに接続していることがわかります。

Concourse CI secured connection

Nginxはブラウザとの接続を保護し、リクエストをConcourseに渡します。安全に接続できるようになったので、Webインターフェイスに安全にログインできます。

右上隅にあるloginリンクをクリックすると、Webインターフェイスにログインできます。まず、チームを選択するように求められます。管理グループであるmainチームは、デフォルトで使用可能な唯一の選択です。

Concourse CI select main team

次のページで、クレデンシャルを入力するように求められます。

web_environmentファイル内で構成した資格情報を入力すると、ログインしてデフォルトのプレースホルダーインターフェイスに戻ります。

Concourse CI select main team

flyを使用してパイプライン構成をサーバーに送信すると、この画面は、パイプラインアクティビティを監視できるインターフェイスに置き換えられます。

結論

このガイドでは、NginxをConcourseCIサーバーの安全なリバースプロキシとして構成しました。 Nginxはクライアントからの安全な接続を受け入れ、リクエストをConcourseサーバーに転送します。 Concourseはローカルループバックインターフェイスにバインドするため、リモートクライアントは直接接続できません。

Concourseサーバーに安全に接続できるようになったので、flyツールとWebインターフェイスを使用してパイプラインの構築と管理を開始できます。次のガイドに従って、継続的インテグレーションパイプラインを開発および実装する方法を学び、プロジェクトの自動テストプロセスを設定できます。 Concourseドキュメントの「helloworld」の例も確認してください。

getdocs

13036