Alibaba Cloud Service Mesh:ASMインスタンス内のアプリケーションへの特定のIPアドレスからのアクセスを制限する

前提条件

• v1.15.3.25以降のASMインスタンスにクラスタが追加されています。詳細については、ASMインスタンスへのクラスタの追加をご参照ください。

• 自動サイドカープロキシインジェクションが有効になっています。詳細については、自動サイドカープロキシインジェクションの有効化をご参照ください。

• HTTPBinアプリケーションがデプロイされ、アクセス可能です。詳細については、HTTPBinアプリケーションのデプロイをご参照ください。

使用上の注意

この例では、ゲートウェイの externalTrafficPolicy フィールドは Local に設定されています。externalTrafficPolicy フィールドが Cluster に設定されている場合、送信元 IP アドレスは保持されません。

シナリオ 1：ASMインスタンス内のアプリケーションにアクセスするためのリクエストを開始するクライアントとASMゲートウェイの間にレイヤー 7 プロキシがデプロイされていない

次のコマンドを実行して HTTPBin アプリケーションにアクセスします。

curl 47.111.XXX.XX:80/ -I

{
    "authority_for": "47.111.XXX.XX",
    "bytes_received": "0",
    "bytes_sent": "0",
    "downstream_local_address": "10.0.70.17:80",
    "downstream_remote_address": "106.XX.XX.1:58656",
    "duration": "2",
    "istio_policy_status": "-",
    "method": "HEAD",
    "path": "/",
    "protocol": "HTTP/1.1",
    "request_id": "b1aa0770-4f64-4798-894a-4a04a0ba****",
    "requested_server_name": "-",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "httpbin",
    "start_time": "2023-08-31T06:42:47.380Z",
    "trace_id": "-",
    "upstream_cluster": "outbound|8000||httpbin.default.svc.cluster.local",
    "upstream_host": "10.0.70.85:80",
    "upstream_local_address": "10.0.70.17:56110",
    "upstream_response_time": "2",
    "upstream_service_time": "2",
    "upstream_transport_failure_reason": "-",
    "user_agent": "curl/7.88.1",
    "x_forwarded_for": "106.11.XX.X"
}

クライアントの実際の IP アドレスは 106.11.XX.X です。ゲートウェイログの downstream_remote_address フィールドと x_forwarded_for フィールドの値が正しいことがわかります。この場合、ゲートウェイの ipBlocks と remoteIpBlocks の設定が有効になります。

{
    "authority_for": "47.111.XXX.XX",
    "bytes_received": "0",
    "bytes_sent": "0",
    "downstream_local_address": "10.0.70.91:80",
    "downstream_remote_address": "106.11.XX.X:0",
    "duration": "1",
    "istio_policy_status": "-",
    "method": "HEAD",
    "path": "/",
    "protocol": "HTTP/1.1",
    "request_id": "20c94846-3e12-458a-b7d5-88ac867f****",
    "requested_server_name": "outbound_.8000_._.httpbin.default.svc.cluster.local",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "default",
    "start_time": "2023-08-31T10:06:33.809Z",
    "trace_id": "-",
    "upstream_cluster": "inbound|80||",
    "upstream_host": "10.0.70.91:80",
    "upstream_local_address": "127.0.X.X:43247",
    "upstream_response_time": "1",
    "upstream_service_time": "1",
    "upstream_transport_failure_reason": "-",
    "user_agent": "curl/7.88.1",
    "x_forwarded_for": "106.11.XX.X"
}

サイドカープロキシのアクセスログの x_forwarded_for フィールドの値がクライアントの実際の IP アドレスであることがわかります。downstream_remote_address フィールドの値もクライアントの実際の IP アドレスですが、ポート情報が失われ、0 と表示されます。

例 1：ゲートウェイでブラックリストまたはホワイトリストを設定する

例 2：サイドカープロキシでブラックリストまたはホワイトリストを設定する

シナリオ 2：ASMインスタンス内のアプリケーションにアクセスするためのリクエストを開始するクライアントとASMゲートウェイの間にレイヤー 7 プロキシがデプロイされている

このシナリオでは、ASM ゲートウェイが受信するリクエストの x_forwarded_for リクエストヘッダーには、レイヤー 7 プロキシによって追加されるデフォルト値が必要です。

{
    "authority_for": "47.111.XXX.XX",
    "bytes_received": "0",
    "bytes_sent": "0",
    "downstream_local_address": "10.0.70.17:80",
    "downstream_remote_address": "106.11.XX.X:62232",
    "duration": "4",
    "istio_policy_status": "-",
    "method": "HEAD",
    "path": "/",
    "protocol": "HTTP/1.1",
    "request_id": "4f8ee609-1479-4f75-ba9d-4fa6d646****",
    "requested_server_name": "-",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "httpbin",
    "start_time": "2023-08-31T11:25:11.376Z",
    "trace_id": "-",
    "upstream_cluster": "outbound|8000||httpbin.default.svc.cluster.local",
    "upstream_host": "10.0.70.91:80",
    "upstream_local_address": "10.0.70.17:42646",
    "upstream_response_time": "4",
    "upstream_service_time": "4",
    "upstream_transport_failure_reason": "-",
    "user_agent": "curl/7.88.1",
    "x_forwarded_for": "56.5.X.X, 72.9.X.X, 98.1.X.X,106.11.XX.X"
}

リクエストが ASM ゲートウェイに到達する前に、x_forwarded_for リクエストヘッダーの値は 56.5.X.X, 72.9.X.X, 98.1.X.X である必要があります。最後の IP アドレス 106.11.XX.X は、ASM ゲートウェイによって追加されます。downstream_remote_address は、ゲートウェイに直接接続するピアエンドの IP アドレスを示します。この場合、これは物理 IP アドレスであり、有効なポートが含まれています。

{
    "authority_for": "47.111.XXX.XX",
    "bytes_received": "0",
    "bytes_sent": "0",
    "downstream_local_address": "10.0.70.91:80",
    "downstream_remote_address": "106.11.XX.X:0",
    "duration": "1",
    "istio_policy_status": "-",
    "method": "HEAD",
    "path": "/",
    "protocol": "HTTP/1.1",
    "request_id": "4f8ee609-1479-4f75-ba9d-4fa6d646****",
    "requested_server_name": "outbound_.8000_._.httpbin.default.svc.cluster.local",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "default",
    "start_time": "2023-08-31T11:25:11.378Z",
    "trace_id": "-",
    "upstream_cluster": "inbound|80||",
    "upstream_host": "10.0.70.91:80",
    "upstream_local_address": "127.0.X.X:34607",
    "upstream_response_time": "1",
    "upstream_service_time": "1",
    "upstream_transport_failure_reason": "-",
    "user_agent": "curl/7.88.1",
    "x_forwarded_for": "56.5.X.X, 72.9.X.X, 98.1.X.X,106.11.XX.X"
}

サイドカープロキシのログは、x_forwarded_for リクエストヘッダーの値がゲートウェイの値と同じであることを示しています。downstream_remote_address の値は実際の物理アドレスではありません。x_forwarded_for リクエストヘッダーの値の最後の IP アドレスです。（x_forwarded_for フィールドには IP アドレスのみが含まれています。したがって、ここでのポートは 0 です。）

次のセクションでは、ipBlocks フィールド（このフィールドはピアエンドの実際の物理 IP アドレスを示します）はテストしません。remoteIpBlocks フィールドのみがテストされます。この場合、x_forwarded_for フィールドを配列として扱う必要があります。ASM ゲートウェイへの IP アドレスからのアクセスを拒否します。前のログの x_forwarded_for の最後の IP アドレスは、ASM ゲートウェイにアクセスすることが許可されていません。

例 1：x_forwarded_for フィールドの最後の IP アドレスに remoteIpBlocks を設定する x_forwarded_for フィールドの最後の IP アドレスまで

1. 次のコンテンツを使用して gateway-test.yaml という名前の承認ポリシーを作成します。

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: gateway-test-ap-wg-gateway-test-istio-system-gateway-ingressgateway
     namespace: istio-system
   spec:
     action: DENY
     rules:
       - from:
           - source:
               remoteIpBlocks:
                 - 106.11.XX.X
     selector:
       matchLabels:
         istio: ingressgateway

2. 次のコマンドを実行して、承認ポリシーをデプロイします。

   kubectl apply -f gateway-test.yaml

3. 次のコマンドを実行して HTTPBin アプリケーションにアクセスします。

   curl 47.111.175.XX:XX/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I

   予期される出力：

   HTTP/1.1 403 Forbidden
   content-length: 19
   content-type: text/plain
   date: Thu, 31 Aug 2023 11:50:36 GMT
   server: istio-envoy

   出力は、x_forwarded_for フィールドの最後の IP アドレスが ASM ゲートウェイにアクセスすることを許可されていないことを示しています。

例 2：イングレスゲートウェイの numTrustedProxies フィールドを 2 に設定する

1. イングレスゲートウェイの YAML ファイルの spec フィールドに次の設定を追加します。イングレスゲートウェイの YAML ファイルの編集方法の詳細については、ASM コンソールでイングレスゲートウェイを管理するをご参照ください。

   podAnnotations:
       proxy.istio.io/config: '{"gatewayTopology" : { "numTrustedProxies": 2 } }'

   説明

   この設定により、ゲートウェイが再起動します。

2. ゲートウェイが再起動した後、次のコマンドを実行して HTTPBin アプリケーションにアクセスします。

   curl 47.111.XXX.XX:80/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I

   予期される出力：

   HTTP/1.1 200 OK
   server: istio-envoy
   date: Thu, 31 Aug 2023 12:10:15 GMT
   content-type: text/html; charset=utf-8
   content-length: 9593
   access-control-allow-origin: *
   access-control-allow-credentials: true
   x-envoy-upstream-service-time: 2

   出力は、アクセスが成功し、numTrustedProxies フィールドの値が remoteIpBlocks フィールドの判断結果に影響を与えることを示しています。

   numTrustedProxies が 2 に設定されている場合、ASM ゲートウェイは自身に最も近い 2 つのプロキシを信頼できるとみなし、3 番目に近いプロキシを信頼できないとみなします。したがって、remoteIpBlocks フィールドは、3 番目に近いプロキシの IP アドレスがゲートウェイにアクセスすることを拒否します。numTrustedProxies が設定されていない場合、デフォルト値は 0 です。

例 3：承認ポリシーを使用して、ゲートウェイログの x_forwarded_for フィールドの最後から 3 番目の IP アドレスからのアクセスを拒否する

1. 次のコンテンツを使用して gateway-test.yaml という名前の承認ポリシーを作成します。

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: gateway-test-ap-wg-gateway-test-istio-system-gateway-ingressgateway
     namespace: istio-system
   spec:
     action: DENY
     rules:
       - from:
           - source:
               remoteIpBlocks:
                 - 72.9.X.X
     selector:
       matchLabels:
         istio: ingressgateway

2. 次のコマンドを実行して、承認ポリシーをデプロイします。

   kubectl apply -f gateway-test.yaml

3. 次のコマンドを実行して HTTPBin アプリケーションにアクセスします。

   curl 47.111.XXX.XX:80/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I

   予期される出力：

   HTTP/1.1 403 Forbidden
   content-length: 19
   content-type: text/plain
   date: Thu, 31 Aug 2023 12:38:09 GMT
   server: istio-envoy

   出力は、x_forwarded_for フィールドで指定された最後から 3 番目の IP アドレスからのアクセスが拒否されたことを示しています。

例 4：上記の承認ポリシーの有効範囲を HTTPBin アプリケーションに変更する

1. 次のコンテンツを使用して gateway-test.yaml という名前の承認ポリシーを作成します。

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: gateway-test
     namespace: default
   spec:
     action: DENY
     rules:
       - from:
           - source:
               remoteIpBlocks:
                 - 72.9.X.X
     selector:
       matchLabels:
         app: httpbin

2. 次のコマンドを実行して、承認ポリシーをデプロイします。

   kubectl apply -f gateway-test.yaml

3. 次のコマンドを実行して HTTPBin アプリケーションにアクセスします。

   curl 47.111.XXX.XX:80/ -H 'X-Forwarded-For: 56.5.X.X, 72.9.X.X, 98.1.X.X' -I

   予期される出力：

   HTTP/1.1 200 OK
   server: istio-envoy
   date: Thu, 31 Aug 2023 12:39:36 GMT
   content-type: text/html; charset=utf-8
   content-length: 9593
   access-control-allow-origin: *
   access-control-allow-credentials: true
   x-envoy-upstream-service-time: 6

   出力は、アクセスが成功し、承認ポリシーが無効であることを示しています。上記の numTrustedProxies フィールドはゲートウェイ用に設定されています。サイドカープロキシの numTrustedProxies のデフォルト値は依然として 0 です。サイドカープロキシは、受信した x_forwarded_for リクエストヘッダーの最後の IP アドレスを確認します。したがって、リクエストは拒否されません。

   承認ポリシーの remoteIpBlocks の値をサイドカープロキシログの x_forwarded_for の最後の IP アドレスに変更すると、アクセスは拒否されます。