このページでは、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 へのリクエスト。