監査ロギング

概要

GKE on VMware は、Cloud API と Kubernetes クラスタの両方のレベルで監査ロギングをサポートします。このドキュメントでは、Kubernetes クラスタの監査ロギングについて説明します。Cloud API 監査ロギングについては、Cloud API 監査ロギングの情報をご覧ください。

GKE on VMware は、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 の再起動やアップグレードでログが消えないように、監査ログは永続ディスクに書き込まれます。GKE on VMware では 12 GB までの監査ログエントリが保持されます。

Cloud Audit Logs

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

監査ロギング プロジェクトは、フリート ホスト プロジェクトと同一でなければなりません。

Cloud Audit Logs を有効にすると、ディスクベースの監査ロギングは GKE on VMware によって無効化されます。

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

制限事項

GKE on VMware の Cloud Audit Logs の現在のバージョンには、いくつかの制限があります。

  • データアクセス(取得、リスト出力、監視リクエスト)ロギングはサポートされていません。

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

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

Anthos Audit API の有効化

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

Anthos Audit API の有効化

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

GKE 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.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 監査ログを有効にする

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

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. [フィルタを送信] をクリックして、このプロジェクトにログインするように構成された GKE 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.serviceNameanthosgke.googleapis.com と等しくなる点に注意してください。

監査ポリシー

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