9. プロキシーのサポート¶

プロキシーサーバーは、リソースを別のサーバーから求めているクライアントが出した要求を仲介する役割を果たします。クライアントは、プロキシーサーバーに接続して、別のサーバーからサービスや利用可能なリソースを要求します。そして、このプロキシーサーバーは複雑な内容を簡素化して制御する方法の 1 つとして、その要求を評価します。

注釈

SSL オフロード、または Tower 向けの SSL を処理するプロキシーの使用はサポートされています。プロキシー/ロードバランサーはリモートのホスト情報を渡すように設定しておく必要があります。

SSL をロードバランサーまたはプロキシーにオフロードする場合は、nginx_disable_https=true を追加変数として設定して、設定 Playbook に渡す必要があります。設定 Playbook に追加変数を適用する方法は「um_setup_playbook」を参照してください。

Tower のセッションは、作成時に IP アドレスと関連付けられます。Tower ポリシーでは、セッションを使用する場合には、セッションと、元に関連付けられた IP アドレスと一致することが要件となっています。

プロキシーサーバーをサポートできるように、Tower の設定ユーザーインターフェースにある REMOTE_HOST_HEADERS 一覧の変数を使用して、Tower はプロキシー化された要求 (Tower、HAProxy、Squid、tinyproxy の前の ELB など) を処理します。Ansible Tower 3.2 以前では、この設定は、remote_host_headers.py ファイルで設定していましたが、このファイルは Tower のインストールで提供されなくなりました。

_images/configure-tower-system-proxy.png

デフォルトでは REMOTE_HOST_HEADERS は REMOTE_ADDR, REMOTE_HOST に設定されています。プロキシーサーバーのサポートを有効にするには、REMOTE_HOST_HEADERS = HTTP_X_FORWARDED_FOR, REMOTE_ADDR, REMOTE_HOST のように、REMOTE_HOST_HEADERS パラメーターを単純なコンマ区切りの文字列で定義する必要があります。

Tower はリモートホストの IP アドレスを判断するために、最初の IP アドレスが特定されるまで、REMOTE_HOST_HEADERS のヘッダー一覧を検索します。

注釈

ヘッダー名は、以下のロジックを使用して作成されます。

CONTENT_LENGTH と CONTENT_TYPE の例外を除いて、要求内の HTTP ヘッダーは META キーに変換されます。これは、すべての文字を大文字に変換して、ハイフンはアンダースコアに置き換え、名前に HTTP_ のプリフィックスを追加することで変換されます。たとえば、X-Barkley と呼ばれるヘッダーは META キー HTTP_X_Barkley にマッピングされます。

HTTP 要求および応答オブジェクトに関する情報は、https://docs.djangoproject.com/en/1.8/ref/request-response/#django.http.HttpRequest.META を参照してください。

注釈

ロードバランサーで SSL 中断を使用して、Tower ノードの別のポート (443 -> 80) にトラフィックを転送する場合は /etc/tower/settings.py ファイルに適切に以下の値を設定します。

USE_X_FORWARDED_PORT = True
USE_X_FORWARDED_HOST = True

9.1. 既知のプロキシーの設定¶

Tower が REMOTE_HOST_HEADERS = HTTP_X_FORWARDED_FOR, REMOTE_ADDR, REMOTE_HOST で設定された場合には、X-Forwarded-For の値は Tower の前にあるプロキシー/ロードバランサーから取得していると想定されます。Tower にプロキシー/ロードバランサーを使用せずに到達できる場合や、プロキシーがヘッダーを検証しない場合には、X-Forwarded-For は比較的簡単になりすましを行い、送信元の IP アドレスを偽造することができます。REMOTE_HOST_HEADERS 設定で HTTP_X_FORWARDED_FOR を使用すると、アクセスすべきでない特定のリソースにも基本的にアクセス権を与えるので、攻撃を受けやすくなります。

これを回避するには、許可済みの「既知のプロキシー」を設定してください。これは、設定 API 経由で PROXY_IP_WHITELIST 設定で行います。この一覧に記載されていないロードバランサーやホストは拒否要求に追加されることになります。

PROXY_IP_WHITELIST は、この一覧のプロキシーが正しくヘッダー入力をサニタイズし、X-Forwarded-For の値をクライアントの実際のソース IP と同等に正しく設定した場合にのみ機能します。この設定で重要な点は、Tower が PROXY_IP_WHITELIST 内の IP/ホスト名に依存して、X-Forwarded-For フィールドに攻撃を受けない値を指定することができる点です。

HTTP_X_FORWARDED_FOR は、以下の点が満たされていない限り、REMOTE_HOST_HEADERS の項目として設定 しない ようにしてください。

SSL Termination でプロキシー環境を使用している

プロキシーにより X-Forwarded-For ヘッダーのサニタイズおよび検証が行われクライアントの攻撃を防止することができる

信頼されたプロキシー/ロードバランサーの送信元 IP のみを含む PROXY_IP_WHITELIST

注釈

すべてのトラフィックをプロキシー経由とする必要がない場合には、no_proxy フィールドで除外する IP スキームを指定できます。一覧は、IP の範囲、個別の IP をコンマ区切りで指定できます。この例では、JSON 形式の IP を指定しています。

"https_proxy": "example.proxy.com:8080",
"http_proxy": "example.proxy.com:8080",
"no_proxy": "10.0.0.0/8"

9.2. リバースプロキシー¶

リバースプロキシーの背後に環境がある場合には、HTTP_X_FORWARDED_FOR のヘッダーフィールドを設定するようにしてください。X-Forwarded-For (XFF) HTTP ヘッダーフィールドで、HTTP プロキシーまたはロードバランサー経由で Web サーバーに接続するクライアントの送信元 IP アドレスを指定します。

REMOTE_HOST_HEADERS = HTTP_X_FORWARDED_FOR, REMOTE_ADDR, REMOTE_HOST

注釈

プロキシーが設定されていて通知が機能しない場合には、ナレッジベース記事「 How do I Use Ansible Tower Notifications from Behind a Proxy? 」を参照してください。