サービスの監査ポリシーの構成
監査ポリシーを使用すると、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
をインストールしません。コントロール プレーンとゲートウェイを個別にデプロイして管理することをおすすめします。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。
Anthos Service Mesh インストールのカスタマイズ
監査ポリシーを使用するには、Anthos Service Mesh インストールをカスタマイズします。
インストール
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 を構成する必要のある他のオーバーレイ ファイルを指定してください。
Anthos Service Mesh のインストールを完了して、ワークロードの自動サイドカー プロキシ インジェクションを有効にします。ワークロードのデプロイと再デプロイをご覧ください。
アップグレード
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 を構成する必要のある他のオーバーレイ ファイルを指定してください。
Anthos Service Mesh のインストールを完了して、ワークロードの自動サイドカー プロキシ インジェクションを有効にします。詳細については、新しいコントロール プレーンに切り替えるをご覧ください。
監査ロギングの使用
このセクションでは、Bookinfo サンプルを使用して、監査ロギングの使用方法を説明します。
Bookinfo サンプル アプリケーションをデフォルトの名前空間にデプロイします。
Ingress ゲートウェイの外部 IP アドレスを取得し、サンプル アプリケーションにリクエストを送信してトラフィックを生成します。
Google Cloud コンソールでナビゲーション メニュー
に移動し、[ロギング] > [ログ エクスプローラ] を選択します。Google Cloud プロジェクトを選択します。
まだ監査ポリシーがデプロイされていないため、監査ログはありません。なお、監査ログはアクセスログとは異なります。
stackdriver
アクセスログを表示するには、[クエリビルダー] フィールドに次のクエリを入力して、[クエリを実行] をクリックします。logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
ログ エクスプローラの使用方法の詳細については、ログ エクスプローラの概要をご覧ください。
監査ポリシーの構成と監査ログの確認
このセクションでは、Bookinfo アプリケーションを監査するためのいくつかのオプションを提示します。監査ポリシーをデプロイすると、いくつかのリクエストを送信した後、ログ エクスプローラで監査ログを確認できます。
次のコマンドを入力して、クラスタを操作する認証情報を取得します。このコマンドは、クラスタに対して
kubectl
の現在のコンテキストも設定します。gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --zone=CLUSTER_LOCATION
次の監査ポリシーを適用して、
/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
Bookinfo にリクエストをいくつか送信します。
ログ エクスプローラで [クエリビルダー] フィールドに次のクエリを入力し、[クエリを実行] をクリックします。
logName="projects/PROJECT_ID/logs/server-istio-audit-log"
このクエリにより、次のようなログが返されます。
次のポリシーを適用して、
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
新しい監査ポリシーは、有効にする前に、最初に反映させる必要があります。
10 件以上のリクエストを Bookinfo に送信して、評価サービスがヒットしたことを確認してから、ログ エクスプローラで監査ログを確認します。監査ログは次のようになります。
次のポリシーを適用して、デフォルトの名前空間内のすべてのサービスを監査するようにします。
kubectl apply -f - << EOF apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: namespace: default name: "audit-all" spec: action: AUDIT rules: - {} EOF
さらに Bookinfo にリクエストを送信し、ログ エクスプローラで監査ログを確認します。これで、すべてのリクエストが監査ログに記録されるようになります。
監査ポリシーを ProductPage と Ratings に制限しておく場合は、
audit-all
ポリシーを削除します。kubectl delete authorizationpolicy audit-all -n default
トラブルシューティング
監査ポリシーを有効にしても監査ログが表示されない場合は、次の点を確認してください。
ログ エクスプローラで指定された期間のトラフィックがあることを確認します。Bookinfo を使用してテストしている場合は、次のコマンドを数回実行することでリクエストを送信できます。
curl -s http://EXTERNAL_IP/productpage | grep Bookstore
Ingress ゲートウェイに、監査対象のサービスに対するリクエストをブロックする
AuthorizationPolicy
があるかどうかを確認します。ログ エクスプローラの次のフィルタで
stackdriver
アクセスログを調べて、リクエストがアプリケーションに到達したかどうかを確認します。logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
Stackdriver が構成され、監査ログが有効になっていることを確認するには、現在の
istiod
状態の構成をダンプします。config_dump
でenable_audit_log
と監査ポリシーの名前を検索します。istioctl dashboard envoy POD_NAME.NAMESPACE
リクエストが監査ポリシールールに一致することを確認するには、ロールベースのアクセス制御(RBAC)のデバッグログを確認します。次のコマンドを使用して、RBAC デバッグ ロギングを有効にします。
kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
リクエストを送信し、
kubectl logs
コマンドを使用して Pod のログを確認します。kubectl logs POD_NAME -n NAMESPACE -c istio-proxy