Ubuntu 16.04でNginxを使用してSSLでコンコースCIを保護する方法

前書き

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

https://www.digitalocean.com/community/tutorials/how-to-install-concourse-ci-on-ubuntu-16-04 [前のチュートリアル]で、Concourse CIインスタンスをインストールして構成する方法を示しましたUbuntu 16.04サーバー。 最終的には、コマンドラインとWebインターフェイスの両方から管理および監視できる継続的な統合サーバーが残されました。

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

前提条件

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

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

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

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

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

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

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

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

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

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;

上記の出力では、ドメイン名(この例では + 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/

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

/ etc / nginx / sites-enabled / default

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

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

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

   server_name ;

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

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

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

まず、ブロックされた + server`の前のファイルの最初に、Concourse Webプロセスが接続を受け入れる方法を定義する* concourse *と呼ばれる + upstream`ブロックを作成します。 継続的統合サーバーは、ポート8080での接続を受け入れます。

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

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

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

/ etc / nginx / sites-enabled / default

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

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

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

   server_name ;

   location / {








   }

   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サーバーに転送するように設定されました。

ローカルループバックインターフェイスにバインドするコンコースの構成

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

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

sudo nano /etc/concourse/web_environment

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

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

/ etc / concourse / web_environment

. . .
CONCOURSE_EXTERNAL_URL=://

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

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

sudo systemctl restart concourse-web

次を入力して、Concourseの「+ web +」インターフェースがローカルループバックインターフェースのみをリッスンしていることを確認します。

sudo netstat -plunt | grep 8080
Outputtcp        0      0           0.0.0.0:*               LISTEN      20932/concourse

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

すべての外部リクエストはNginxを経由するため、ファイアウォール設定を変更してポート8080の例外を削除できます。

sudo ufw delete allow 8080
secondary_label Output]
Rule deleted
Rule deleted (v6)

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

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

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

https://

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

image:https://assets.digitalocean.com/articles/concourseci_ssl_1604/initial_screen.png [Concourse CI初期画面]

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

image:https://assets.digitalocean.com/articles/concourseci_ssl_1604/secure_indicator.png [コンコースCIセキュア接続]

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

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

image:https://assets.digitalocean.com/articles/concourseci_ssl_1604/select_main_team.png [コンコースCIセレクトメインチーム]

次のページで、資格情報の入力を求められます。

`+ web_environment +`ファイル内で設定した認証情報を入力すると、ログインしてデフォルトのプレースホルダーインターフェイスに戻ります。

image:https://assets.digitalocean.com/articles/concourseci_ssl_1604/placeholder_interface.png [Concourse CI select main team]

パイプライン設定を「+ fly +」でサーバーに送信すると、この画面は、パイプラインのアクティビティを監視できるインターフェイスに置き換えられます。

結論

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

Concourseサーバーに安全に接続できるようになったので、 `+ fly +`ツールとWebインターフェースを使用してパイプラインの構築と管理を開始できます。 次のガイドに従って、https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-pipelines-with-concourse-ci-on-ubuntu-16-04 [プロジェクトの自動テストプロセスを設定するための継続的統合パイプラインの開発および実装方法]。 Concourseドキュメントの「hello world」の例もご覧ください。

前の投稿:Linuxの簡単な歴史
次の投稿:CentOS 7にElasticsearch、Logstash、Kibana(Elastic Stack)をインストールする方法