DevOps & Platform Eng

ClickHouse Dockerセキュリティ:DHIがエンタープライズの壁を突破

アプリが全く使わないパッケージに脆弱性が見つかったからという理由で、せっかく作ったコンテナデプロイがセキュリティスキャナーに却下された経験はないだろうか?これはエンタープライズでよくある頭痛の種だ。そこに、今、Docker Hardened Images (DHI) が、特に人気の高いClickHouseを皮切りに、有望な解決策を提示している。

{# Always render the hero — falls back to the theme OG image when article.image_url is empty (e.g. after the audit's repair_hero_images cleared a blocked Unsplash hot-link). Without this fallback, evergreens with cleared image_url render no hero at all → the JSON-LD ImageObject loses its visual counterpart and LCP attrs go missing. #}
ClickHouseのレイヤー化されたアーキテクチャを示す図。

Key Takeaways

  • エンタープライズのセキュリティスキャンでは、アプリケーション自体ではなく、使用されていないベースイメージのパッケージに含まれるCVEが原因で、デプロイがブロックされることがよくある。
  • Docker Hardened Images (DHI) は、アプリケーションに必要な必須コンポーネントのみを提供することで、攻撃対象領域を劇的に削減する。
  • イメージ構築におけるこのミニマリストアプローチは、プロアクティブなセキュリティとデプロイメント効率に向けた重要なシフトを表している。

セキュリティチームが、コードの不備ではなく、コンテナのベースイメージにある、どうでもいいようなパッケージが大きなCVEフラグを立てているせいで、デプロイに待ったをかけたときの、あの衝撃を味わったことはないだろうか?それは、フォーマルな夜会に、ちょっとカジュアルすぎるアロハシャツで現れるようなものだ——着てはいるが、ゲストリストに載ることはまずないだろう。

これは絵空事ではない。昨年11月、シャープなLLMオブザーバビリティプラットフォームであるLangfuseをセルフホストしているチームが、Kubernetes上でClickHouseデータベースを本番運用する準備をしていたまさにその時、この壁にぶち当たった。ClickHouseイメージをAWS ECRにアップロードしたところ、なんと3つの重大な脆弱性が検出されたのだ。ClickHouse自体ではなく、ベースイメージに潜んでいたものだ。彼らのセキュリティチームは、その勤勉さゆえに、スキャナーのレポートを見て「絶対ダメ」と一蹴した。

この記事では、Docker Hardened Images (DHI) が、この終わりのないデプロイメントの limbo 状態から我々をどう救い出そうとしているのか、その全貌に迫る。DHIのアプローチを、広く使われているClickHouseデータベースイメージを主軸に、深く掘り下げていこう。

ClickHouse:無視できない分析の巨人

まず、ClickHouse自体について少し触れておこう。大規模な本格的な分析を行うなら、ClickHouseを知らないはずがない。このオープンソースの列指向データベースは、まさに怪物だ。数十億行のデータを平らげ、ミリ秒単位で結果を吐き出す。従来の行指向データベースは忘れよう。ClickHouseはスピードのために作られた。Cloudflare、Uber、Spotifyといった企業が本番運用しており、Docker Hubから1億回以上プルされていることから、深刻な分析スループットを必要とするあらゆる環境で、事実上のインフラ選択肢となっている。しかし、問題は常にそのデフォルトのセキュリティ姿勢にあった——開発者の利便性のために作られており、エンタープライズの本番環境が要求する鉄壁の強化には至っていない。そして、ここに我々の現在の苦境の根源がある。

見えない肥大化:ベースイメージこそ真の悪党

標準のclickhouse/clickhouse-serverイメージは、その善意にもかかわらず、フルUbuntu 22.04ベースで構築されている。Ubuntuは素晴らしいOSだが、ClickHouseのような高度に特化したデータベースにとっては、満載のキッチンをピクニックに持っていくようなものだ。ClickHouseが全く必要としないものが山ほど含まれている:Perl、完全なパッケージマネージャー(apt)、数え切れないほどのシステムユーティリティ、そして連鎖する依存関係の数々。これらのパッケージの多くは、アップストリームのメンテナーからセキュリティバックポートを長らく受けていない。

ClickHouseはその焦点の定まった輝きで、これらのほとんどにほとんど触れることすらない。それなのに、それらのパッケージのCVEは紛れもなく実在する。TrivyやGrypeのようなスキャナーは、忠実にそれらをフラグ付けする。AWS ECRは、その公平で論理的な方法で、ただそこにあり、不活性な脆弱なライブラリと、積極的に悪用されているライブラリを区別できない。セキュリティチームは赤信号を見て、まったく正しく、デプロイをブロックする。彼らは、スキャナーが提供する情報に基づいて、その職務を遂行しているのだ。

確かに、英雄的な防御を試みたくなるだろう:巧妙なリスク例外文書を作成し、あなたの特定のワークロードが、パッチ未適用のCVE-2021-31879を持つあの古いwgetライブラリに決して触れることはない、というエッセイを書く。それは消耗し、時間のかかるプロセスだ。このカフカ的な悪夢全体を回避する唯一の真の解決策は、それらの不要なパッケージを単純に削除することだ。そして、それがまさに、Docker Hardened Images (DHI) が目指していることなのだ。

DHI:最小限の必須要素まで徹底的に剥ぎ取る

では、DHIは何をしてその価値を証明するのか?それは、見かけはシンプルだが、非常に影響力の大きい問いから始まる:「データベースが実際に実行するために何が必要か?」広範囲で機能豊富なUbuntuベースから始め、CVE数を管理可能に保とうと期待するのではなく、DHIはClickHouseに必要なものだけを慎重に船に乗せる。それ以外は?すべて削除だ。

このミニマリストアプローチの最も直接的で、率直に言って、素晴らしい結果は何か?実行時にaptが存在しないことだ。攻撃者がコンテナに侵入したと想像してみよう。組み込みのパッケージマネージャーがなければ、悪意のあるツールのインストールや永続的な足場を築くための選択肢は大幅に限定される。curlwgetのようなネットワークユーティリティも、同様のセキュリティ意識の高い理由で削除されている。

しかし、DHIは明白な攻撃ベクターの削除だけで終わらない。それはさらに深く進み、ベースOSや他のツールによって使用されているかもしれないが、ClickHouseのコア機能には全く無関係なライブラリを特定し、削除する。これは単にイメージサイズを縮小すること(それが魅力的な特典であることは確かだが)だけではない。これは攻撃対象領域を劇的に削減し、デプロイメントを本質的により回復力のあるものにし、そして最も重要なことに、厳格なエンタープライズセキュリティ環境内でデプロイ可能にするためのものだ。

こう考えてみてほしい。標準イメージは、完全に家具が備え付けられた家だ。考えうる限りのものすべてが揃っており、さらに必要ないものもたくさんある。DHIイメージは?それは、快適に暮らすための必須コンポーネントだけで構築された、綿密に設計されたミニマリストの聖域だ。そしてセキュリティチームにとって、その聖域ははるかに魅力的に見えるだろう。

標準のclickhouse/clickhouse-serverイメージは、フルUbuntu 22.04ベースで構築されている。このベースには、Perl、システムユーティリティ、apt自体、そしてUbuntuが古いパッケージを持ち込んだために存在する数十の連鎖依存関係など、ClickHouseが不要とするものが数多く含まれている。多くの場合、Ubuntuのメンテナーはアップストリームからの修正をバックポートしないことを決定している。

この必要性への執拗な焦点は、DHIイメージが従来のイメージのほんの一部になることを意味する。より小さなイメージは、より高速なプル、より迅速なデプロイ、そして脆弱性の潜在的なフットプリントの縮小を意味する。それは効率化のプレイであり、同時にセキュリティの傑作でもある。

これによる影響は計り知れない。開発者にとっては、セキュリティ例外の処理に費やす時間が減り、機能構築に費やす時間が増える。セキュリティチームにとっては、よりクリーンなレポートと、デプロイされたアプリケーションに対する信頼の向上を意味する。それは共生関係であり、ついに調和を見出したのだ。すべては、よりインテリジェントなイメージ構築アプローチのおかげだ。

なぜこれが重要なのか:プラットフォームシフトの到来

これは単なる強化されたClickHouseイメージの話ではない。これは、ソフトウェアデプロイメントについての我々の考え方に根本的なプラットフォームシフトを示す信号であり、灯台だ。長年、我々はベースOSレイヤーを必要悪、基本的にそのまま受け入れるべき基盤コンポーネントだと考えてきた。これらの基盤レイヤーにおけるCVEの蔓延は、DevOpsの世界で絶え間ない、低レベルの不安の唸りとなっている。

DHI、そしてそれが表す哲学は、その前提に正面から挑戦している。それは、ベースイメージは容認すべき静的なエンティティではなく、それをホストする特定のアプリケーションのために積極的に最適化できる、いやされるべき、柔軟なコンポーネントであると主張している。これはインフラストラクチャに適用されたAI的思考だ——コアなニーズを特定し、それ以外のすべてを容赦なく最適化する。

我々は、ベースイメージのセキュリティ債務を受け入れるモデルから、それを排除するモデルへと移行している。これは単なるわずかな改善ではない。それは飛躍であり、モノリシックアプリケーションからマイクロサービスへの移行、あるいはオンプレミスサーバーからクラウドネイティブアーキテクチャへの移行に匹敵する。それは、我々のアプリケーションが構築され、デプロイされる基盤となる基盤の根本的な変化なのだ。

未来はリーンでパワフル

AIが我々のテックスタックのあらゆるレイヤーに浸透し続けるにつれて、このようなインテリジェントな最適化がさらに増えるだろう。AIを活用したビルドシステムを想像してみてほしい。それは、特定のアプリケーションイメージから不要なコンポーネントを動的に剥ぎ取り、その特定の実行ニーズとセキュリティポリシーに合わせて調整するものだ。ClickHouse向けのDHIは、この未来が今日繰り広げられている強力で具体的な例だ。それは、セキュリティが後付けではなく、インフラストラクチャ自体の固有の特性となる未来だ。デプロイメントがブロックされるのではなく、安全で、世界が何を投げつけてきても対応できる状態ですり抜けていく未来だ。そして、あらゆる開発者やOpsエンジニアにとって、それは興奮する価値のある未来なのだ。

**


🧬 関連インサイト

よくある質問**

Docker Hardened Image (DHI) とは具体的に何ですか? DHIは、アプリケーションの実行に必要な最小限のコンポーネントセットで構築されたコンテナイメージであり、攻撃対象領域と脆弱性の可能性を劇的に削減します。

DHIイメージは起動が遅くなりますか? 一般的に、いいえ。不要なオーバーヘッドを削除し、イメージサイズを縮小することで、DHIイメージは肥大化した従来のイメージよりもプルや起動が速くなることがよくあります。

これはClickHouse専用ですか? DHIは多くのアプリケーションに適用できる方法論ですが、この記事では特にClickHouseへの実装に焦点を当てています。

Alex Rivera
Written by

Developer tools reporter covering SDKs, APIs, frameworks, and the everyday tools engineers depend on.

Worth sharing?

Get the best Developer Tools stories of the week in your inbox — no noise, no spam.

Originally reported by Docker Blog