Prometheusは「裸」で運用するな：ゼロトラスト時代における堅牢な監視基盤の構築術
Prometheusをただ「メトリクスを集めるためのサーバー」だと思っているなら、今すぐその認識を改めるべきだ。Prometheusは、システムの状態を可視化する最強の武器であると同時に、ネットワーク内を自由に這い回る「特権的データソース」でもある。
社内LANという「境界」が消滅した今、Prometheusをデフォルト設定のまま放置することは、家の鍵を開けたまま外出するに等しい。本稿では、Prometheusをゼロトラスト環境の最前線で運用するための、TLS相互認証と認証プロキシによる完全武装の神髄を伝授する。
—
1. なぜ「そのまま」ではいけないのか：Prometheusの脆弱性の本質
Prometheusのデフォルト実装は、認証・認可を外部に委ねる設計だ。これは「信頼できるネットワーク内に配置される」というレガシーな前提に基づいている。しかし、現代の分散システムにおいては、エッジからデータセンター、クラウドまで通信が横断する。
- スクレイピングの盗聴: TLSなしの通信は、平文でメトリクスが流れる。ビジネス上の機密情報（顧客数やトランザクション量）が傍受されるリスク。
- クエリの乗っ取り: `/api/v1/query` はPromQLを自由に実行できる。攻撃者に探索の足がかりを与え、最悪の場合はCPUリソースを枯渇させる（DoS攻撃）。
—
2. TLS相互認証（mTLS）でスクレイピングを堅牢化する
監視ターゲット（Exporter）とPrometheus間でmTLSを強制することで、通信の盗聴を防ぐだけでなく、「許可されたノード以外からのデータ投入」を完全に遮断する。
設定の勘所：`tls_config` の活用
Prometheusの `scrape_configs` には、`tls_config` を注入する。ここで重要なのは、CA証明書による信頼チェーンの確立と、クライアント証明書による個体識別だ。
prometheus.yml の一部
scrape_configs:
- job_name: ‘production-service’
scheme: https
tls_config:
# Exporterが提示する証明書を検証するためのCA
ca_file: /etc/prometheus/certs/ca.crt
# Prometheus自身のクライアント証明書（Exporter側で許可リスト化）
cert_file: /etc/prometheus/certs/client.crt
key_file: /etc/prometheus/certs/client.key
server_name: service.internal.local
# 厳格な検証を強制（中間者攻撃を無効化）
insecure_skip_verify: false
アーキテクトの視点:
ここで `insecure_skip_verify: true` を設定した瞬間に、あなたのセキュリティは崩壊する。証明書の有効期限管理には `cert-manager` を導入し、Kubernetes環境なら `Secret` オブジェクトを介した自動ローテーションをパイプラインに組み込め。手動管理は「事故の母」だ。
—
3. 認証プロキシによる「壁」の構築：OAuth2/Basic認証
Prometheus自体にはユーザー認証機能がない。したがって、前段にリバースプロキシ（Nginx, Envoy, または `oauth2-proxy`）を置くのが業界標準の「正解」だ。
推奨構成：Envoyによる透過的認証
EnvoyをPrometheusのサイドカー（または手前）に配置し、ヘッダーベースの認証を行う。
Envoyのフィルター設定例
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
http_filters:
- name: envoy.filters.http.jwt_authn
typed_config:
# ここでOIDC/OAuth2のJWTを検証
providers:
google:
issuer: https://accounts.google.com
jwks_uri: https://www.googleapis.com/oauth2/v3/certs
これにより、PromQL APIへのアクセスは「有効なトークンを持つ者」のみに制限される。
—
4. 上級者向け：パフォーマンスを犠牲にしないセキュリティ
セキュリティ対策は往々にしてオーバーヘッドを伴う。だが、賢い設計者は以下のハックでそれを最小化する。
① `scrape_interval` とコネクションプーリング
mTLSのハンドシェイクコストを抑えるため、Exporter側では `Keep-Alive` を有効にせよ。PrometheusのHTTPクライアントは再利用されるが、Exporter側が接続を切断すると、毎回TLSネゴシエーションが発生し、CPUを無駄に消費する。
② クエリ制限の自動化
攻撃者が極めて重いクエリを投げることを防ぐため、Prometheus起動時に以下のフラグを調整せよ。
- `–query.max-concurrency`: 同時実行クエリ数を制限し、メモリ枯渇（OOM）を防ぐ。
- `–query.timeout`: タイムアウトを厳格に設定し、無限ループに近いクエリを即座に殺す。
—
5. 運用自動化の魂：IaCとAPIの活用
Prometheusのコンフィグを人間が手で編集するなど、言語道断だ。
- 完全自動化パイプライン: `prometheus-operator` の `ServiceMonitor` を使い、監視対象の追加をGitOpsで管理する。これにより、監視設定の漏れとセキュリティ不備がCIプロセスで弾かれる。
- 自動モニタリング: Prometheus自身のメトリクス（`prometheus_http_requests_total` 等）を別の監視インスタンスから監視し、「誰が、どのクエリを叩いているか」を可視化せよ。
結論：監視の「守護者」たれ
Prometheusをセキュアにすることは、システムの「脳」を守ることと同義だ。
TLSによる暗号化、mTLSによる信頼の保証、そしてOAuth2によるアクセス制御。これらを実装し、自動化されたパイプラインに乗せることで初めて、あなたは「監視のプロフェッショナル」のスタートラインに立てる。
ツールに動かされるな。ツールを制御し、その挙動を完全に掌握せよ。それが、大規模分散システムを支配する唯一の道だ。