このページでは、Containrer-Optimized OS を実行している Google Kubernetes Engine ノードで、詳細なオペレーティング システム監査ログを有効にする方法を説明します。また、Google Cloud のオペレーション スイートにログが送信されるように Logging エージェントを構成する方法についても説明します。
オペレーティング システムの監査ロギングは、Cloud Audit Logs や Kubernetes 監査ログとは異なります。
概要
ノードのオペレーティング システムログには、エラー メッセージ、ログイン試行、バイナリ実行など、クラスタとワークロードの状態に関する重要な情報が記録されます。この情報を活用して、問題のデバッグやセキュリティ インシデントの調査を行えます。
クラスタ内の各ノードからログを収集するには、DaemonSet のスケジュールが可能なクラスタノードごとに DaemonSet を使用して Pod を 1 つずつ実行します。この Pod によって、ホスト上に 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 に基づいたアプリケーションである Google Cloud のオペレーション スイートの Logging エージェント用です。
このサンプルのロギング DaemonSet ログでは、次のイベントがログに記録されます。
auditd
システム構成の変更- AppArmor 権限チェック
execve()
、socket()
、setsockopt()
、mmap()
の実行- ネットワーク接続
- ユーザーのログイン
- SSH セッションとその他すべての TTY(
kubectl exec -t
セッションを含む)
ロギング DaemonSet の構成
ロギング DaemonSet の構成は、fluentd-gcp-config-cos-auditd
という ConfigMap を使って行います。提供されている例では、監査ログは Google Cloud のオペレーション スイートに送信されますが、Google Cloud のオペレーション スイート以外の宛先にログが送信されるように構成できます。
auditd
は、デフォルトのロギング構成よりもかなり多くのログを生成することがあり、システム リソースを消費します。そのため、追加費用が発生する場合があります。フィルタを設定すると、ロギングのボリュームを管理できます。
fluentd-gcp-config-cos-auditd
ConfigMap にフィルタをセットアップして、特定のデータがロギングされないようにできます。GKE で Google Cloud オペレーション スイートのロギングをカスタマイズする方法と、Google Cloud のオペレーション スイートの Logging エージェントを構成する方法については、このチュートリアルをご覧ください。- 着信ログがフィルタリングされるように Google Cloud のオペレーション スイートを構成することもできます。詳細については、Google Cloud のオペレーション スイートのログの除外をご覧ください。
ロギング DaemonSet のデプロイ
既存のクラスタを使用することも、新しいクラスタを作成することもできます。
サンプルのマニフェストをダウンロードします。
curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml
サンプルのマニフェストを必要に応じて編集します。DaemonSet の仕組みについては、前のセクションをご覧ください。
ロギング DaemonSet と ConfigMap をデプロイします。
kubectl apply -f cos-auditd-logging.yaml
ロギング Pod が起動したことを確認します。マニフェストで別の Namespace を定義した場合は、cos-auditd を使用している名前空間の名前に置き換えます。
kubectl get pods --namespace=cos-auditd
Pod が実行されている場合、出力は次のようになります。
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 つのノードが存在します。
Google Cloud のオペレーション スイートで監査ログにアクセスできるようになりました。ログビューアで、VM インスタンスで結果をフィルタリングします。
ログのエクスポート
ログをエクスポートする方法については、次のページをご覧ください。
- ログビューアを使用するには、ログのエクスポートに移動してください。
- Cloud Logging API を使用するには、API でのログのエクスポートをご覧ください。
- コマンドライン ツールを使用するには、gcloud ロギングに移動してください。
クリーンアップ
auditd
によるロギングを無効にするには、ロギング DaemonSet を削除してノードを再起動します。監査の構成は、有効になると同時にロックされます。この構成を変更するには、ノードの再作成が必要になります。
DaemonSet、ConfigMap、およびそれらの名前空間をクラスタから削除します。
kubectl delete -f cos-auditd-logging.yaml
クラスタのノードを再起動します。まず、ノードが所属するインスタンス グループを取得します。
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}
次のステップ
- Cloud Forensics 101 を視聴してクラウド フォレンジックを始める。
- Kubernetes 監査ロギングと監査ポリシーについて学習する。
- Kubernetes Engine セキュリティの概要を読む。
- Cloud 監査ログについて学習する。