ClickHouseがDocker Hardened Imagesを提供、最小構成で攻撃面を縮小

ClickHouseは、ClickHouse Server、Keeper、Kubernetes OperatorとHelmチャート、エクスポーター向けのDocker Hardened Imagesを提供しました。不要なパッケージを減らし、特権を持たないユーザー実行と供給網の証跡を標準化します。

要点

• パッケージマネージャーや一般的なネットワークツールを本番イメージから除き、攻撃面を小さくしています。
• 特権を持たないユーザー実行、継続的な修正、SLSA Build Level 3の由来証明を掲げています。
• 公式比較では標準イメージの111パッケージに対する8件の中程度、11件の低重要度から、DHIは中程度 0件、低重要度 14件となりました。
• データベースの設定、ボリューム、基本動作は維持されますが、別レジストリの認証とミラー手順が必要です。

今回のブログ記事で語られていること

コンテナ化したデータベースは、ClickHouse本体だけでなく、OSパッケージ、シェル、パッケージマネージャー、診断ツールまで脆弱性管理の対象になります。Docker Hardened Imagesは、本番実行に不要な部品を削り、既定で特権を持たないユーザーとして動かし、ビルド元を追跡できる由来証明を付けた配布物です。ClickHouse Serverだけでなく、分散構成の調整に使うKeeper、Kubernetes OperatorとHelmチャート、監視用エクスポーターまで対象にしているため、周辺コンポーネントを含む基盤全体で同じ方針を取りやすくなります。

公式記事のスキャン例では、標準イメージに111のパッケージがあり、8件の中程度と11件の低重要度が検出されました。DHIでは中程度が0件、低重要度が14件で、残る低重要度は修正できない中核ライブラリ由来と説明されています。この数値は特定時点のスキャナー結果であり、将来の脆弱性ゼロを保証しません。また、パッケージ数が少ないこととClickHouseの設定が安全であることは別です。ネットワーク公開範囲、認証、TLS、ユーザー権限、秘密情報、バックアップは従来どおり管理する必要があります。

データベースの設定やボリュームの扱いを変えずに移行できる設計ですが、運用方法は一部変わります。本番イメージにはシェルやネットワークツールがないため、障害時にコンテナへ入って直接調査する手順は使えない場合があります。開発用バリアントやdocker de不具合を安全に使う手順を決め、診断用コンテナへ本番の秘密情報を広げないことが重要です。また、DHIは別レジストリから配布されるため、認証、プルスルーキャッシュ、隔離環境環境へのミラー、ダイジェスト固定、更新通知をCI/CDへ組み込む必要があります。

今回のブログ記事が関係する人

ClickHouseをコンテナやKubernetesで運用するSRE、イメージ脆弱性を管理するセキュリティ担当、ソフトウェア供給網とレジストリを管理するプラットフォームチームに関係します。

結局、今回のブログ記事をどう読むべきか

脆弱性対応の負担を減らす配布選択肢ですが、置き換えるだけで安全が完成するわけではありません。ダイジェストを固定した検証、ボリューム互換、特権を持たないユーザー権限、監視、障害調査、ミラー更新を試してから段階的に切り替えてください。