GKE ノード上で Linux の auditd ログを有効にする

このページでは、Container-Optimized OS を実行する Google Kubernetes Engine ノードで詳細なオペレーティング システム監査ログを有効化する方法について説明します。このページでは、ログを Stackdriver に送信するように Logging エージェントを構成する方法についても説明します。

オペレーティング システムの監査ロギングは、Cloud 監査ログKubernetes 監査ログとは異なります。

概要

ノードのオペレーティング システムログには、エラー メッセージ、ログイン試行、バイナリ実行など、クラスタとワークロードの状態に関する重要な情報が記録されます。この情報を活用して、問題のデバッグやセキュリティ インシデントの調査を行えます。

クラスタ内の各ノードからログを収集するには、DaemonSet のスケジュールが可能なクラスタノードごとに DaemonSet を使用してポッドを 1 つずつ実行します。このポッドによって、ホスト上に auditd ロギング デーモンが構成され、ログを Stackdriver などのログ取り込みサービスに送信するように Logging エージェントが構成されます。

定義上、監査はイベントの後に実行されるため、事後的なセキュリティ対策となります。クラスタでフォレンジックを実行する際、多くの場合 auditd ログだけでは不十分です。全体的なセキュリティ戦略の一環として auditd ログの最適な使用方法を検討してください。

制限事項

このページで説明するロギング メカニズムは、Container-Optimized OS を実行するノードでのみ動作します。

ロギング DaemonSet の動作の仕組み

このセクションでは、サンプルのロギング DaemonSet が動作する仕組みを説明します。この仕組みを理解することで、DaemonSet を自由に構成できるようになります。後続のセクションでは、DaemonSet をデプロイする方法について説明します。

サンプルのマニフェストで、DaemonSet と ConfigMap およびそれらを格納する名前空間のインスタンスを定義します。

この DaemonSet では、クラスタ内の各ノードにポッドがデプロイされます。このポッドには 2 つのコンテナが格納されます。1 つ目のコンテナは、cloud-audit-setup systemd サービスを起動する init コンテナです。2 つ目のコンテナ fluentd-gcp-cos-auditd は、fluentd をベースとするアプリケーションである Stackdriver Logging エージェントで使用されます。

このサンプルのロギング DaemonSet ログでは、次のイベントがログに記録されます。

  • auditd システム構成の変更
  • AppArmor 権限チェック
  • execve()socket()setsockopt()mmap() の実行
  • ネットワーク接続
  • ユーザーのログイン
  • SSH セッションとその他すべての TTY(kubectl exec -t セッションを含む)

ロギング DaemonSet の構成

ロギング DaemonSet の構成は、fluentd-gcp-config-cos-auditd という ConfigMap を使って行います。この例では、監査ログが Stackdriver に送信されますが、Stackdriver 以外の宛先にログを送信するようにも構成できます。

auditd は、デフォルトのロギング構成よりもかなり多くのログを生成することがあり、システム リソースを消費します。そのため、追加費用が発生する場合があります。フィルタを設定すると、ロギングのボリュームを管理できます。

ロギング DaemonSet のデプロイ

  1. 既存のクラスタを使用することも、新しいクラスタを作成することもできます。

  2. サンプルのマニフェストをダウンロードします。

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml
    
  3. サンプルのマニフェストを必要に応じて編集します。DaemonSet の仕組みについては、前のセクションをご覧ください。

  4. ロギング DaemonSet と ConfigMap をデプロイします。

    kubectl apply -f cos-auditd-logging.yaml
    
  5. ロギングポッドが起動したことを確認します。マニフェストで別の名前空間を定義した場合は、cos-auditd を、ご使用の名前空間名に置き換えてください。

    kubectl get pods --namespace=cos-auditd
    

    ポッドが実行されている場合、出力は次のようになります。

    NAME                                             READY   STATUS    RESTARTS   AGE
    cos-auditd-logging-g5sbq                         1/1     Running   0          27s
    cos-auditd-logging-l5p8m                         1/1     Running   0          27s
    cos-auditd-logging-tgwz6                         1/1     Running   0          27s
    

    クラスタのノードごとにポッドが 1 つデプロイされます。この例のクラスタには 3 つのノードが存在します。

  6. これで、Stackdriver で監査ログにアクセスできるようになりました。

クリーンアップ

auditd によるロギングを無効にするには、ロギング DaemonSet を削除してノードを再起動します。監査の構成は、有効になると同時にロックされます。この構成を変更するには、ノードの再作成が必要になります。

  1. DaemonSet、ConfigMap、およびそれらの名前空間をクラスタから削除します。

    kubectl delete -f cos-auditd-logging.yaml
    
  2. クラスタのノードを再起動します。まず、ノードが所属するインスタンス グループを取得します。

    instance_group=$(gcloud compute instance-groups managed list \
                        --format="value(name)" \
                        --filter=${CLUSTER_NAME})
    

    次に、インスタンス自体を取得します。

    instances=$(gcloud compute instance-groups managed list-instances ${instance_group} \
                   --format="csv(instance)[no-heading][terminator=',']")
    

    最後に、インスタンスを再作成します。

    gcloud compute instance-groups managed recreate-instances ${instance_group} \
       --instances=${instances}
    

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Kubernetes Engine のドキュメント