監査ポリシー

このページでは、Google Kubernetes Engine（GKE）の監査ロギング ポリシーの概要について説明します。このページでは、GKE でクラスタ内のイベントがキャプチャされて記録される方法、ログに記録される情報とその記録先に影響する要因、監査ログに表示される内容に影響するポリシーについて説明します。

さまざまな種類の監査ログを有効にして表示する手順と、必要な IAM 権限については、GKE 監査ロギングの情報をご覧ください。

このページは、クラスタで生じたアクティビティに関する分析情報を取得してセキュリティ脅威のモニタリング、変更の追跡、問題のトラブルシューティングを行うセキュリティ スペシャリストを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

このページを読む前に、次のトピックをよく理解しておいてください。

監査ポリシーの概要

GKE クラスタ内の Kubernetes API サーバーは、GKE が管理するバックエンドに監査ログエントリを書き込みます。GKE は、Kubernetes API サーバーからログエントリを受け取ると、プロジェクトの管理アクティビティ ログとデータアクセス ログに書き込みます。

プロジェクトの監査ログの内容は 2 つのポリシーによって変わります。

  • Kubernetes 監査ポリシーでは、イベントをログエントリとして記録するルールを定義します。また、ログエントリに含めるデータを指定します。

  • GKE 監査ポリシーでは、管理アクティビティ ログに書き込むエントリとデータアクセス ログに書き込むエントリを定義します。

データアクセス ログに書き込まれる監査ログは、監査ログの構成によって異なります。データアクセス ログには、Google Cloud Observability の料金が適用されます。管理アクティビティ ログでは料金は発生しません。GKE は、次のタイプのデータアクセス ログをサポートしています。

  • ADMIN_READ: Pod の一覧表示など、Kubernetes リソースに関するメタデータを読み取るオペレーション。
  • DATA_READ: Kubernetes リソース内のデータを読み取るオペレーション（Pod のログの読み取りなど）。
  • DATA_WRITE: Kubernetes リソースにデータを書き込むオペレーション（Pod のステータスの更新など）。

詳しくは、データアクセス監査ログを構成するをご覧ください。

Kubernetes の監査ポリシー

Kubernetes API サーバーは、kube-apiserver コマンドの --audit-policy-file フラグで指定されたポリシーに従います。

GKE は、Kubernetes API サーバーを起動するときに、--audit-policy-file フラグの値を設定して監査ポリシー ファイルを提供します。オープンソースの Kubernetes リポジトリには、監査ポリシー ファイルを生成する configure-helper.sh スクリプトがあります。スクリプトを直接見ると、監査ポリシー ファイルの大部分を確認できます。

イベントとステージ

ユーザーやコンポーネントから Kubernetes API サーバーへのリクエストが作成された場合、そのリクエストは 1 つ以上のステージを経て実行されます。

ステージ 説明
RequestReceived 監査ハンドラがリクエストを受信しました。
ResponseStarted レスポンス ヘッダーは送信されましたが、レスポンスの本文は送信されていません。
ResponseComplete レスポンスの本文が送信され、すべての送信処理が完了しました。
Panic サーバーで内部エラーが発生し、リクエストが完了していません。

リクエストの各段階では、ポリシーに従って処理されるイベントが生成されます。このポリシーは、イベントをログエントリとして記録するかどうか、およびその場合にどのデータをログエントリに含めるかを指定します。

監査レベル

Kubernetes の監査ポリシー ファイルには、ルールリストが含まれています。ポリシー ファイルでは、イベントに一致する最初のルールによりイベントの監査レベルが設定されます。

ルールでは、以下の監査レベルのいずれかが指定されます。

レベル 説明
None イベントのログエントリを作成しない。
Metadata ログエントリを作成する。メタデータは含めるがリクエストの本文またはレスポンスの本文は含めない。
Request ログエントリを作成する。メタデータとリクエストの本文は含めるがレスポンスの本文は含めない。
RequestResponse ログエントリを作成する。メタデータ、リクエストの本文、レスポンスの本文を含める。

ここで、ルールの例を示します。イベントがルールに一致する場合、Kubernetes API サーバーは Request レベルでログエントリを作成します。

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

次のすべてが該当する場合、イベントがルールに一致したと判断されます。

  • イベントがポリシー ファイル内の以前のルールと一致しない。
  • 呼び出し元の ID が system:nodes ユーザー グループ内に存在する。
  • 呼び出しが update リクエストか patch リクエストである。
  • リクエストが nodes/status リソースか pods/status リソースに存在する。
  • イベントが呼び出しの RequestReceived ステージに向けたものではない。

GKE 監査ポリシー

GKE が Kubernetes API サーバーからログエントリを受信すると、独自のポリシーを適用して、プロジェクトの管理アクティビティ ログに書き込むエントリとプロジェクトのデータアクセス ログに書き込むエントリを決定します。

ほとんどの場合、GKE は Kubernetes API サーバーから受け取ったログエントリに次のルールを適用します。

  • create、delete、update の各リクエストを表すエントリは、管理アクティビティ ログに書き込まれます。

  • get、list、updateStatus の各リクエストを表すエントリは、データアクセス ログに書き込まれます。

料金とデフォルトで有効なログの種類については、ロギングの詳細をご覧ください。

GKE クラスタ用の Kubernetes 監査ポリシー ファイル

GKE クラスタ用の Kubernetes 監査ポリシー ファイルの冒頭には、特定のイベントを記録しないように指定するルールが記述されます。たとえば、以下のルールでは nodes リソースや nodes/status リソースの kubelet による任意の get リクエストは記録しないように指定されています。None レベルでは、一致したイベントはログに記録されません。

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

ポリシー ファイルでは、level: None ルールリストの後に特殊なケースのルールリストが記述されています。次の例は、Metadata レベルで特定のリクエストを記録するよう指示する特殊なケースのルールです。

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

次のすべてが該当する場合、イベントがルールに一致したと判断されます。

  • イベントがポリシー ファイル内の以前のルールと一致しない。
  • リクエストがタイプ secrets、configmaps、tokenreviews のリソースに対するものである。
  • イベントが呼び出しの RequestReceived ステージに向けたものではない。

ポリシー ファイルには、特殊なケースのルールリストの後に一般的なルールが複数記述されます。スクリプトの一般的なルールを確認するには、${known_apis} の known_apis の値を置き換える必要があります。代入すると、ルールは次のようになります。

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

このルールは、ポリシー ファイルの以前のルールと一致せず、その時点で RequestReceived ステージではないイベントに適用されます。このルールでは、リストに記載されたいずれかのグループに属する任意のリソースに対する get、list、watch の各リクエストが Request レベルで記録されると定義されています。

ポリシー ファイルの次のルールは、以下のようになります。

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

このルールは、ポリシー ファイルの以前のルールと一致せず、その時点で RequestReceived ステージではないイベントに適用されます。特に、このルールは読み取りリクエストの get、list、watch には適用されません。このルールは create、update、delete などの書き込みリクエストに適用されます。このルールでは、書き込みリクエストは RequestResponse レベルでログに記録されます。

GKE クラスタ用の Kubernetes 監査ポリシーの概要

次のリストは、GKE クラスタ用の Kubernetes 監査ポリシーの概要を示しています。

  • 一般に、create、update、delete などの書き込みリクエストは RequestResponse レベルで記録されます。

  • 一般に、get、list、watch の各イベントは Metadata レベルで記録されます。

  • 一部のイベントは特殊なケースとして扱われます。特殊なケースとして扱われるリクエストの確定リストについては、ポリシーのスクリプトを参照してください。特殊なケースには以下のようなものがあります。

    • kubelet や system:node-problem-detector による更新やパッチ リクエスト、nodes/status リソースや pods/status リソースの system:serviceaccount:kube-system:node-problem-detector は Request レベルで記録されます。

    • nodes/status リソースや pods/status リソースの system:nodes グループの任意の ID による更新やパッチ リクエストは、Request レベルで記録されます。

    • system:serviceaccount:kube-system:namespace-controller による deletecollection リクエストは、Request レベルで記録されます。

    • secrets リソース、configmaps リソース、tokenreviews リソースのリクエストは、Metadata レベルで記録されます。

  • ログに記録されないリクエストもあります。ログに記録されないリクエストの確定リストについては、ポリシー スクリプトで level: None ルールをご覧ください。次のリクエストはログに記録されません。

    • system:kube-proxy による、endpoints、services、services/status の各リソースの表示リクエスト。

    • kube-system Namespace の configmaps リソースの system:unsecured による Get リクエスト。

    • nodes リソースや nodes/status リソースの kubelet による Get リクエスト。

    • nodes リソースや nodes/status リソースの system:nodes グループ内の任意の ID による Get リクエスト。

    • kube-system Namespace の endpoints リソースの system:kube-controller-manager、system:kube-scheduler、system:serviceaccount:endpoint-controller による Get リクエストや Update リクエスト。

    • namespaces、namespaces/status、namespaces/finalize の各リソースの system:apiserver による Get リクエスト。

    • metrics.k8s.io グループの任意のリソースの system:kube-controller-manager による Get リクエストおよび List リクエスト。

    • /healthz*、/version、/swagger* のいずれかに一致する URL へのリクエスト。

次のステップ