概要
VMware 用 Google Distributed Cloud（ソフトウェアのみ）は、Google Cloud API と Kubernetes クラスタの両方のレベルで監査ロギングをサポートします。このドキュメントでは、Kubernetes クラスタの監査ロギングについて説明します。Google Cloud API の監査ロギングについては、Cloud API の監査ロギングに関する情報をご覧ください。
Google Distributed Cloud は、Kubernetes Audit Logging を使用して、クラスタの Kubernetes API サーバーへの呼び出しを時系列で記録します。監査ログは、不審な API リクエストの調査や統計情報の収集に役立ちます。
監査ログをディスクや Google Cloud プロジェクトの Cloud Audit Logs に書き込むように、クラスタを構成できます。Cloud Audit Logs への書き込みには、ディスクへの書き込みや、オンプレミス ロギング システムでのログ取得よりもいくつかの利点があります。
- すべての GKE クラスタの監査ログを一元化できます。
- Cloud Audit Logs に書き込まれるログエントリは不変です。
- Cloud Audit Logs エントリは 400 日間保持されます。
- Cloud Audit Logs は Anthos の料金に含まれています。
ディスクベースの監査ロギング
デフォルトでは、VM の再起動やアップグレードでログが消えないように、監査ログは永続ディスクに書き込まれます。Google Distributed Cloud では、最大 12 GB の監査ログエントリが保持されます。
Cloud Audit Logs
クラスタ用の Cloud Audit Logs を有効にすると、クラスタ構成ファイルの cloudAuditLogging.projectID フィールドで指定した Google Cloud プロジェクトを使用して、クラスタの Kubernetes API サーバーからの管理アクティビティ監査ログエントリが Google Cloud に送信されます。この Google Cloud プロジェクトは、監査ロギング プロジェクトと呼ばれます。
監査ロギング プロジェクトは、フリート ホスト プロジェクトと同一でなければなりません。
ログエントリをバッファリングして Cloud Audit Logs に書き込むために、Google Distributed Cloud は audit-proxy Pod を管理クラスタにデプロイします。このコンポーネントは、ユーザー クラスタのサイドカー コンテナとしても利用できます。
制限事項
Google Distributed Cloud の Cloud Audit Logs の現在のバージョンには、いくつかの制限があります。
データアクセス（取得、リスト出力、監視リクエスト）ロギングはサポートされていません。
Kubernetes 監査ポリシーの変更はサポートされていません。
Cloud Audit Logs は、長時間のネットワークの停止に対処できません。ログエントリを Google Cloud にエクスポートできない場合は、10G のディスク バッファにキャッシュ保存します。バッファの空き容量がなくなると、後続のエントリは破棄されます
Anthos Audit API を有効にする
監査ロギング プロジェクトで Anthos Audit API を有効にします。
Cloud Audit Logs のサービス アカウントを作成する
Google Distributed Cloud で使用するために作成したサービス アカウントは、すでに 1 つ以上ありますが、監査ロギング機能に対しては、監査ロギング サービス アカウントと呼ばれる追加のサービス アカウントを作成する必要があります。
監査ログサービス アカウントを作成します。
gcloud iam service-accounts create audit-logging-service-account
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 はサービス アカウントのメールアドレスです。
管理ワークステーションの他のサービス アカウントキーと同じ場所に
audit-logging-key.jsonを保存します。
Cloud Audit Logs を有効にして管理クラスタを作成する
管理クラスタの Cloud Audit Logs は、最初に管理クラスタを作成するときにのみ有効にできます。既存の管理クラスタを変更して Cloud Audit Logs を有効にすることはできません。
管理クラスタの作成をご覧ください。
管理クラスタの構成ファイルで、
cloudAuditLoggingセクションに入力します。cloudAuditLogging.projectIDを、監査ロギング プロジェクトの ID に設定します。cloudAuditLogging.clusterLocationを、ログを保存する Google Cloud リージョンに設定します。レイテンシを改善するには、オンプレミスのデータセンターに近いリージョンを選択します。cloudAuditLogging.serviceAccountKeyPathを、監査ロギング サービス アカウントの JSON キーファイルのパスに設定します。
例:
cloudAuditLogging: projectID: "my-project" clusterLocation: "us-west1" serviceAccountKeyPath: "/my-key-folder/audit-logging-key.json"
通常どおりクラスタ作成を続けます。
Cloud Audit Logs を有効にしてユーザー クラスタを作成する
ユーザー クラスタの作成をご覧ください。
ユーザー クラスタの構成ファイルで、
cloudAuditLoggingセクションに入力します。cloudAuditLogging.projectIDを、監査ロギング プロジェクトの ID に設定します。cloudAuditLogging.clusterLocationを、ログを保存する Google Cloud リージョンに設定します。レイテンシを改善するには、オンプレミスのデータセンターに近いリージョンを選択します。cloudAuditLogging.serviceAccounKeyPathの値を、Cloud Audit Logs サービス アカウントの JSON キーファイルのパスに設定します。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 は、ユーザー クラスタが登録されている Google Cloud プロジェクトでのみ有効にできます。
既存のユーザー クラスタが登録されていない場合は、Cloud Audit Logs を有効にする前に、以下の手順で登録します。
ユーザー クラスタの構成ファイルに
gkeConnectセクションを追加します。例:gkeConnect: projectID: "my-project" registerServiceAccountKeyPath: "/my-key-fokder/connect-register-key.json"
クラスタを更新します。
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
ユーザー クラスタを登録したら、次の手順で Cloud Audit Logs を有効にします。
ユーザー クラスタの構成ファイルの
cloudAuditLoggingセクションに入力します。各フィールドの詳細については、Cloud Audit Logs を有効にしてユーザー クラスタを作成するをご覧ください。cloudAuditLoggingセクションのprojectIDは、gkeConnectセクションのものと同じでなければなりません。クラスタを更新します。
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
既存のユーザー クラスタの Cloud Audit Logs を無効にする
ユーザー クラスタの構成ファイルで、
cloudAuditLoggingセクションを削除します。ユーザー クラスタを更新します。
gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]
アクセス監査ログ
ディスクベースの監査ロギング
管理クラスタの監査ログは、/var/log/kube-audit/kube-apiserver-audit.log のコントロール プレーン ノードで確認できます。ユーザー クラスタの監査ログは、kube-audit-kube-apiserver-0 という名前の PersistentVolumeClaim にあります。このデータには、volumes エントリを介してユーザー自身の Pod 内でアクセスできます。
管理クラスタ用にこのエントリを追加します。
volumes:
- name: kube-audit
hostPath:
path: /var/log/kube-audit
type: ""
ユーザー クラスタ用にこのエントリを追加します。
volumes:
- name: kube-audit
persistentVolumeClaim:
claimName: kube-audit-kube-apiserver-0
適切な管理クラスタノード（およびこのノードのみ）で Pod をスケジュールするには、次のように nodeSelector セクションと tolerations セクションを Pod 仕様に追加する必要があります。
spec:
nodeSelector:
node-role.kubernetes.io/master: ''
tolerations:
- key: node-role.kubernetes.io/master
value: ""
effect: NoSchedule
ユーザー クラスタの場合は、ユーザー クラスタ名として namespace を設定し、nodeName を kube-apiserver-0 と同じに設定します。
spec:
nodeName: NODE_NAME
kube-apiserver-0 の nodeName を特定するには、次のコマンドを実行します。
kubectl get pod kube-apiserver-0 -n USER_CLUSTER_NAME --kubeconfig kubeconfig -o jsonpath='{.spec.nodeName}'
各監査ログのファイル名には、ファイルがローテーションされた日時を示すタイムスタンプがあります。ファイルには、その日時までの監査ログが含まれています。
Cloud Audit Logs
コンソール
Google Cloud コンソールで、[ロギング] メニューの [ログ] ページに移動します。
上で説明したプルダウン メニューのすぐ上にある [ラベルまたはテキスト検索でフィルタ] ボックスで、下矢印をクリックしてプルダウン メニューを開きます。メニューで、[高度なフィルタに変換] を選択します。
フィールドに次のフィルタを入力します。
resource.type="k8s_cluster" logName="projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity" protoPayload.serviceName="anthosgke.googleapis.com"
[フィルタを送信] をクリックして、このプロジェクトにログインするように構成されたクラスタのすべての監査ログを表示します。
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 監査ロギング ポリシーによって決まります。このポリシーの変更は現在サポートされていませんが、将来的にはサポートされる予定です。