すべてのプロダクト
Search
ドキュメントセンター

:レイヤー 4 認証と認可

最終更新日:Jan 13, 2025

Ambient Mesh モードにおける認証と認可の構成モデルは、レイヤー 4 とレイヤー 7 が分離されているため、元の Sidecar モードとは異なります。このトピックでは、v1.18 の Service Mesh(ASM)インスタンスでレイヤー 4 認可ポリシーを使用する方法について説明します。

前提条件

イングレスゲートウェイと関連アプリケーションがデプロイされ、基本機能が検証されていること。詳細については、「はじめに」の前提条件とステップ 1 をご参照ください。

制限事項

  • ztunnel の認可ポリシーには、次の制限が適用されます。

    • action フィールドを CUSTOM に設定することはできません。これは、ztunnel がカスタム認可サービスをサポートしていないことを示します。

    • source フィールドでは、requestPrincipals フィールドと remoteIpBlocks フィールドはサポートされていません。

    • operation フィールドでは、ports フィールドのみがサポートされています。

  • ウェイポイントプロキシがデプロイされていない場合、認可ポリシーは ztunnel によって適用されます。この場合、認可ポリシーは指定されたワークロードにバインドされている必要があります。

  • ztunnel はレイヤー 4 プロキシです。ztunnel でレイヤー 7 ルールを含む認可ポリシーを構成した場合、レイヤー 4 ルールのみが有効になります。

例 1:ゲートウェイと sleep アプリケーションのみが productpage サービスにアクセスできるようにする

この例では、ztunnel が principals に基づいて正しく認可を実行できるかどうかを検証します。詳細については、「はじめに」をご参照ください。

テストが完了したら、次のコマンドを実行して認可ポリシーを削除します。

kubectl delete authorizationpolicy productpage-viewer

例 2:productpage サービスのポート 9080 へのアクセスを禁止する

この例では、主に ztunnel が宛先ポートに基づいて正しく認可を実行できるかどうかを検証します。

  1. 次の内容を使用して、productpage-viewer.yaml ファイルを作成します。

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
     name: productpage-viewer
     namespace: default
    spec:
     selector:
       matchLabels:
         app: productpage
     action: DENY
     rules:
     - to:
       - operation:
           ports:
           - "9080"
    // YAML ファイルの内容
  2. kubeconfig ファイルの情報に基づいて kubectl を使用して ASM インスタンスに接続し、次のコマンドを実行して認可ポリシーを作成します。

    kubectl apply -f productpage-viewer.yaml
  3. 認可ポリシーが有効になっているかどうかを確認します。

    1. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"

      予期される出力:

      upstream connect error or disconnect/reset before headers. reset reason: connection termination%
    2. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"

      予期される出力:

      upstream connect error or disconnect/reset before headers. reset reason: connection termination%
    3. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/sleep -- curl -s http://productpage:9080/

      予期される出力:

      command terminated with exit code 56
    4. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      予期される出力:

      command terminated with exit code 56

      出力は、すべてのポッドが productpage サービスのポート 9080 にアクセスできないことを示しています。

      最初の 2 つのテストでは、ゲートウェイを介して productpage サービスにアクセスするリクエストへのレスポンスで upstream connect error or disconnect/reset before headers. reset reason: connection termination% エラーが報告されます。このエラーは実際にはイングレスゲートウェイによって返されます。ゲートウェイが productpage サービスにアクセスできない場合(productpage サービスがイングレスゲートウェイによる 9080 ポートへのアクセスを許可していない場合)、HTTP 503 エラーが報告されます。

      最後の 2 つのテストのレスポンスは command terminated with exit code 56 で、これは curl コマンドによって返されます。curl コマンドは productpage サービスとの接続を直接確立しようとしますが、接続の確立に失敗します。そのため、HTTP エラーは報告されません。これは、ゲートウェイを介した直接アクセスのエラーとは異なります。

  4. 次のコマンドを実行して認可ポリシーを削除します。

    kubectl delete authorizationpolicy productpage-viewer

例 3:sleep ポッドの IP アドレスが productpage サービスにアクセスすることを禁止する

この例では、主に ztunnel が送信元 IP アドレスに基づいて正しく認可を実行できるかどうかを検証します。

  1. 次のコマンドを実行して、sleep ポッドの IP アドレスをクエリします。

    kubectl get pod -o wide | grep sleep

    予期される出力:

    notsleep-5fb85fb789-z****         1/1     Running   0          48m   10.0.67.92   cn-hangzhou.10.0.67.41   <none>           <none>
    sleep-bc9998558-z****             1/1     Running   0          48m   10.0.67.91   cn-hangzhou.10.0.67.42   <none>           <none>

    予期される出力は、現在のテスト環境における sleep ポッドの IP アドレスが 10.0.67.91 であることを示しています。各環境の実際のポッド IP アドレスは異なる場合があります。

  2. 次の内容を使用して、sleep ポッドの IP アドレスからのリクエストが productpage サービスにアクセスすることを禁止する productpage-viewer.yaml ファイルを作成します。

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
     name: productpage-viewer
     namespace: default
    spec:
     selector:
       matchLabels:
         app: productpage
     action: DENY
     rules:
     - from:
       - source:
           ipBlocks:
           - ${sleep Pod IP}
    // sleep ポッドの IP アドレス
  3. kubeconfig ファイルの情報に基づいて kubectl を使用して ASM インスタンスに接続し、次のコマンドを実行して認可ポリシーを作成します。

    kubectl apply -f productpage-viewer.yaml
  4. 認可ポリシーが有効になっているかどうかを確認します。

    1. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"

      予期される出力:

      <title>Simple Bookstore App</title>
    2. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"

      予期される出力:

      <title>Simple Bookstore App</title>
    3. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/sleep -- curl -s http://productpage:9080/

      予期される出力:

      command terminated with exit code 56
    4. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      予期される出力:

      <title>Simple Bookstore App</title>

      出力は、ztunnel のみをデプロイし、ウェイポイントプロキシをデプロイしない場合、ゲートウェイを介した sleep ポッドから productpage サービスへのアクセスを禁止できないことを示しています。これは、認可ポリシーの remoteIpBlocks フィールドがリクエストの X-Forwarded-For ヘッダーに依存しているためですが、ztunnel はレイヤー 4 プロキシです。

  5. 次のコマンドを実行して認可ポリシーを削除します。

    kubectl delete authorizationpolicy productpage-viewer

例 4:istio-system ネームスペースのポッドが productpage サービスにアクセスすることを禁止する

この例では、主に ztunnel が送信元ネームスペースに基づいて正しく認可を実行できるかどうかを検証します。送信元ネームスペースとは、ポッドがリクエストを開始するネームスペースのことです。

  1. 次の内容を使用して、istio-system ネームスペースのポッドが productpage サービスにアクセスすることを禁止する productpage-viewer.yaml ファイルを作成します。

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
     name: productpage-viewer
     namespace: default
    spec:
     selector:
       matchLabels:
         app: productpage
     action: DENY
     rules:
     - from:
       - source:
           namespaces:
           - istio-system
    // istio-system ネームスペース
  2. kubeconfig ファイルの情報に基づいて kubectl を使用して ASM インスタンスに接続し、次のコマンドを実行して認可ポリシーを作成します。

    kubectl apply -f productpage-viewer.yaml
  3. 認可ポリシーが有効になっているかどうかを確認します。

    1. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"

      予期される出力:

      upstream connect error or disconnect/reset before headers. reset reason: connection termination%
    2. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"

      予期される出力:

      upstream connect error or disconnect/reset before headers. reset reason: connection termination%
    3. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      予期される出力:

      <title>Simple Bookstore App</title>
    4. 次のコマンドを実行してアクセステストを実行します。

      kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      予期される出力:

      <title>Simple Bookstore App</title>

      イングレスゲートウェイは istio-system ネームスペースにデプロイされています。出力は、認可ポリシーが作成された後、sleep アプリケーションと notsleep アプリケーションはゲートウェイを介して productpage サービスにアクセスできませんが、productpage サービスに直接アクセスできることを示しています。

  4. 次のコマンドを実行して認可ポリシーを削除します。

    kubectl delete authorizationpolicy productpage-viewer