監査ポリシー

Autopilot Standard

---

このページでは、Google Kubernetes Engine（GKE）の監査ロギング ポリシーについて説明します。さまざまな種類の監査ログと必要な IAM 権限を有効にして表示する手順については、GKE 監査ロギングの情報をご覧ください。

始める前に

このドキュメントを読む前に、次のトピックをよく理解しておいてください。

• GKE での監査ロギング
• Kubernetes での監査

概要

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 クラスタの 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 へのリクエスト。

GKE 監査ポリシー

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

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

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

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

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

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 レベルで記録されると定義されています。

注: get、list、watch の各リクエストは実際にはリクエスト本文が存在しないため、このルールの場合 Metadata レベルでログエントリが作成されます。

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

- 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 レベルでログに記録されます。

次のステップ

• Kubernetes の監査
• 監査ログへのアクセス
• GKE セキュリティの概要
• Cloud Audit Logs