セキュリティモデル

以下の技術的な詳細に入る前に、Prometheus は監視システムとして、監視対象システムの情報を収集・提供することに焦点を当てていることを強調しておきます。したがって、Prometheus コンポーネントが提供する HTTP エンドポイントは、インターネットのような公開ネットワークに公開されるべきではありません(ただし、それを理解し、適切な対策を講じている場合を除きます)。これには、インストルメント化されたバイナリの /metrics エンドポイント、サーバーコンポーネントの各種 API エンドポイント、Go で実装されたサーバーコンポーネントの /pprof エンドポイントなどが含まれます(ただし、これらに限定されません)。さらに、これらのエンドポイントへのリクエストにより、サーバーを簡単に過負荷にし、最終的に DoS 攻撃につながる可能性があります。

Prometheus は、多くのコンポーネントと他のシステムとの多くの統合を持つ洗練されたシステムです。信頼できる環境と信頼できない環境の両方でデプロイできます。

このページでは、Prometheus の一般的なセキュリティ上の前提条件と、一部の設定で有効になりうる攻撃ベクトルについて説明します。

あらゆる複雑なシステムと同様に、バグが見つかることはほぼ確実であり、その中にはセキュリティに関連するものも含まれます。

すでに公開されている(例:公開 CVE 経由) セキュリティバグ で、依存関係のバージョンアップだけでは修正できないものについては、関連するリポジトリの MAINTAINERS に記載されている情報に加え、まだ報告されていない場合は、バグレポート を開いて、関連するすべての詳細を提供してください。

まだ公開されていない セキュリティバグ を発見した場合は、関連リポジトリの MAINTAINERS に記載されているメンテナーにプライベートに報告し、[email protected] に CC してください。可能な限り早く問題を修正し、あなたとリリース日を調整します。あなたの努力に対する公開承認や、氏名での言及を希望するかどうかを選択できます。

ほとんどの依存関係のバージョン更新は自動的に処理されます。しかし、セキュリティバグ の修正が依存関係のバージョン更新のみを必要とし、自動化が見逃した場合、直接更新を送信していただいても構いません。

自動セキュリティスキャナー

セキュリティスキャナーユーザーへの特別な注意:生成されたレポートには注意してください。ほとんどのスキャナーは汎用的であり、多くの誤検知を生成します。私たちにはますます多くのレポートが送られてきており、それらをすべて確認し、期待される丁寧さで返信するのにかなりの作業が必要です。この問題は、特に Go と NPM の依存関係スキャナーで顕著です。

私たちと私たちの時間の配慮として、生のレポートを提出しないようお願いいたします。代わりに、どの具体的な結果が私たちに関連し、なぜそうなのかを説明する分析とともに提出してください。

また、オープンソースプロジェクトであるため、一般的に商用スキャンツールへのアクセスがなく、それらの出力がしばしば誤解を招くか、あるいは単に間違っていることに注意してください。Go コードの場合、影響を受けていると思われるバージョンのソースコード(バイナリではなく、完全な分析ができないため)で、オープンソースのgovulncheck ツールで再現しない場合、発見内容を再確認する(そのコードが Prometheus コードベース内で実際に到達可能であるかどうかも含む)ようお願いいたします。

Prometheus は会社ではなく、ボランティアによって維持されています。したがって、セキュリティ問題の修正はベストエフォートで行われます。Prometheus、Alertmanager、Node Exporter、Blackbox Exporter、Pushgateway については、7 日以内にセキュリティ修正をリリースするよう努めています。

Prometheus

信頼されていないユーザーが Prometheus HTTP エンドポイントとログにアクセスできると想定されます。彼らはデータベースに含まれるすべての時系列情報、およびさまざまな運用/デバッグ情報にアクセスできます。

また、コマンドライン、設定ファイル、ルールファイル、および Prometheus およびその他のコンポーネントの実行環境のその他の側面を変更できるのは、信頼されたユーザーのみであると想定されます。

Prometheus がスクレイプするターゲット、その頻度、およびその他の設定は、すべて設定ファイルによって決定されます。管理者は、サービスディスカバリシステムからの情報を使用することを決定する場合があります。これは、リラベリングと組み合わせることで、そのサービスディスカバリシステム内のデータを変更できるあらゆる人に、これらの制御の一部を付与する可能性があります。

スクレイプされたターゲットは、信頼されていないユーザーによって実行される可能性があります。デフォルトでは、ターゲットが別のターゲットを偽装するデータを公開できるようなことはないはずです。honor_labels オプションは、特定のリラベリング設定と同様に、この保護を削除します。

Prometheus 2.0 以降、--web.enable-admin-api フラグは、時間系列の削除などの機能を含む管理 HTTP API へのアクセスを制御します。これはデフォルトで無効になっています。有効にすると、管理機能は /api/*/admin/ パスでアクセス可能になります。--web.enable-lifecycle フラグは、Prometheus の HTTP リロードとシャットダウンを制御します。これもデフォルトで無効になっています。有効にすると、/-/reload および /-/quit パスでアクセス可能になります。

Prometheus 1.x では、/-/reload および /api/v1/series に対する DELETE の使用は、HTTP API にアクセスできるすべてのユーザーが利用できます。/-/quit エンドポイントはデフォルトで無効になっていますが、-web.enable-remote-shutdown フラグで有効にできます。

Remote read 機能により、HTTP アクセス権を持つすべてのユーザーがリモート読み取りエンドポイントにクエリを送信できます。例えば、PromQL クエリがリレーショナルデータベースに対して直接実行される場合、Prometheus にクエリを送信できるユーザー(Grafana 経由など)は、そのデータベースに対して任意の SQL を実行できます。

Alertmanager

Alertmanager HTTP エンドポイントにアクセスできるユーザーは、そのデータにアクセスできます。アラートを作成したり解消したりできます。サイレンスを作成、変更、削除できます。

通知の送信先は、設定ファイルによって決まります。特定のテンプレート設定では、通知がアラート定義の宛先に到達する可能性があります。例えば、通知がアラートラベルを宛先メールアドレスとして使用する場合、Alertmanager にアラートを送信できるユーザーは、任意のアドレスに通知を送信できます。アラート定義の宛先がテンプレート可能なシークレットフィールドの場合、Prometheus または Alertmanager にアクセスできるユーザーは、シークレットを表示できます。

テンプレート化可能なシークレットフィールドは、上記のユースケースで通知をルーティングするためのものです。テンプレートファイル機能を使用してシークレットを構成ファイルから分離するためのものではありません。テンプレートファイルに保存されたシークレットは、Alertmanager 設定ファイルでレシーバーを構成できるユーザーであれば誰でも抽出できる可能性があります。例えば、大規模なセットアップでは、各チームが完全に制御できる Alertmanager 設定ファイルフラグメントを持ち、それらが完全な最終設定ファイルに結合される場合があります。

Pushgateway

Pushgateway HTTP エンドポイントにアクセスできるユーザーは、含まれるメトリックを作成、変更、削除できます。Pushgateway は通常 honor_labels を有効にしてスクレイプされるため、Pushgateway にアクセスできるユーザーは Prometheus に任意の時系列を作成できます。

--web.enable-admin-api フラグは、既存のすべてのメトリックグループをワイプするなどの機能を含む管理 HTTP API へのアクセスを制御します。これはデフォルトで無効になっています。有効にすると、管理機能は /api/*/admin/ パスでアクセス可能になります。

エクスポーター

エクスポーターは一般的に、設定されたコマンド/リクエストのセットを持つ単一の設定インスタンスとしか通信しません。これは HTTP エンドポイントから拡張することはできません。

また、SNMP エクスポーターや Blackbox エクスポーターのように、URL パラメータからターゲットを取得するエクスポーターもあります。したがって、これらのエクスポーターへの HTTP アクセス権を持つユーザーは、それらを任意のエンドポイントにリクエストを送信させることができます。クライアントサイド認証もサポートしているため、HTTP Basic Auth パスワードや SNMP コミュニティ文字列などの機密情報の漏洩につながる可能性があります。TLS のようなチャレンジ・レスポンス認証メカニズムはこの影響を受けません。

クライアントライブラリ

クライアントライブラリは、ユーザーのアプリケーションに含めることを目的としています。

クライアントライブラリ提供の HTTP ハンドラを使用する場合、そのハンドラに到達する悪意のあるリクエストは、追加の負荷やスクレイプ失敗から生じる問題以上の問題を引き起こすことはないはずです。

認証、認可、および暗号化

Prometheus、およびほとんどのエクスポーターは TLS をサポートしています。TLS クライアント証明書によるクライアント認証も含まれます。Prometheus の設定に関する詳細は、こちら にあります。

Go プロジェクトは、Go の crypto/tls ライブラリに基づいた同じ TLS ライブラリを共有しています。デフォルトで TLS 1.2 を最小バージョンとしています。このポリシーは、Qualys SSL Labs の推奨事項に基づいており、デフォルト設定と正しく提供された証明書でグレード 'A' を達成することを目指しつつ、アップストリーム Go のデフォルトに可能な限り近づけています。このグレードを達成することは、完璧なセキュリティと使いやすさのバランスを提供します。

Java エクスポーターには、将来的に TLS が追加される予定です。

異なる暗号スイートや古い TLS バージョンなど、特別な TLS ニーズがある場合は、暗号が安全でないとマークされていない 限り、最小 TLS バージョンと暗号スイートを調整できます。それでも満足できない場合は、現在の TLS 設定により、より特別な要件を持つサーバーとリバースプロキシの間に安全なトンネルを構築できます。

HTTP Basic Authentication もサポートされています。Basic Authentication は TLS なしで使用できますが、その場合、ネットワーク上でユーザー名とパスワードが平文で公開されます。

サーバー側では、Basic Authentication のパスワードはbcrypt アルゴリズムでハッシュとして保存されます。セキュリティ基準に合ったラウンド数を選択するのは、あなたの責任です。ラウンド数が多いほど、パスワード認証にかかる CPU パワーと時間は増加しますが、ブルートフォース攻撃はより困難になります。

さまざまな Prometheus コンポーネントは、クライアントサイド認証と暗号化をサポートしています。TLS クライアントサポートが提供されている場合、SSL 検証をスキップする insecure_skip_verify というオプションもよくあります。

API セキュリティ

管理および変更を伴うエンドポイントは、curl のような単純なツールでアクセスされることを意図しているため、CSRF 保護は組み込まれていません。そのようなユースケースを壊してしまうためです。したがって、リバースプロキシを使用する場合は、CSRF を防ぐためにこれらのパスをブロックしたい場合があります。

変更を伴わないエンドポイントについては、CORS ヘッダー(例:Access-Control-Allow-Origin)をリバースプロキシに設定して、XSS を防ぐことを検討してください。

信頼されていないユーザー(例:コンソールテンプレートの URL パラメータ、または自身で構築したもの)から入力を含む PromQL クエリを構成しており、そのユーザーが悪意のある PromQL クエリを実行できないようにしたい場合は、任意の信頼されていない入力を適切にエスケープして、インジェクション攻撃を防ぐようにしてください。例えば、up{job="<user_input>"} は、<user_input>"} or some_metric{zzz=" の場合、up{job=""} or some_metric{zzz=""} のようになります。

Grafana を使用している方へ:ダッシュボードの権限はデータソースの権限ではありません。したがって、プロキシモードでのユーザーの任意のクエリ実行能力を制限しないでください。

シークレット

HTTP API および/またはログ経由で、シークレットではない情報やフィールドが利用可能になる場合があります。

Prometheus では、サービスディスカバリから取得したメタデータはシークレットとは見なされません。Prometheus システム全体で、メトリックはシークレットとは見なされません。

設定ファイル内のシークレットを含むフィールド(ドキュメントで明示的にマークされているもの)は、ログや HTTP API 経由では公開されません。コンポーネントが HTTP エンドポイント経由で設定を公開することは一般的であるため、シークレットを他の設定フィールドに配置しないでください。ディスク上のファイルを不正な読み書きから保護するのは、ユーザーの責任です。

依存関係によって使用される他のソースからのシークレット(例:EC2 サービスディスカバリで使用される AWS_SECRET_KEY 環境変数)は、制御外のコードや、保存されている場所を偶然公開する機能により、公開される可能性があります。

サービス拒否

過剰な負荷や高コストなクエリに対する緩和策はいくつか用意されています。しかし、あまりにも多くのクエリや高コストなクエリ/メトリックが提供された場合、コンポーネントは停止します。悪意のある行為よりも、信頼されたユーザーが誤ってコンポーネントを停止させる可能性の方が高いです。

CPU、RAM、ディスク容量、IOPS、ファイルディスクリプタ、帯域幅を含む十分なリソースをコンポーネントに提供することを保証するのは、ユーザーの責任です。

すべてのコンポーネントの障害を監視し、障害発生時に自動的に再起動するように設定することを推奨します。

ライブラリ

このドキュメントでは、標準ソースコードからビルドされたバニラバイナリを対象としています。ここに記載されている情報は、Prometheus ソースコードを変更した場合、または Prometheus 内部(公式クライアントライブラリ API を除く)を独自のコードで使用した場合には適用されません。

ビルドプロセス

Prometheus のビルドパイプラインは、Prometheus 開発チームの多くのメンバーとそれらのプロバイダーのスタッフがアクセスできるサードパーティプロバイダーで実行されます。バイナリの正確な出所が気になる場合は、プロジェクトが提供する事前ビルドバイナリに依存するのではなく、ご自身でビルドすることをお勧めします。

Prometheus-Community

Prometheus-Community organization のリポジトリは、サードパーティのメンテナーによってサポートされています。

Prometheus-Community organization の セキュリティバグ を発見した場合は、関連リポジトリの MAINTAINERS に記載されているメンテナーにプライベートに報告し、[email protected] に CC してください。

この organization の一部のリポジトリは、このドキュメントで提示されているものとは異なるセキュリティモデルを持っている場合があります。その場合は、それらのリポジトリのドキュメントを参照してください。

外部監査

このページの内容