監査ロギング

概要

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 を有効にします。

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 を有効にすることはできません。

  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.projectIDcloudAuditLogging.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 を設定し、nodeNamekube-apiserver-0 と同じに設定します。

   spec:
     nodeName: NODE_NAME

kube-apiserver-0nodeName を特定するには、次のコマンドを実行します。

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"
    
  4. [フィルタを送信] をクリックして、このプロジェクトにログインするように構成されたクラスタのすべての監査ログを表示します。

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.serviceNameanthosgke.googleapis.com と等しくなる点に注意してください。

監査ポリシー

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