認可ポリシーの高度な機能を構成する

Cloud Service Mesh 認可ポリシーを使用すると、メッシュ内のワークロードのアクセスをメッシュレベル、名前空間レベル、ワークロード レベルで制御できます。このページでは、ドライラン モードや拒否ロギングなど、Cloud Service Mesh 認可ポリシーの高度な機能を構成する方法について説明します。このページは、認可ポリシーの概要で説明されている基本的な認可ポリシーのコンセプトを理解していることを前提としています。

ドライラン モード

Cloud Service Mesh 認可ポリシーはドライラン モードをサポートしているため、実際の本番環境のトラフィックに適用しなくてもポリシーのテストを行うことができます。ドライラン モードでは、認可ポリシーの影響を確認してから適用できます。これにより、誤った認可ポリシーで本番環境のトラフィックが中断されるリスクを軽減できます。

ドライラン モードに変更するには、認可ポリシーで "istio.io/dry-run": "true" アノテーションを使用します。

ドライラン モードの例

次の例の deny-path-headers は、dry-run アノテーションが "true に設定されたポリシーを示しています。この認可ポリシーは、パス headers に対するリクエストを拒否し、他のすべてのリクエストを許可します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

ドライラン モードで認可ポリシーを適用すると、Cloud Service Mesh は適用結果を Cloud Logging にロギングしますが、ポリシーの適用は行いません。リクエストは常に許可されます。認可ポリシーが期待どおりに動作しているかどうかはログ エクスプローラで確認できます。

ドライランのロギングの詳細

ドライラン モードで認可ポリシーを適用すると、ログ エクスプローラでポリシーの結果を確認できます。

  1. [ログ エクスプローラ] に移動します。次の URL で、PROJECT_ID をプロジェクト ID に置き換えます。

    https://console.cloud.google.com/logs/query?project=PROJECT_ID

  2. [クエリビルダー] フィールドにクエリを入力して、ドライラン モードの認可ポリシーを検索します。次のクエリでは、NAMESPACE を実際の名前空間に置き換えます。

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"

  3. [実行] をクリックします。

  4. 必要に応じて期間を調整します。

次のスクリーンショットは、サンプルの deny-path-headers ポリシーが適用された後のログ エクスプローラです。トラフィック ログにドライランのラベルが付いています。

画像

ドライラン モードでは、Istio のドライランの結果だけでなく、ALLOW と DENY の認可ポリシーをサポートしています。Cloud Service Mesh は、ドライランの結果を次のラベルで Cloud Logging に保存します。

  • dry_run_result: ドライランの結果は「AuthzAllowed」か「AuthzDenied」のいずれかです。
  • dry_run_policy_name: ドライランの決定を行う、一致した認可ポリシーの名前空間と名前。
  • dry_run_policy_rule: ドライランの決定を行う、一致する認可ポリシールールのインデックス。

次の表に、ドライラン モードで認可ポリシーについて記録された詳細を示します。

ドライラン モードで適用された認可ポリシー 一致結果 ドライランの結果 Cloud Logging
DENY ポリシーのみ 不一致 許可 dry_run_result: 「AuthzAllowed」
一致 不承認 dry_run_result: 「AuthzDenied」
dry_run_result: 。
dry_run_policy_rule:
ALLOW ポリシーのみ 不一致 不承認 dry_run_result: 「AuthzDenied」
一致 許可 dry_run_result: AuthzAllowed
dry_run_policy_name: .
dry_run_policy_rule:
ALLOW ポリシーと DENY ポリシーの両方 どちらも一致していない 不承認 dry_run_result: 「AuthzDenied」
DENY ポリシーのみに一致 不承認 dry_run_result: 「AuthzDenied」
dry_run_result: 。
dry_run_policy_rule:
ALLOW ポリシーのみに一致 許可 dry_run_result: AuthzAllowed
dry_run_policy_name: .
dry_run_policy_rule:
両方のポリシーに一致 不承認 dry_run_result: 「AuthzDenied」
dry_run_result: 。
dry_run_policy_rule:

ドライランの結果に問題がなければ、次のいずれかの方法でドライラン モードを無効にします。

  • ドライランのアノテーションを完全に削除する。

  • ドライランのアノテーションの値を false に変更する。

ドライラン モードを無効にしてポリシーを適用すると、Cloud Service Mesh がポリシーを適用します。

拒否ロギング

ポリシーによってリクエストが許可されていない場合、認可ポリシーがリクエストを拒否します。HTTP（gRPC を含む）プロトコルの場合、リクエストがステータス コード 403 で拒否されます。HTTP 以外のプロトコルの場合、接続は直接終了します。Cloud Logging トラフィック ログには、トラフィックが拒否された理由を調べる際に役立つ追加情報が含まれています。たとえば、認可ポリシーによって拒否されたリクエストの数が表示されます。これにより、バックエンド アプリケーションから拒否された原因となったポリシールールを特定できます。

次の例では、dry-run アノテーションが "false に設定されています。DENY 認可ポリシーを適用すると、Cloud Service Mesh はそのポリシーを適用します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

DENY 認可ポリシーを適用すると、ログ エクスプローラでポリシーの結果を確認できます。

  1. [ログ エクスプローラ] に移動します。次の URL で、PROJECT_ID をプロジェクト ID に置き換えます。

    https://console.cloud.google.com/logs/query?project=PROJECT_ID

  2. [クエリビルダー] フィールドに、DENY 認可ポリシーを探すクエリを入力します。次のクエリで、NAMESPACE は実際の名前空間に置き換えます。

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"

  3. [実行] をクリックします。

  4. 必要に応じて期間を調整します。

次のスクリーンショットは、サンプルの deny-path-headers ポリシーが適用された後にログ エクスプローラで、ログエントリが表示されています。ラベルを確認すると、認可ポリシーが 403 に影響を及ぼしていることがわかります。

画像

ログ エクスプローラのトラフィック ログでは、認可拒否に次のラベルが付いています。

  • response_details: 認可ポリシーによって拒否された場合、「AuthzDenied」に設定されます。
  • policy_name: 拒否の原因となる認証 DENY ポリシーの名前空間と名前が含まれます。値は <Namespace>.<Name> の形式です。たとえば、foo.deny-path-headers は、foo 名前空間にある認証ポリシー deny-path-headers を意味します。
  • policy_rule: 拒否の原因となる認証ポリシー内のルールのインデックスを含めます。たとえば、0 はポリシー内の最初のルールを意味します。

次のステップ

サービス メッシュ内に存在するすべての認可ポリシーの一覧を表示するには、次のコマンドを実行します。

kubectl get authorizationpolicy --all-namespaces

認可ポリシーがすでに適用されている場合は、kubectl delete を使用して削除できます。

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

トラフィック ログの取得方法については、ログにアクセスするをご覧ください。