監査ロギング

アルファ版

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

概要

Anthos clusters on VMware（GKE On-Prem）は Kubernetes Audit Logging を使用します。これにより、クラスタの Kubernetes API サーバーに対する呼び出しの記録が時系列で保持されます。監査ログは、不審な API リクエストの調査や統計情報の収集に役立ちます。

監査ログをディスクや Google Cloud プロジェクトの Cloud Audit Logs に書き込むように、クラスタを構成できます。Cloud Audit Logs への書き込みには、ディスクへの書き込みや、オンプレミス ロギング システムでのログ取得よりもいくつかの利点があります。

• すべての Anthos クラスタの監査ログを一元化できます。
• Cloud Audit Logs に書き込まれるログエントリは不変です。
• Cloud Audit Logs エントリは 400 日間保持されます。
• Cloud Audit Logs は Anthos の料金に含まれています。

ディスクベースの監査ロギング

デフォルトでは、VM の再起動やアップグレードでログが消えないように、監査ログは永続ディスクに書き込まれます。Anthos clusters on VMware では 12 GB までの監査ログエントリが保持されます。

Cloud Audit Logs

クラスタで Cloud Audit Logs を有効にすると、クラスタ構成ファイルの cloudAuditLogging.projectID フィールドで指定した Cloud プロジェクトを使用して、クラスタの Kubernetes API サーバーからの管理アクティビティ監査ログエントリが Google Cloud に送信されます。この Cloud プロジェクトは、監査ロギング プロジェクトと呼ばれます。

監査ロギング プロジェクトは、接続プロジェクトと同じでなければなりません。

Cloud Audit Logs が有効にされると、Anthos clusters on VMware は、ディスクベースの監査ロギングを無効にします。

ログエントリをバッファリングして Cloud Audit Logs に書き込むために、Anthos clusters on VMware は audit-proxy Pod を管理クラスタにデプロイします。このコンポーネントは、ユーザー クラスタのサイドカー コンテナとしても利用できます。

制限事項

Anthos clusters on VMware の Cloud Audit Logs はプレビュー機能です。このプレビュー リリースには複数の制限事項があります。

• データアクセス ロギングはサポートされていません。

• Kubernetes 監査ポリシーの変更はサポートされていません。

• Cloud Audit Logs は、ネットワークの長い停止に対処できません。ログエントリが Google Cloud にエクスポートできない場合は、10G のディスク バッファにキャッシュ保存します。そのバッファがいっぱいになると、後続のエントリは破棄されます。

Anthos Audit API の有効化

監査ロギング プロジェクトで Anthos Audit API を有効にします。

Anthos Audit API の有効化

Cloud Audit Logs のサービス アカウントの作成

Anthos clusters on VMware で使用するために作成したサービス アカウントは、すでに 1 つ以上ありますが、監査ロギング機能に対しては、監査ロギング サービス アカウントと呼ばれる追加のサービス アカウントを作成する必要があります。

1. 監査ログサービス アカウントを作成します。

   gcloud iam service-accounts create audit-logging-service-account

2. Cloud Audit Logs サービス アカウントの JSON キーファイルを作成します。

   gcloud iam service-accounts keys create audit-logging-key.json \
      --iam-account AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL
   

   ここで、AUDIT_LOGGING_SERVICE_ACCOUNT_EMAIL はサービス アカウントのメールアドレスです。

3. 管理ワークステーションの他のサービス アカウントキーと同じ場所に audit-logging-key.json を保存します。

Cloud Audit Logs を有効にした管理クラスタの作成

管理クラスタの Cloud Audit Logs は、最初に管理クラスタを作成するときにのみ有効にできます。既存の管理クラスタを変更して Cloud Audit Logs を有効にすることはできません。

1. 管理クラスタの作成をご覧ください。

2. 管理クラスタの構成ファイルで、cloudAuditLogging セクションに入力します。

3. cloudAuditLogging.projectId を、監査ロギング プロジェクトの ID に設定します。

4. cloudAuditLogging.clusterLocation を、ログを保存する Google Cloud リージョンに設定します。レイテンシを改善するには、オンプレミスのデータセンターに近いリージョンを選択します。

5. cloudAuditLogging.serviceAccountKeyPath を、監査ロギング サービス アカウントの JSON キーファイルのパスに設定します。

次に例を示します。

cloudAuditLogging:
  projectId: "my-project"
  clusterLocation: "us-west1"
  serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"

通常どおりクラスタ作成を続けます。

Cloud Audit Logs を有効にしたユーザー クラスタの作成

1. ユーザー クラスタの作成をご覧ください。

2. ユーザー クラスタの構成ファイルで、cloudAuditLogging セクションに入力します。

3. cloudAuditLogging.projectId を、監査ロギング プロジェクトの ID に設定します。

4. cloudAuditLogging.clusterLocation を、ログを保存する Google Cloud リージョンに設定します。レイテンシを改善するには、オンプレミスのデータセンターに近いリージョンを選択します。

5. cloudAuditLogging.serviceAccounKeyPath の値を、Cloud Audit Logs サービス アカウントの JSON キーファイルのパスに設定します。

6. gkeConnect セクションが入力され、gkeConnect.projectID が cloudAuditLogging.projectID と同じであることを確認します。

次に例を示します。

gkeConnect:
  projectId: "my-project"
  registerServiceAccountKeyPath: "/my-key-fokder/connect-register-key.json"

cloudAuditLogging:
  projectId: "my-project"
  clusterLocation: "us-west1"
  serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"

通常どおりクラスタ作成を続けます。

既存のユーザー クラスタの Cloud Audit Logs を有効にする

Cloud Audit Logs を有効にするには、クラスタがすでに登録されている必要があります。つまり、クラスタを作成する前に、クラスタ構成ファイルの gkeConnect セクションにはデータが入力されています。

1. ユーザー クラスタの構成ファイルで、cloudAuditLogging セクションに入力します。

2. cloudAuditLogging.projectId を、監査ロギング プロジェクトの ID に設定します。

3. cloudAuditLogging.clusterLocation を、ログを保存する Google Cloud リージョンに設定します。レイテンシを改善するには、オンプレミスのデータセンターに近いリージョンを選択します。

4. cloudAuditLogging.serviceAccounKeyPath の値を、Cloud Audit Logs サービス アカウントの JSON キーファイルのパスに設定します。

5. gkeConnect セクションが入力され、gkeConnect.projectID が cloudAuditLogging.projectID と同じであることを確認します。

次に例を示します。

gkeConnect:
  projectId: "my-project"
  registerServiceAccountKeyPath: "/my-key-fokder/connect-register-key.json"

cloudAuditLogging:
  projectId: "my-project"
  clusterLocation: "us-west1"
  serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"

ユーザー クラスタを更新します。

gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]

既存のユーザー クラスタの Cloud Audit Logs を無効にする

1. ユーザー クラスタの構成ファイルで、cloudAuditLogging セクションを削除します。

2. ユーザー クラスタを更新します。

gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]

監査ログにアクセスする

ディスクベースの監査ロギング

1. 管理クラスタおよび関連するすべてのユーザー クラスタで実行されている Kubernetes API サーバーを表示します。

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get pods --all-namespaces -l component=kube-apiserver
   

   ここで [ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルです。

2. API サーバーの監査ログをダウンロードします。

   kubectl cp -n [NAMESPACE] [APISERVER_POD_NAME]:/var/log/kube-audit/kube-apiserver-audit.log /tmp/kubeaudit.log
   

   このコマンドは、最新のログファイルを取得します。このログファイルには、管理クラスタの場合は最大 1 GB、ユーザー クラスタの場合は最大 850 GB が含まれます。

   管理クラスタの監査ログは、/var/log/kube-audit/kube-apiserver-audit.log のコントロール プレーン ノードでも確認できます。ユーザー クラスタの監査ログは、kube-audit-kube-apiserver-0 という名前の PersistentVolumeClaim にあります。このデータには、次のような volume エントリを介して自身の Pod 内でアクセスできます。

   volumes:
   ‐ name: kube-audit
     hostPath:
       path: /var/log/kube-audit
       type: ""
   

   volumes:
   ‐ name: kube-audit
     persistentVolumeClaim:
       claimName: kube-audit-kube-apiserver-0
       readOnly: true
   

   適切な管理クラスタノード（およびこのノードのみ）で Pod をスケジュールするには、次のように nodeSelector と tolerations セクションを Pod 仕様に追加する必要があります。

    spec:
     nodeSelector:
       node-role.kubernetes.io/master: ''
     tolerations:
     ‐ key: node-role.kubernetes.io/master
       value: ""
       effect: NoSchedule
   

   ユーザー クラスタの場合は、次の nodeSelector を使用します。

   spec:
    nodeSelector:
      kubernetes.googleapis.com/cluster-name: [USER_CLUSTER_NAME]
   

   古い監査記録は別のファイルに保存されます。これらのファイルを表示するには:

   kubectl exec -n [NAMESPACE] [APISERVER_POD_NAME] -- ls /var/log/kube-audit -la
   

   各監査ログのファイル名には、ファイルがローテーションされた日時を示すタイムスタンプがあります。ファイルには、その日時までの監査ログが含まれています。

Cloud Audit Logs

Console

1. Google Cloud コンソールで、[ロギング] メニューの [ログ] ページに移動します。

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

2. 上で説明したプルダウン メニューのすぐ上にある [ラベルまたはテキスト検索でフィルタ] ボックスで、下矢印をクリックしてプルダウン メニューを開きます。メニューで、[高度なフィルタに変換] を選択します。

3. テキスト ボックスに次のフィルタを入力します。

   resource.type="k8s_cluster"
   logName="projects/[PROJECT_ID]/logs/externalaudit.googleapis.com%2Factivity"
   protoPayload.serviceName="anthosgke.googleapis.com"
   

4. [フィルタを送信] をクリックして、このプロジェクトにログインするように構成された Anthos clusters on VMware クラスタのすべての監査ログを表示します。

gcloud

プロジェクトの管理アクティビティ ログで k8s_cluster リソースタイプに該当するログエントリの最初の 2 つを一覧表示します。

gcloud logging read \
    'logName="projects/[PROJECT_ID]/logs/externalaudit.googleapis.com%2Factivity" \
    AND resource.type="k8s_cluster" \
    AND protoPayload.serviceName="anthosgke.googleapis.com" ' \
    --limit 2 \
    --freshness 300d

ここで、[PROJECT_ID] はプロジェクト ID です。

出力には 2 つのログエントリが表示されます。各ログエントリについて、logName フィールドは projects/[PROJECT_ID]/logs/externalaudit.googleapis.com%2Factivity 値を持ち、protoPayload.serviceName は anthosgke.googleapis.com と等しくなる点に注意してください。

監査ポリシー

Cloud Audit Logs の動作は、静的に構成された Kubernetes 監査ロギング ポリシーによって決定されます。現在、このポリシーは変更できません。