監視の「盲点」を塞げ：Prometheusを要塞化するRBACとセキュリティの深淵
オブザーバビリティの神髄は「システムを深く知ること」にある。しかし、その「システムを知るための窓口」であるPrometheusそのものが、攻撃者にとっての「極上の宝箱」であることに気づいているエンジニアはどれだけいるだろうか。
Prometheusには、メトリクスという名のシステム内部の機密情報が詰まっている。設定を誤れば、攻撃者はあなたのAPIトークン、DBの接続情報、さらにはインフラのトポロジーまでを丸裸にできる。
今日は、Prometheusを単なる監視ツールから「攻撃に耐えうる要塞」へと進化させるための、現場で血肉となる極限の知見を共有する。
—
1. Prometheusを「全裸」にするな：WebUIの鉄壁ガード
Prometheusのデフォルト設定は「開発者が検証しやすい」というだけで、本番環境にはあまりに無防備だ。
鉄則：Prometheusは決して直接公開しない
PrometheusのWebUIをインターネットや社内ネットワークに平然と公開してはいけない。認証を突破された瞬間、`target`のリストやラベルから、システムの弱点が一目瞭然になる。
- OAuth2 Proxyによる保護: Nginx Ingress Controller等と連携し、`oauth2-proxy`をサイドカーとして配置せよ。GitHubやGoogleの認証を挟むだけで、攻撃のコストは数千倍に跳ね上がる。
- WebUIの機能制限: `–web.config.file` を使用し、不要なUIエンドポイントを無効化する。
web-config.yml
不要な管理APIを無効化し、攻撃対象領域を最小化する
basic_auth_users:
admin:
Prometheus 2.26以降で利用可能な設定
disable_admin_api: true
—
2. KubernetesにおけるRBAC：最小権限の原則を極める
Prometheusは通常 `ClusterRole` を必要とするが、何でもかんでも閲覧権限を与えるのは怠慢だ。
「神」権限を剥奪する
多くのドキュメントは `cluster-admin` 相当の権限をPrometheusに与えるよう指示するが、これは地雷だ。必要なのは `list` と `watch` だけである。
最小限のRBAC定義：これ以上は不要だ
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-minimal-role
rules:
- apiGroups: [“”]
resources: [“nodes”, “nodes/metrics”, “services”, “endpoints”, “pods”]
verbs: [“get”, “list”, “watch”] # ‘create’や’delete’は断じて許すな
—
3. 機密情報の「環境変数汚染」を防ぐ
「環境変数にパスワードをベタ書きする」のは、監視ツールにおいても例外ではない。PrometheusのYAML設定に直接シークレットを埋め込むのは論外だ。
プロの運用：K8s Secret + `envsubst`
設定ファイルには環境変数用のプレースホルダーを置き、起動時に `envsubst` を経由してマウントする。
prometheus.yamlの抜粋
scrape_configs:
- job_name: ‘api-server’
bearer_token: ${API_BEARER_TOKEN} # 環境変数から注入する
—
4. 現場で差がつく「神」テクニック
開発スピードを劇的に上げるキーボードショートカット
PrometheusのGraph UIでマウスを触っているのは素人だ。
- `Shift + Enter`: クエリの実行。
- `Ctrl + Enter`: クエリのフォーマット。
- `Up / Down`: クエリ履歴の呼び出し。
この3つだけで、トラブルシュートの速度は体感で2倍になる。
絶対に入れるべき「プラグイン的」存在：Prometheus Rule Validator
設定ファイルをデプロイする前に、必ずローカルでバリデーションをかけろ。
デプロイ前にCIパイプラインで必ず通すこと
promtool check rules alert_rules.yml
promtool check config prometheus.yml
これを通さないまま本番にデプロイし、監視が死ぬ事故を何度見てきたことか。
—
5. チーム開発における設定共有の「黄金ルール」
設定がスパゲッティ化するのを防ぐために、以下のルールを徹底せよ。
1. ラベルの正規化: `env`, `service`, `team` ラベルを全メトリクスに強制適用する。これがなければ、障害発生時に「どのチームの責任か」で朝まで議論することになる。
2. Recording Ruleの活用: 重いクエリは `Recording Rule` に逃がせ。ダッシュボードを開くたびに計算させているようでは、監視自体が負荷の原因になる。
3. YAMLのDRY: `kustomize` を使い、環境ごとの差分のみを管理せよ。コピペしたYAMLファイルが散乱するリポジトリは、監視の「墓場」だ。
—
最後に：オブザーバビリティは「信頼」である
監視ツールは、システムが健やかであることを証明する唯一の根拠だ。その根拠そのものが脆弱であれば、チームはシステムを信頼できなくなる。
今日紹介した設定は、どれも地味で面倒なものかもしれない。しかし、「誰にも気づかれないところで、システムを完璧に守り抜く」ことこそが、伝説的なエンジニアの証だ。
さあ、今すぐあなたのPrometheus設定を確認し、不要な権限を剥ぎ取り、要塞としての磨きをかけてほしい。あなたの監視が、真の意味でチームの誇りとなることを願っている。