Prometheusは、多くのコンポーネントと他のシステムとの多くの統合を備えた高度なシステムです。信頼できる環境と信頼できない環境の両方で展開できます。
このページでは、Prometheusの一般的なセキュリティ上の前提と、一部の設定によって有効になる可能性のある攻撃ベクトルについて説明します。
あらゆる複雑なシステムと同様に、バグが見つかる可能性があり、その中にはセキュリティ関連のバグも含まれます。 *セキュリティバグ* を発見した場合は、関連するリポジトリのMAINTAINERSに記載されているメンテナに非公開で報告し、[email protected] にCCしてください。できるだけ早く問題を修正し、リリース日について調整します。ご尽力の公表の有無、氏名表記の有無を選択いただけます。
セキュリティスキャナーのユーザーへの特別な注意：生成されたレポートに注意してください。ほとんどのスキャナーは汎用的なため、多くの誤検知が発生します。ますます多くのレポートが送信されており、それらすべてを確認して期待どおりの対応をするにはかなりの作業が必要です。この問題は、GoとNPMの依存関係スキャナーで特に深刻です。
時間と労力の節約のため、生のレポートを送信しないようお願いいたします。代わりに、どの特定の結果が適用可能で、なぜ適用可能なのかを説明する分析とともに提出してください。
Prometheusは企業ではなくボランティアによって保守されています。したがって、セキュリティの問題の修正はベストエフォートで行われます。Prometheus、Alertmanager、Node Exporter、Blackbox Exporter、およびPushgatewayについては、7日以内にセキュリティ修正をリリースすることに努めています。
信頼できないユーザーがPrometheusのHTTPエンドポイントとログにアクセスできると想定しています。彼らはデータベースに含まれるすべての時系列情報と、さまざまな運用/デバッグ情報にアクセスできます。
信頼できるユーザーだけが、コマンドライン、設定ファイル、ルールファイル、およびPrometheusと他のコンポーネントのランタイム環境のその他の側面を変更できることも想定しています。
Prometheusがどのターゲットをスクレイプするか、どのくらいの頻度で、どのような設定でスクレイプするかは、設定ファイルで完全に決定されます。管理者は、サービスディスカバリシステムからの情報を使用することを決定する可能性があり、リラベリングと組み合わせることで、そのサービスディスカバリシステムのデータを変更できるユーザーにこの制御の一部を付与する場合があります。
スクレイプされるターゲットは、信頼できないユーザーによって実行される場合があります。デフォルトでは、ターゲットが別のターゲットになりすますデータを公開することはできないはずです。`honor_labels`オプションは、特定のリラベリング設定と同様に、この保護を削除します。
Prometheus 2.0以降、`--web.enable-admin-api`フラグは、時系列の削除などの機能を含む管理HTTP APIへのアクセスを制御します。これはデフォルトで無効になっています。有効にした場合、管理および変更機能は` /api/*/admin/`パスでアクセスできます。`--web.enable-lifecycle`フラグは、Prometheusのリロードとシャットダウンを制御します。これもデフォルトで無効になっています。有効にした場合、`/-/reload`と`/-/quit`パスでアクセスできます。
Prometheus 1.xでは、`/-/reload`と` /api/v1/series`に対する`DELETE`の使用は、HTTP APIにアクセスできるユーザーであれば誰でもアクセスできます。`/-/quit`エンドポイントはデフォルトで無効になっていますが、`-web.enable-remote-shutdown`フラグで有効にすることができます。
リモート読み取り機能により、HTTPアクセス権を持つユーザーは誰でもリモート読み取りエンドポイントにクエリを送信できます。たとえば、PromQLクエリがリレーショナルデータベースに対して直接実行される場合、Prometheusにクエリを送信できるユーザー（Grafanaなど）は誰でも、そのデータベースに対して任意のSQLを実行できます。
AlertmanagerのHTTPエンドポイントにアクセスできるユーザーは誰でも、そのデータにアクセスできます。彼らはアラートを作成および解決できます。サイレンスを作成、変更、削除できます。
通知の送信先は、設定ファイルで決定されます。特定のテンプレート設定を使用すると、アラート定義の宛先に通知が送信される可能性があります。たとえば、通知がアラートラベルを宛先メールアドレスとして使用する場合、Alertmanagerにアラートを送信できるユーザーは誰でも、任意のメールアドレスに通知を送信できます。アラート定義の宛先がテンプレート可能なシークレットフィールドの場合、PrometheusまたはAlertmanagerのいずれかにアクセスできるユーザーは誰でも、シークレットを表示できます。
テンプレート可能なシークレットフィールドは、上記のユースケースで通知をルーティングするためのものであり、テンプレートファイル機能を使用してシークレットを設定ファイルから分離する方法として意図されていません。テンプレートファイルに保存されているシークレットは、Alertmanager設定ファイルで受信者を設定できるユーザーであれば誰でも抽出できます。たとえば、大規模な設定では、各チームが完全に制御するAlertmanager設定ファイルの断片を持つ可能性があり、それらが最終的な完全な設定ファイルに統合されます。
PushgatewayのHTTPエンドポイントにアクセスできるユーザーは誰でも、その中に含まれるメトリックを作成、変更、削除できます。Pushgatewayは通常、`honor_labels`を有効にしてスクレイプされるため、Pushgatewayにアクセスできるユーザーは誰でも、Prometheusに任意の時系列を作成できます。
`--web.enable-admin-api`フラグは、すべての既存のメトリックグループを消去するなどの機能を含む管理HTTP APIへのアクセスを制御します。これはデフォルトで無効になっています。有効にした場合、管理機能は` /api/*/admin/`パスでアクセスできます。
エクスポーターは、一般的に、プリセットのコマンド/リクエストセットを使用して、設定された1つのインスタンスのみと通信し、HTTPエンドポイントを介して拡張することはできません。
SNMPやBlackboxエクスポーターなど、URLパラメーターからターゲットを取得するエクスポーターもあります。したがって、これらのエクスポーターへのHTTPアクセス権を持つユーザーは誰でも、それらに任意のエンドポイントへのリクエストを送信させることができます。クライアント側の認証もサポートしているため、HTTP Basic認証パスワードやSNMPコミュニティ文字列などのシークレットの漏洩につながる可能性があります。TLSなどのチャレンジレスポンス認証メカニズムは、これの影響を受けません。
クライアントライブラリは、ユーザーのアプリケーションに含めることを目的としています。
クライアントライブラリが提供するHTTPハンドラーを使用する場合、そのハンドラーに到達する悪意のあるリクエストによって、追加の負荷とスクレイプの失敗によるもの以外に問題が発生することはありません。
Prometheus およびほとんどのエクスポーターは TLS をサポートしています。TLS クライアント証明書によるクライアント認証を含みます。Prometheus の設定に関する詳細は こちら をご覧ください。
Go プロジェクトは、Go の crypto/tls ライブラリに基づく同じ TLS ライブラリを共有しています。デフォルトでは、最小バージョンとして TLS 1.2 を使用しています。この点に関するポリシーは、Qualys SSL Labs の推奨事項に基づいており、デフォルト設定と正しく提供された証明書で「A」グレードの達成を目指すと共に、可能な限りアップストリームの Go デフォルトに準拠しています。このグレードの達成により、完璧なセキュリティと使いやすさのバランスを取ることができます。
Java エクスポーターには、将来的に TLS が追加される予定です。
異なる暗号スイートや古い TLS バージョンなど、特別な TLS のニーズがある場合は、暗号が crypto/tls ライブラリで非安全とマークされていない限り、最小 TLS バージョンと暗号を調整できます。それでもニーズを満たせない場合は、現在の TLS 設定を使用して、より特殊な要件を持つサーバーとリバースプロキシ間の安全なトンネルを構築できます。
HTTP ベーシック認証もサポートされています。ベーシック認証は TLS なしで使用できますが、その場合、ネットワーク上でユーザー名とパスワードが平文で公開されます。
サーバー側では、ベーシック認証のパスワードは bcrypt アルゴリズムを使用してハッシュとして保存されます。セキュリティ基準に一致するラウンド数を選択することは、ユーザーの責任です。ラウンド数が多いほど、ブルートフォース攻撃は複雑になりますが、その分 CPU パワーとリクエストの認証にかかる時間が増加します。
さまざまな Prometheus コンポーネントは、クライアント側の認証と暗号化をサポートしています。TLS クライアントサポートが提供されている場合、多くの場合、SSL 検証をスキップするinsecure_skip_verifyというオプションもあります。
管理エンドポイントと変更エンドポイントは、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 組織でセキュリティのバグを発見した場合は、関連するリポジトリの MAINTAINERS に記載されているメンテナーに非公開で報告し、[email protected] に CC を追加してください。
その組織の下にある一部のリポジトリは、このドキュメントで提示されているものとは異なるセキュリティモデルを持っている場合があります。その場合は、それらのリポジトリのドキュメントを参照してください。
2018 年、CNCF は cure53 によって 2018 年 4 月から 2018 年 6 月にかけて実施された外部セキュリティ監査を後援しました。詳細については、監査の最終レポートをお読みください。
2020 年、CNCF は Node Exporter のcure53 による 2 回目の監査を後援しました。
2023 年、CNCF は Chainguard による Prometheus のソフトウェアサプライチェーンセキュリティ評価を後援しました。
このドキュメントは オープンソース です。問題やプルリクエストを送信して改善にご協力ください。