【ITニュース解説】cAdvisor: 134,520 pages name it, 13,948 answer on 8080, and no fingerprint exists to check against

現代のITシステムにおいて、アプリケーションを効率的に動かすために「コンテナ」という技術が広く使われている。コンテナは、アプリケーションとその実行に必要なものをまとめて隔離する技術で、まるで小さな仮想的な箱の中でアプリが動いているようなものだ。そして、このコンテナの動きを監視し、その状況を教えてくれる重要なツールの一つに「cAdvisor（シーアドバイザー）」がある。cAdvisorは、コンテナがどれくらいのCPUやメモリを使っているか、ネットワークの状況はどうなっているかなど、システムの健全性を把握するために不可欠な情報を収集する。

cAdvisorは、コンテナを管理するシステムである「Kubernetes（クーバネティス）」と連携して使われることが多いが、単独でホスト（サーバー）にインストールすることも可能だ。通常はバックグラウンドで動作し、Webブラウザからアクセスできる簡易的なインターフェースをポート8080で提供する。システムエンジニアにとって、このcAdvisorが提供する情報は、問題発生時の原因特定や、システム全体のパフォーマンス改善に役立つ貴重なデータ源となる。

しかし、今回の調査で、このcAdvisorの普及と、それに伴う意外なセキュリティ上の盲点が明らかになった。インターネット上のデバイスやサービスを検索する特殊な検索エンジン「ZoomEye」を使った調査では、まず「cAdvisor」というタイトルを持つWebページを検索すると、約13万件もの結果が見つかった。だが、「cAdvisor」という厳密な文字列をタイトルに持つものや、アプリケーションとして「cAdvisor」と識別されるものはほとんど存在しないことも判明した。これは、cAdvisorが公式の製品ページのような厳密なWebタイトルを持たないことや、ソフトウェアの識別情報が登録されたデータベースに十分に分類されていないことを示している。

しかし、「cAdvisor」というタイトルで、かつデフォルトで使用されるポート8080で応答するシステムを絞り込んで検索すると、約1万4千件のシステムがヒットした。これは、実際にインターネット上に公開されており、cAdvisorが稼働している可能性が高いシステムの数を示唆している。この数字は、cAdvisorが非常に広範に利用されている一方で、その存在が明確に分類・認識されていないという現状を浮き彫りにする。

cAdvisorが収集する情報には、コンテナの名前、使用しているイメージ（コンテナの元となるプログラムの設計図）、データが保存されている場所（ボリュームパス）、設定情報（ラベル）、そして実行中のプロセスの詳細などが含まれる。これらは、システム管理者がシステムの全体像を把握し、どこにどのようなデータがあり、どのようにアプリケーションがデプロイされているかを理解するために非常に有用な「インベントリ情報」だ。しかし、見方を変えれば、これらの情報はシステムの内部構造を詳細に開示することになり、悪意のある第三者に知られた場合、攻撃の足がかりにされかねない。

特に懸念されるのが、cAdvisorが持つ「プロファイリングエンドポイント」という機能だ。これは、システムのパフォーマンスを詳細に分析するためのデバッグ機能で、通常は開発者や運用者が問題解析のために利用する。この機能は、設定フラグ（--profiling=false）で無効にできるものの、デフォルトで有効になっている場合、cAdvisorのWebインターフェースと同じポート8080で公開されてしまう可能性がある。デバッグ用のエンドポイントは、本来のサービスよりも多くの詳細な情報を提供する傾向があり、過去にもこのような機能がセキュリティ上の脆弱性につながった事例は少なくない。意図せず公開された場合、システムの内部情報が容易に漏洩するリスクを抱えることになる。

cAdvisorは、通常、コンテナのメトリクス（性能指標）を収集し、「Prometheus（プロメテウス）」のような監視ツールに送るために導入されるため、多くの場合は正当な理由で利用される。しかし、「内部システム用」として認証なしでデプロイされることが多く、「内部」という言葉の解釈に誤解が生じやすい。本来「内部向け」とは、ネットワーク的に外部からアクセスできない設定（例えば、特定のプライベートなネットワークインターフェースにのみ接続を許可する設定）を指すべきだ。単に「内部で使うつもり」という意図だけで、全てのネットワークインターフェースからのアクセスを許可する設定（「any-address binding」）にしてしまうと、意図せず外部に公開され、誰でも認証なしでcAdvisorの情報にアクセスできるようになってしまう。プラットフォームチームがcAdvisorの管理を担当する一方で、セキュリティレビューの対象外となりがちなことも、この問題の背景にある。

このようなリスクを防ぐため、システムエンジニアは以下の点を常に確認する必要がある。 まず、cAdvisorがどのネットワークインターフェースからの接続を受け入れているか（リスナーのバインディング）を確認する。Prometheusからのデータ収集は特定のIPアドレスから行われるため、全てのインターフェースにバインドする必要はなく、プライベートなインターフェースに限定すべきだ。次に、cAdvisorのアクセスに対して何らかの認証機構が導入されているかを確認する。内部システムであっても、不必要な情報公開を防ぐために認証は重要である。さらに、デバッグ用のプロファイリングエンドポイントは、本当に必要な場合を除き無効にするか、アクセスできるネットワークを厳しく制限すべきだ。そして、同じホスト上で顧客のアプリケーションとプラットフォームサービスの両方が動作している場合、cAdvisorが不必要に多くのコンテナの情報にアクセスしていないか、その可視性を分離できているかを確認することも重要である。

最後に、cAdvisorのようなシステムも重要な「資産」としてきちんと管理することが求められる。具体的には、どのホストで、どのネットワークアドレスとポートで動作しているか、プロファイリング機能が有効になっているか、どの監視システムからのデータ収集が許可されているかといった情報を明確に記録すべきだ。また、cAdvisorへの異常なアクセスや、デバッグパスへのリクエストがあった場合には、それを検知できるようにアクセスログを適切に設定し、監視する体制を整える必要がある。多くのシステムでは、監視ポートへのアクセスログは重要ではないとみなされ、破棄されてしまうことが多いが、これでは異常を早期に発見できない。

今回の調査結果は、システムエンジニアが「非常に一般的でありながら、その存在が厳密には認識されていない」ツールに対して、特に注意を払うべきであることを示している。単に便利なツールとして導入するだけでなく、その設定がどのような情報を公開し、どのようなセキュリティリスクを潜在的に抱えているかを深く理解し、適切な対策を講じることが、これからのシステム開発と運用において不可欠となるだろう。