サイドカーは「信頼の足元」をすくう盲点――サービスメッシュ時代の権限侵害と対策
「サイドカーコンテナがあるから、アプリケーションは安全だ」と思っているなら、今すぐその認識を捨ててほしい。
EnvoyやIstioのようなサービスメッシュを導入している現場では、メインのアプリケーションコンテナと同じPod内に、特権的な役割を担うサイドカーが同居している。これらはトラフィックの制御や相互TLS（mTLS）の管理を行う「黒衣」だが、攻撃者にとっては「アプリケーションに憑依するだけで、クラスタの権限を奪取できる特等席」に他ならない。
今回は、このサイドカーが持つ強力な権限がどのように悪用され、それをどう防ぐべきか、現場の視点で切り込む。
—
1. サイドカーのトークンは「鍵束」である
Kubernetesにおいて、Pod内の各コンテナには自動的に ServiceAccount のトークンがマウントされる。サイドカー（例えばIstioの istio-proxy）は、クラスタ内の通信を制御するために、アプリケーションよりも強い権限を持つことが多い。
攻撃者がアプリケーションの脆弱性（RCEなど）を突き、Pod内に侵入したとしよう。彼らはまず /var/run/secrets/kubernetes.io/serviceaccount/token を探す。もしPodの設計が甘く、アプリケーションとサイドカーが同じ ServiceAccount を共有していれば、攻撃者は即座にKubernetes APIサーバーへのアクセス権を手に入れ、名前空間内の情報を列挙したり、他のPodを攻撃する足がかりにする。
攻撃シナリオ：サイドカーを経由した横展開
1. アプリの脆弱性（例：コマンドインジェクション）を突き、Pod内のシェルを奪う。
2. マウントされている token を使い、kubectl バイナリがなくても curl でAPIサーバーを叩く。
3. サイドカーが持つ「他サービスへの通信許可」を悪用し、内部ネットワークの機密情報へアクセスする。
—
2. 防御の要：ServiceAccountの分離と最小権限
この攻撃を防ぐための第一歩は、「アプリケーションとサイドカーの権限を物理的に切り離すこと」だ。Pod全体で一つの ServiceAccount を使い回すような構成は、今すぐ廃止すべきだ。
Kubernetesでの権限分離（Podスペックの修正）
Istioのようなサイドカーを使用する場合、automountServiceAccountToken: false を活用し、必要最小限の権限以外は与えないのが鉄則だ。
apiVersion: v1
kind: Pod
metadata:
name: secure-app
spec:
# デフォルトのトークン自動マウントを無効化
automountServiceAccountToken: false
containers:
- name: my-app
image: my-app:latest
# アプリにはトークンをマウントしない
volumeMounts:
- name: empty-dir
mountPath: /var/run/secrets/kubernetes.io/serviceaccount
readOnly: true
- name: istio-proxy
image: istio/proxyv2:latest
# サイドカーには必要な権限のみを与えた専用SAを割り当てる
# （RBACで限定された権限のみを持つSAを指定する）
serviceAccountName: istio-proxy-sa—
3. 実装レベルでの防御：サイドカー通信の監視
権限分離だけでなく、アプリケーション側で「誰が通信しているか」を検証することも重要だ。例えば、Pythonで書かれたバックエンドであれば、X-Forwarded-Client-Cert ヘッダーを検証し、許可されたクライアント（サイドカー経由の正当なトラフィック）からのリクエストのみを受け入れる実装にする。
Python (FastAPI) でのリクエストバリデーション例
from fastapi import FastAPI, Request, HTTPException
app = FastAPI()
# 信頼できるプロキシ（サイドカー）からのアクセスのみを許可する
ALLOWED_PROXY_IP = "127.0.0.1"
@app.middleware("http")
async def verify_proxy(request: Request, call_next):
# クライアントIPがサイドカー経由か確認
client_ip = request.client.host
if client_ip != ALLOWED_PROXY_IP:
# 外部から直接アプリコンテナへの通信をブロック
raise HTTPException(status_code=403, detail="Forbidden: Direct access denied")
response = await call_next(request)
return response—
4. 現場のセキュリティチーフからの提言
最後に、運用において忘れてはならないポイントを挙げる。
1. automountServiceAccountToken: false をデフォルトにせよ：
HelmチャートやKustomizeのベース設定で、デフォルトでトークンをマウントしない設定を強制する。本当に権限が必要なPodだけ、例外として許可を与える運用に変えるだけで、攻撃の難易度は跳ね上がる。
2. ネットワークポリシーの適用：
たとえサイドカーが乗っ取られても、Pod外への通信を NetworkPolicy で制限しておけば被害は最小限に留まる。「どのサービスがどのサービスと通信できるか」をホワイトリスト方式で厳格に定義すること。
3. 可視化とログ監査：
サイドカー（Envoy）のアクセスログを stdout に出し、異常なパスへのアクセスや、不自然なトークンの使用をSIEMで検知する。
セキュリティとは、境界線を引くことではなく、「境界線が突破されたときに、どれだけ被害を隔離できるか」という設計の美学だ。サイドカーを「便利なツール」として盲信するのではなく、「強力な武器であるがゆえに厳重に管理すべき特権」として扱うこと。それが、真に堅牢なクラウドネイティブ環境を作るエンジニアの矜持である。
明日から、君のクラスタの PodSpec を確認してほしい。そこには、まだ修正されていない「鍵束」が放置されているかもしれないのだから。
コメント