サービスの監査ポリシーの構成

監査ポリシーを使用すると、Anthos Service Mesh 内のサービスへのデータアクセスを監査できます。サービスの監査は、「誰がいつ何をしたか、場合によってはその理由」を調べるのに有用です。監査ポリシーでは、監査ログが作成されるタイミングとログのコンテンツを指定できます。このガイドでは、監査ポリシーを使用できるように、Anthos Service Mesh をインストールする方法について説明します。

監査ログは Google Cloud コンソールの Cloud Logging ログ エクスプローラで表示されるため、監査ポリシーがサポートされるのは以下のプラットフォームに限られます。

  • Google Cloud 上の GKE
  • GKE on VMware
  • Google Distributed Cloud Virtual for Bare Metal

監査ポリシーは、AUDIT アクションを追加することで、AuthorizationPolicy を拡張します。これは、対象ポリシーの範囲（ワークロード、名前空間、またはメッシュ全体）でのみ有効になります。ポリシーは ORed されます。つまり、いずれかのポリシーが当てはまると、リクエストがログに記録されます。特定のワークロードに監査ポリシーが適用されていない場合、そのワークロードの監査ログは生成されません。

myapi の /user/profile/* パスに対するすべての WRITE アクセスを監査する監査ポリシーの例を次に示します。

  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    namespace: ns1
    name: anyname
  spec:
    selector:
      matchLabels:
        app: myapi
    action: AUDIT
    rules:
    - to:
      - operation:
          methods: ["POST", "UPDATE", "DELETE"]
          paths: ["/user/profile/*"]

制限事項

  • Ingress ゲートウェイに監査ログはありません。
  • 監査コンテンツは構成できません。
  • 現在、Anthos Service Mesh の監査ログは、通常のアクセスログと同じ信頼性プロパティを持ちます。たとえば、ワークロード Pod を再起動すると、ワークロードの監査ログの一部が、永続化されていない場合、失われる可能性があります。

始める前に

スタートガイドの手順に沿って、以下を行ってください。

ゲートウェイ構成を準備する

Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。

デフォルトでは、asmcli は istio-ingressgateway をインストールしません。コントロール プレーンとゲートウェイを個別にデプロイして管理することをおすすめします。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。クラスタ内コントロール プレーンにデフォルトの istio-ingressgateway をインストールする必要がある場合は、--option legacy-default-ingressgateway 引数を指定します。

Anthos Service Mesh インストールのカスタマイズ

監査ポリシーを使用するには、Anthos Service Mesh インストールをカスタマイズします。

インストール

  1. Anthos Service Mesh をインストールするの手順を行います。asmcli install の実行時に、次のオプションを指定します。

    --option audit-authorizationpolicy

    次に例を示します。

    ./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --ca mesh_ca \
  --output_dir DIR_PATH  \
  --enable_all \
  --option audit-authorizationpolicy

    Anthos Service Mesh を構成する必要のある他のオーバーレイ ファイルを指定してください。

  2. Anthos Service Mesh のインストールを完了して、ワークロードの自動サイドカー プロキシ インジェクションを有効にします。ワークロードのデプロイと再デプロイをご覧ください。

アップグレード

  1. Anthos Service Mesh をアップグレードするの手順を行います。asmcli install の実行時に、次のオプションを指定します。

    --option audit-authorizationpolicy

    次に例を示します。

    ./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --ca mesh_ca \
  --output_dir DIR_PATH  \
  --enable_all \
  --option audit-authorizationpolicy

    Anthos Service Mesh を構成する必要のある他のオーバーレイ ファイルを指定してください。

  2. Anthos Service Mesh のインストールを完了して、ワークロードの自動サイドカー プロキシ インジェクションを有効にします。詳細については、新しいコントロール プレーンに切り替えるをご覧ください。

監査ロギングの使用

このセクションでは、Bookinfo サンプルを使用して、監査ロギングの使用方法を説明します。

  1. Bookinfo サンプル アプリケーションをデフォルトの名前空間にデプロイします。

  2. Ingress ゲートウェイの外部 IP アドレスを取得し、サンプル アプリケーションにリクエストを送信してトラフィックを生成します。

  3. Google Cloud コンソールでナビゲーション メニュー に移動し、[ロギング] > [ログ エクスプローラ] を選択します。

    ログ エクスプローラに移動

  4. Google Cloud プロジェクトを選択します。

  5. まだ監査ポリシーがデプロイされていないため、監査ログはありません。なお、監査ログはアクセスログとは異なります。stackdriver アクセスログを表示するには、[クエリビルダー] フィールドに次のクエリを入力して、[クエリを実行] をクリックします。

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"

    ログ エクスプローラの使用方法の詳細については、ログ エクスプローラの概要をご覧ください。

監査ポリシーの構成と監査ログの確認

このセクションでは、Bookinfo アプリケーションを監査するためのいくつかのオプションを提示します。監査ポリシーをデプロイすると、いくつかのリクエストを送信した後、ログ エクスプローラで監査ログを確認できます。

  1. 次のコマンドを入力して、クラスタを操作する認証情報を取得します。このコマンドは、クラスタに対して kubectl の現在のコンテキストも設定します。

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

  2. 次の監査ポリシーを適用して、/productpage パスに対する GET リクエストを監査します。

    kubectl apply -f - << EOF
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "audit-productpage"
  namespace: default
spec:
  action: AUDIT
  rules:
  - to:
    - operation:
        methods: ["GET"]
        paths: ["/productpage"]
EOF

  3. Bookinfo にリクエストをいくつか送信します。

  4. ログ エクスプローラで [クエリビルダー] フィールドに次のクエリを入力し、[クエリを実行] をクリックします。

    logName="projects/PROJECT_ID/logs/server-istio-audit-log"

    このクエリにより、次のようなログが返されます。

    画像

  5. 次のポリシーを適用して、bookinfo-ratings サービスに対するリクエストを監査します。この監査ポリシーは追加型です。以下のポリシーを適用すると、ProductPage と Ratings の両方に対するリクエストの監査ログが表示されます。

    kubectl apply -f - << EOF
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "audit-ratings"
  namespace: default
spec:
  action: AUDIT
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
    to:
    - operation:
        methods: ["GET"]
EOF

    新しい監査ポリシーは、有効にする前に、最初に反映させる必要があります。

  6. 10 件以上のリクエストを Bookinfo に送信して、評価サービスがヒットしたことを確認してから、ログ エクスプローラで監査ログを確認します。監査ログは次のようになります。

    画像

  7. 次のポリシーを適用して、デフォルトの名前空間内のすべてのサービスを監査するようにします。

    kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  namespace: default
  name: "audit-all"
spec:
  action: AUDIT
  rules:
    - {}
EOF

  8. さらに Bookinfo にリクエストを送信し、ログ エクスプローラで監査ログを確認します。これで、すべてのリクエストが監査ログに記録されるようになります。

    画像

  9. 監査ポリシーを ProductPage と Ratings に制限しておく場合は、audit-all ポリシーを削除します。

    kubectl delete authorizationpolicy audit-all -n default

トラブルシューティング

監査ポリシーを有効にしても監査ログが表示されない場合は、次の点を確認してください。

  1. ログ エクスプローラで指定された期間のトラフィックがあることを確認します。Bookinfo を使用してテストしている場合は、次のコマンドを数回実行することでリクエストを送信できます。

    curl -s http://EXTERNAL_IP/productpage | grep Bookstore

  2. Ingress ゲートウェイに、監査対象のサービスに対するリクエストをブロックする AuthorizationPolicy があるかどうかを確認します。

  3. ログ エクスプローラの次のフィルタで stackdriver アクセスログを調べて、リクエストがアプリケーションに到達したかどうかを確認します。

    logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"

    画像

  4. Stackdriver が構成され、監査ログが有効になっていることを確認するには、現在の istiod 状態の構成をダンプします。config_dump で enable_audit_log と監査ポリシーの名前を検索します。

    istioctl dashboard envoy POD_NAME.NAMESPACE

    画像 画像 画像

  5. リクエストが監査ポリシールールに一致することを確認するには、ロールベースのアクセス制御（RBAC）のデバッグログを確認します。次のコマンドを使用して、RBAC デバッグ ロギングを有効にします。

    kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'

  6. リクエストを送信し、kubectl logs コマンドを使用して Pod のログを確認します。

    kubectl logs POD_NAME -n NAMESPACE -c istio-proxy

次のステップ