SECURITY MODEL

Prometheusは、たくさんのコンポーネントとたくさんの他システムとの連携のある複雑なシステムである。多種多様な、信頼性のある環境と信頼性のない環境にデプロイされる可能性がある。

このページは、Prometheusの一般的なセキュリティ上の仮定と、いくつかの設定で有効になる攻撃経路について記述する。

複雑なシステムであれば何であれ、バグがないという保証することは不可能である。もし、セキュリティのバグを見つけたら、関係するリポジトリのMAINTAINERS.mdに挙げられているメンテナー個人にレポートし、prometheus-team@googlegroups.comにCCして下さい。私たちは、その問題を修正し、リリース日をあなたと調整し、あなたが望むなら個人名を挙げてあなたの努力に謝意を示します。

Prometheus

PrometheusのHTTPエンドポイントとログに信頼性のないユーザーからのアクセスがあることが仮定されている。データベースに含まれる全ての時系列に加えて各種の操作/デバッグ情報にアクセスできる。

また、信頼性のあるユーザーのみが、コマンドライン、設定ファイル、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で有効にできる。

remote read機能によって、HTTPアクセスできる人なら誰でもremote readエンドポイントにクエリを送信できるようになる。例えば、もし、PromQLクエリが最終的にリレーショナルDBに対して直接実行されるならば、Prometheusに（Grafanaなどを通して）クエリを送信できる人なら誰でも任意のSQLをそのDBに対して出来ることになる。

Alertmanager

AlertmanagerのHTTPエンドポイントにアクセスできる人なら誰でもそのデータにアクセスできる。アラートを作成したり解消できる。サイレンスを作成したり、修正したり、削除できる。

どこに通知を送るかは、設定ファイルによって決まる。テンプレートの設定次第で、通知の宛先がアラートによって決まってしまう。例えば、宛先emailアドレスとしてアラートのラベルを使っていると、Alertmanagerにアラートを送信できる人なら誰でも、どんなemailアドレスにも通知を送ることが可能である。もし、アラートで決まる宛先がテンプレート可能な秘密のフィールドならば、PrometheusまたはAlertmanagerにアクセスできる人なら誰でもその秘密を見ることが可能になるだろう。

テンプレート可能な秘密のフィールドは、通知をルーティングするための利用を意図している。テンプレートファイルの機能を利用して秘密を設定ファイルから分離するための方法としては意図されていない。例えば、大規模な設定の中では、各チームが自分で完全に制御できるAlertmanager設定ファイルの断片を持っていて、それらが結合されて、最終的な完全な設定ファイルになる。

Pushgateway

PushgatewayのHTTPエンドポイントにアクセスできる人なら誰でも、その中に含まれるメトリクスを作成、変更、削除することができる。 Pushgatewayは通常はhonor_labelsを有効にしてスクレイプされるので、これは、Pushgatewayにアクセスできる人は誰でもPrometheusの中に時系列を作成できるということを意味する。

Exporters

exporterは、一般的には、設定されたインスタンスとだけ、事前に決められたコマンド/リクエストの集合を用いて、通信する。

SNMPやBlackbox exporterのような、URLパラメーターから監視対象を得るexporterも存在する。したがって、それらのexporterにHTTPでアクセスできる人なら誰でも、任意のエンドポイントにリクエストを送信することが可能である。それらはクライアント側での認証をサポートしているので、HTTP Basic認証のパスワードやSNMP community stringsのような秘密の漏洩に繋がる可能性がある。 TLSのようなチャレンジ/レスポンス認証はこの影響を受けない。

クライアントライブラリ

クライアントライブラリは、ユーザーアプリケーションに含まれることが意図されている。

クライアントライブラリが提供するHTTPハンドラを利用しているなら、そのハンドラに到達する悪意のあるリクエストが、付加的な負荷やスクレイプの失敗の問題以外の問題を起こすことが可能であってはならない。

認証、認可、暗号化

Prometheusおよびそのコンポートは、サーバーサイドで認証も認可も暗号化も提供しない。もしそれらが必要なら、リバースプロキシの利用が推奨されている。

管理用エンドポイントと変更が起きるエンドポイントは、cURLなどの簡単なツールを通してアクセスされることを意図している。そのような使い方ができなくなってしまうので、CSRFの防御は組み込まれていない。したがって、リバースプロキシを使う際には、CSRFを防ぐためにそういうパスをブロックした方が良いだろう

変更が起きないエンドポイントに対しては、XSSを防ぐために、Access-Control-Allow-OriginのようなCORSヘッダをリバースプロキシに設定した方が良いだろう。

任意のPromQLを実行できるようにするつもりがない信頼性のないユーザーからの入力（コンソールテンプレートや自分で作った何かへのURLパラメーター）を含むPromQLクエリを構築している場合、信頼性のない入力の全てが適切にエスケープされるようにし、インジェクション攻撃を防ぐこと。例えば、up{job="<user_input>"}は、仮に<user_input>が"} or some_metric{zzz="だったとすると、up{job=""} or some_metric{zzz=""}るだろう。

Grafanaを使っている人は、ダッシュボードのパーミッションはデータソースのパーミッションではない、したがって、プロキシモードでユーザーが任意のクエリを実行する力を制限しないこと。

Prometheusの各種コンポーネントはクライアント側の認証と暗号化をサポートしている。 TLSクライアントが提供されている場合、SSLの検証をスキップするinsecure_skip_verifyという設定項目もしばしばある。

Secrets

秘密でない情報やフィールドは、HTTP APIやログを通じて利用可能な可能性がある。

Prometheusでは、サービスディスカバリーで取得したメタデータは秘密とは考えられていない。 Prometheusシステム全体で、メトリクスは秘密とは考えられていない。

設定ファイルの秘密を含むフィールド（ドキュメントにそう明示されている）は、ログやHTTP APIを通じて出力されることはない。コンポーネントが自分の設定をHTTPエンドポイントから出力するのは普通なので、秘密を他の設定フィールドに入れてはいけない。

依存しているものに利用される他の情報源から来る秘密（例えば、EC2サービスディスカバリーで利用されるAWS_SECRET_KEY環境変数）は、Prometheusで制御できる範囲外のコードのせい、または、それが保存されている場所に出力する機能のせいで結局出力されてしまうかもしれない。

Denial of Service

過剰な負荷や高価なクエリに対する緩和策がいくつか講じられている。しかし、多すぎる、または効果すぎるクエリー/メトリクスが与えられると、コンポーネントは落ちてしまうだろう。悪意のある行動よりも信頼しているユーザーによってたまたま破壊される可能性の方が高い。

CPU、RAM、ディスク容量、IOPS、ファイル記述子、通信帯域を含む十分なリソースをコンポーネントに与えるのはユーザーの責任である。

全てのコンポーネントのエラーを監視し、エラー時に自動的に再起動させることが推奨される。

ライブラリ

このドキュメントは、ソースコードからビルドされた普通のバイナリについて考える。自分でソースコードを修正した場合や、Prometheusの内部を自分のコードから（公式クライアントライブラリAPIを超えて）利用した場合には、ここで記されている情報は適用できない。

ビルドプロセス

Prometheusのビルドパイプラインは、サードパーティーのプロバイダー上で動き、Prometheus開発チームのメンバーとそのプロバイダーのスタッフがパイプラインにアクセスできる。もし、自分のバイナリの正確な出どころについて心配なら、プロジェクトによって事前にビルドされたバイナリに頼るのではなく、自分自身でビルドすることを推奨する。

外部監査

CNCFは、2018年4月から2018年6月に渡るcure53による外部のセキュリティ監査を支援した。

さらなる詳細は、監査の最終報告書を呼んで下さい。

参考リンク

Security | Prometheus

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード — 上のQRコードからPayPayによる支援

it-engineer’s blog

セキュリティモデル - Prometheusドキュメント