監査ログによるKubernetesセキュリティモニタリング　詳解：クラウドセキュリティモニタリングのベストプラクティス（4）

クラウド／クラウドネイティブのログをセキュリティの観点でモニタリングするベストプラクティスを紹介する本連載。第4回は、人気が高まるKubernetes環境の監査ログによるセキュリティモニタリングについて解説する。

» 2023年09月26日 05時00分公開

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

＊本連載では、Datadogのホワイトペーパーよりベンダー中立的な部分を抜粋し、＠ITの表記ルールに合わせるために改変を加えています。（編集部）

　Kubernetesは、コンテナ化されたアプリケーションをデプロイするためのプラットフォームとして高い人気を集めているが、環境が拡大していくとセキュリティを確保することが難しくなる。新しいコンテナが追加されるたびに、アプリケーションの攻撃対象領域、つまり不正アクセスの潜在的な起点が増えることにもなる。管理しているコンテナやアプリケーションのリクエストを完全に可視化しなければ、アプリケーションのセキュリティギャップや悪意のあるアクティビティを見落としてしまう可能性が高くなる。

　Kubernetesの監査ログでは、Kubernetesのコントロールプレーンにおけるアクティビティの詳細な記録（誰が、どこで、いつ、どのように操作したかなど）が確認できる。監査ログをモニタリングすれば、機密データが漏えいする前にKubernetesリソースの設定ミスや悪用を検出し、その影響を軽減することが可能だ。しかし、Kubernetesのコンポーネントやサービスからは毎日数百万件のログイベントが生成されるため、本当に重要なログを特定することは困難である。

Kubernetesの監査ログを理解する方法
Kubernetesクラスタのセキュリティ保護のためにモニタリングする必要のある重要な監査ログ

　まず、監査ログポリシーについて簡単に説明し、Kubernetesがこれらのポリシーを使用して監査ログを生成する方法を見ていこう。

監査ログの生成に関する基本情報

　Kubernetes APIサーバに対してリクエストが実行されると、新しいポッドやサービスアカウントの作成など、さまざまな監査イベントが発生する。サーバは、監査ポリシーに沿ってこれらのイベントをフィルタリングする。監査ポリシーは、記録する監査イベントや記録したイベントの送信先を指定する一連のルールであり、これらのイベントを JSON形式のログファイルや外部のAPIバックエンドに保存することができる。

　監査ログを使用してKubernetesが取得するクラスタアクティビティの範囲は、監査ポリシーの構成と、各リソースについて設定するレベルによって異なるため、監査ポリシーを適切に設定し、Kubernetesのセキュリティをモニタリングするために必要なデータを収集することが重要だ。これらができなければ、アプリケーションに対する脅威を特定することは困難だ。例えば、ポッドのアクティビティに関するデータを収集するようにポリシーを設定していなければ、「許可されていないアカウントが特権付きのコンテナを含む新しいポッドをいつ作成したのか」を把握することは難しい。一方で、クラスタアクティビティに直接関係しないエンドポイントの監査イベント（/healthzや/version）を収集するようにポリシーが設定されていると、多くのノイズが生成されることになる。

Kubernetes APIサーバの監査ログを理解する

　自社環境のセキュリティ設定の不具合を特定するには、適切な監査ログを取得することに加え、ログを適切に理解する必要がある。新しいポッドの作成に関する監査ログのサンプルを詳しく見ていき、Kubernetesのセキュリティモニタリングに最も役立つ情報を確認しよう。

　requestURIとverb属性は、リクエストで使用されたリクエストパス（リクエストの対象となるAPIエンドポイント）とアクション（一覧表示、作成、監視）を示す。APIサーバは、このアクションに対応するHTTPメソッドにマッピングする。下記のエントリー例では、あるユーザーがネームスペースに”default”という新しいポッドを作成するPOSTリクエストを実行していることが分かる。

　リクエストパスは、ユーザーがkubectl execコマンドを使用してコンテナで実行するコマンドも取得でき、ユーザーやサービスがアプリケーションとどのようにやりとりしているかについて、豊富なコンテキストを得ることができる。例えば、ユーザーアカウントがlsコマンドをポッドで実行、ディレクトリを表示して探索していることを検出できる。

　user、sourceIPs、およびauthorization.k8s.io/reason属性では、リクエストしたユーザー、組織におけるそのユーザーの権限グループ、リクエストを許可した特定のRBAC権限の詳細を確認できる（RBACロール、ClusterRolesなど）。このデータは、ユーザーのアクセス権限レベルを監査したり、不明なIPアドレスからリクエストがあった場合にアカウントのセキュリティが侵害されているかどうかを判断したりするのに役立つ。また、攻撃に対してアプリケーションを脆弱（ぜいじゃく）な状態にする可能性のある設定ミスを特定するのにも役立つ。

　次に、適切なセキュリティポリシーを設定し、コンテナ化された環境のセキュリティギャップを迅速に特定するためモニタリングする必要があるKubernetes監査ログの、幾つかのタイプについて説明する。

モニタリングする必要がある重要なKubernetesの監査ログ

　攻撃者が、Kubernetesのリソース、アカウントおよびサービスにアクセスし変更する手法は幾つかある。これらの手法の多くで、Kubernetes環境またはRBACポリシーにおける単純な設定ミスが悪用されている。ここでは、クラスタにおける不審なアクティビティを特定し、以下で使用される攻撃手法を検出するためにモニタリングする必要がある重要な幾つかの監査ログについて解説する。

Kubernetes環境へのアクセス
Kubernetesリソースの変更
ユーザーおよびサービスアカウントのアクティビティ

Kubernetes環境へのアクセス

　Kubernetes API サーバは、ユーザーや自社環境以外のKubernetesリソースからの全てのリクエストを管理する。Kubernetes APIサーバは、攻撃者が最初にアクセスしようとする可能性のあるコンポーネントの1つだ。攻撃者は、APIサーバにアクセスすると、サービスアカウントやポッドなど、環境にある他のリソースを見つけて制御しようとする。監査ログから以下のアクティビティをモニタリングすることで、脆弱性を特定し、攻撃がKubernetes環境以外の領域に発展する前に検出することができる。

匿名リクエストの許可

　Kubernetesでは、デフォルトで匿名リクエストを許可するように設定されている。さらに、デフォルトで各ノードのkubeletも匿名リクエストを許可している。攻撃者がkubelet APIに完全にアクセスしてしまうと、ポッドでコマンドを実行したり、特権を昇格でしたりきる可能性があるため、CISベンチマークではこれらの設定を無効にすることが推奨されている。

　APIサーバとkubeletが匿名アクセスを許可している場合、監査ログにあるusernameおよびgroups属性には、それぞれsystem:anonymousおよびsystem:unauthenticatedと表示される。

　これらのタイプのコールが表示される場合トラブルシューティングを行い、自社環境でこの設定を無効にする必要があるかどうかを判断してほしい。この問題の影響を緩和するために、匿名アクセスを無効にし、ロールベースのアクセス制御（RBAC）ポリシーを確認して、正しく設定されていることを見直す。

　マネージドKubernetesサービス（「Google Kubernetes Engine」「Amazon Elastic Kubernetes Service」など）では、通常、匿名アクセスが無効になっているが、念のために確認してほしい。匿名リクエスト（匿名リクエストの拒否も含む）が急増している場合、攻撃者が kubeletとAPIサーバを調査して、どのような種類のサービスデータを取得できるかを探っている可能性があるからだ。

ポッドでの任意のコマンドの実行
クラスタ、ネームスペース、またはネームスペースのポッドからのシークレットの取得

　攻撃者は、kubeletとAPIサーバにアクセスできることを知ると、ポッドで対話型シェルを開始したり、kubectlからシークレットを表示したりして、アクセスできる範囲を広げられるかどうかを確認し、任意のコマンドを実行することが多々ある。許可されていないIPアドレスが（sourceIPs、username、およびgroup監査ログ属性）、ポッドのディレクトリの一覧表示など（requestURIおよびverb属性から判断する）のコマンドを実行している場合、攻撃者が既に自社環境にアクセスしており、Kubernetesリソースを作成、変更、または制御する方法を見つけている恐れがある。この場合の対処法については、次のセクションで説明する。

Kubernetesリソースの変更

　自社環境が変更された場合でも、必ずしも悪意のあるアクティビティが実行されているわけではないが、そのアクティビティが通常とは異なるIPアドレスやサービスアカウントから実行されている場合は、モニタリングすることが重要だ。攻撃者が、自社のクラスタをさらに制御しようとしている場合、一般的に次のようなアクティビティが確認される。

設定されているネームスペースでのポッドの作成
センシティブマウント（sensitive mount）によるポッドの作成
ホストネットワークへのポッドのアタッチ

　攻撃者は多くの場合、ホストネットワークにポッドをアタッチしたり、kube-systemやkube-publicなど、設定されているネームスペースに新しいポッドを作成できるサービスアカウントを探したり、新しいアカウントを作成しようとしたりする。これにより、ネームスペースの他のポッドとの通信、特権付きコンテナがあるポッドの作成、ノードでhostPathボリュームをマウントしてホストのファイルシステムに無制限にアクセスすること、そして、DaemonSetをデプロイしてクラスタの各ノードを簡単に制御することが可能になる。

　同じサービスアカウントやIPアドレスがノード上で新しいポッドやホストマウントを作成していることに気づいた場合、そのアカウントに過剰な権限が付与されていないか確認するか、Pod Security Policyなどのアドミッションコントローラーをアップデートして、使用できるポッドの機能を制限する必要がある。特権付きのコンテナは、権限昇格などの他のさまざまな攻撃に利用されることが多く、攻撃者にとって特に価値の高いものだ。

アカウントのアクティビティ

　攻撃者は権限を昇格して、Kubernetesリソースを制御する場合がある。この手法では、リソースに完全にアクセスできる昇格した特権がある新規アカウントを作成したり、既存アカウントを変更したりする操作が多く見られる。

　以下のアクティビティをモニタリングすることで、アカウント権限の変更や管理者特権のある新しいアカウントの作成を特定できる。

アカウントへの cluster-adminロールのアタッチ

　RBACポリシーにおけるcluster-adminのロールは、全てのリソースに対するスーパーユーザーアクセスの権限をアカウントに付与する。原則として、アカウントには特定のタスクを実行するために必要な権限のみを付与すべきであり、通常のアカウントではこのレベルの高位のアクセス権限は不要である。サービスアカウントの監査ログで、そのアカウントがcluster-adminロールを使用していることを示している場合、そのアカウントにこのロールが本当に必要かどうかを確認する必要がある。

　アカウントにcluster-adminロールにアタッチするClusterRoleBindingを作成しようとする動きもモニタリングする必要がある。このロールバインディングが設定されているアカウントは、クラスタ内の全てのリソースと全てのネームスペースを完全に制御できる。監査ログにこのアクティビティが表示される場合、アカウントが侵害されていないことを確認するためにさらに調査する必要があり、これらの情報は全て、監査ログのauthorization.k8s.io/reason属性で確認できる。