監査ロギング

概要

このドキュメントでは、Google Distributed Cloud（ソフトウェアのみ）で Cloud Audit Logs を使用する方法について説明します。Google Distributed Cloud では Kubernetes Audit Logging を使用して、クラスタの Kubernetes API サーバーに対して行われた呼び出しを時系列で記録します。監査ログは、疑わしい API リクエストの調査や統計情報の収集に役立ちます。GKE On-Prem API の監査ロギングについては、Cloud API 監査ロギングをご覧ください。

Cloud Audit Logs について

監査ログは、Cloud Audit Logs が プロジェクトに書き込まれます。 Google Cloud Cloud Audit Logs への書き込みには、ディスクへの書き込みや、オンプレミス ロギング システムでのログ取得と比べていくつかの利点があります。

  • すべてのクラスタの監査ログを一元化できます。
  • Cloud Audit Logs に書き込まれるログエントリは不変です。
  • Cloud Audit Logs エントリは 400 日間保持されます。
  • Cloud Audit Logs の機能については、料金は Google Distributed Cloud の料金に含まれています。
  • ログをディスクまたは Cloud Audit Logs に書き込むように Google Distributed Cloud を構成できます。

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

デフォルトでは、VM の再起動やアップグレードでログが消えないように、監査ログは永続ディスクに書き込まれます。

  • 高度なクラスタが有効になっていない場合:

    Google Distributed Cloud では、最大 12 GB の監査ログエントリが保持されます。

  • 高度なクラスタが有効になっている場合:

    Google Distributed Cloud では、最大 1 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 を管理クラスタにデプロイします。このコンポーネントは、ユーザー クラスタのサイドカー コンテナとしても利用できます。

制限事項

Cloud Audit Logs には、次の制限があります。

  • データアクセス ロギング（取得、リスト出力、監視リクエスト）はサポートされていません。
  • Kubernetes 監査ポリシーの変更はサポートされていません。
  • Cloud Audit Logs は、長時間のネットワークの停止に対処できません。ログエントリを Google Cloudにエクスポートできない場合は、10 GB のディスク バッファのキャッシュに保存されます。バッファがいっぱいになると、最も古いエントリが削除されます。
  • 1 つのプロジェクトで、Cloud Audit Logs で使用できるサービス アカウントを最大 1,000 個までサポートできます。複数のクラスタで同じサービス アカウントを使用できます。

Anthos Audit API を有効にする

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

Anthos Audit API の有効化

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

Google Distributed Cloud で使用するために作成したサービス アカウントは、すでに 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 は、最初に管理クラスタを作成するときにのみ有効にできます。既存の管理クラスタを変更して 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 は、ユーザー クラスタが登録されている Google Cloud プロジェクトでのみ有効にできます。

既存のユーザー クラスタが登録されていない場合は、Cloud Audit Logs を有効にする前に、以下の手順で登録します。

  1. ユーザー クラスタの構成ファイルに gkeConnect セクションを追加します。例:

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

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

    gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

ユーザー クラスタを登録したら、次の手順で Cloud Audit Logs を有効にします。

  1. ユーザー クラスタの構成ファイルの cloudAuditLogging セクションに入力します。各フィールドの詳細については、Cloud Audit Logs を有効にしてユーザー クラスタを作成するをご覧ください。cloudAuditLogging セクションの projectID は、gkeConnect セクションのものと同じでなければなりません。

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

    gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

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

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

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 へのアクセス

コンソール

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

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

    [以前のログビューア] ページが表示された場合は、[アップグレード] プルダウン メニューから [新しいログ エクスプローラにアップグレード] を選択します。

  2. [クエリ] フィールドをクリックして、クエリを入力します。

  3. [クエリ] フィールドに次のクエリを入力します。

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

    PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  4. [クエリを実行] をクリックして、このプロジェクトにログインするように構成されたクラスタのすべての監査ログを表示します。

gcloud

  1. プロジェクトの管理アクティビティ ログで 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
  1. PROJECT_ID は、実際のプロジェクト ID に置き換えます。

出力には 2 つのログエントリが表示されます。各ログエントリの logName フィールドの値は projects/PROJECT_ID/logs/externalaudit.googleapis.com%2Factivity で、protoPayload.serviceName は anthosgke.googleapis.com と等しくなります。

監査ポリシー

Kubernetes 監査ポリシーでは、イベントをログエントリとして記録するルールを定義し、ログエントリに含めるデータを指定します。Cloud Audit Logs の動作は、静的に構成された Kubernetes 監査ロギング ポリシーによって決まります。このポリシーを変更して Cloud Audit Logs の動作を変更することはできません。