【テクニカル・上級編】 KubernetesにおけるKubeletの未認証アクセス脆弱性 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

Kubernetesの深淵：Kubeletの未認証アクセスという「パンドラの箱」を暴く

Kubernetesクラスターのセキュリティを語る際、多くのエンジニアは kube-apiserver の認証やRBACの複雑さに頭を悩ませる。だが、真のプロフェッショナルは、その背後で沈黙を守る「Kubelet」の脆弱性を決して見逃さない。

Kubeletは、各ノードの支配権を握る司令塔だ。もし、このKubeletが全裸でインターネット（あるいは内部ネットワーク）に晒されていたとしたら？今日は、Kubeletの読み取り専用ポート（10255）や匿名認証の不備が、いかにしてクラスター全体の崩壊を招くのか、その技術的背景と防御の極意を紐解く。

—

1. 攻撃者の視点：なぜKubeletの匿名アクセスが「ゴールドマイン」なのか

攻撃者がKubeletのAPI（デフォルトでポート10250、あるいは古い10255）にアクセスできた瞬間、彼らはそのノード上の「神」となる。ここで取得できる情報は単なるメタデータではない。

Podのリストとシークレット: 実行中のPodの環境変数やマウントされたボリューム内のトークン。
コンテナのログ: セキュリティトークンや機密情報が誤って出力されたログの回収。
コマンド実行能力: exec APIを悪用し、ノードの権限で任意のバイナリを叩く。

Kubeletの通信プロトコルは、TLSクライアント認証を強制しない限り、極めて脆弱だ。特に、--anonymous-auth=true が設定された環境では、攻撃者は「認証なし」でkubeletのAPIを叩き、クラスターの内部構造をパケットレベルで完全にマッピングできてしまう。

—

2. 脆弱性の解剖：通信プロトコルと認証の欠陥

KubeletのAPIエンドポイントは、本来、kube-apiserver との信頼関係を前提に設計されている。しかし、--read-only-port を有効にしている場合、認証をバイパスしてクラスター内のリソース状況が外部に筒抜けになる。

これは単なる設定ミスではない。Kubernetesの設計思想である「分散型コンポーネントの相互信頼」が、悪意ある内部アクセスに対して無防備であることを示している。攻撃者は、以下のようなcurlコマンド一つでノードの全貌を把握する。

# ノード上のPod情報を引き抜く攻撃の例
# 攻撃者はこのレスポンスから、実行中のコンテナの機密情報を特定する
curl -k https://<KUBELET_IP>:10250/pods

—

3. 防衛の要塞化：ゼロトラスト・アーキテクチャの導入

我々が講じるべき防御策は、「設定の修正」を超えた「アーキテクチャの強制」だ。

3.1 Kubeletの認証・認可の強化

まずは、匿名認証を徹底的に無効化し、TLSクライアント認証を強制する。Kubeletの構成ファイル（通常は /var/lib/kubelet/config.yaml）で以下の設定を適用せよ。

# Kubeletの設定ファイル (config.yaml)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false # 匿名アクセスの禁止
  webhook:
    enabled: true # Webhook認証を有効化
    cacheTTL: 2m0s
authorization:
  mode: Webhook # RBACによる認可を強制
readOnlyPort: 0 # 読み取り専用ポートを無効化し、攻撃経路を遮断

3.2 ネットワーク層での封じ込め

Kubelet APIをクラスター外から遮断するのは最低条件だ。CalicoやCiliumといったCNIを活用し、NetworkPolicy で kube-apiserver 以外のノードからの10250番ポートへのアクセスを拒否せよ。

—

4. 未来への備え：耐量子暗号とガードレイル

今後、Kubernetesのセキュリティは「暗号アルゴリズムの更新」という新たなフェーズを迎える。現在のTLS通信は量子コンピュータによる解読リスクを内包している。将来的な Kyber などの耐量子暗号（PQC）への移行を見据えた、サービスメッシュ（Istio等）による通信の多重暗号化は、テックリードにとって不可避なタスクだ。

また、AI時代においては、Kubernetesの監査ログに対して大規模言語モデル（LLM）を用いたリアルタイムのガードレイル設計が重要になる。

プロンプトインジェクションへの防御例:
APIサーバーへのリクエストに異常な文字列や不審なコマンドパターンが含まれていないか、ゲートウェイ層でLLM推論APIを叩き、スコアリングするアーキテクチャを実装する。

# ガードレイル関数の概念コード
def check_k8s_request_safety(request_payload):
    # AIモデルによるインジェクション検知
    # 悪意ある文字列が含まれる場合はブロックする
    if ai_model.detect_injection(request_payload):
        raise SecurityException("Unauthorized command pattern detected.")
    return True

—

結びに：泥臭い監視こそが最強の防御

どれほど強固な設定を施そうと、脆弱性は常に「更新される」ものだ。監視カメラを設置するだけでは不十分で、そのカメラの映像を誰が見ているのか、という「監査の透明性」が問われる。

Kubeletのセキュリティは、設定ファイルの1行を書き換えて終わりではない。クラスター内の全ノードで、kubeletがどのような通信を行い、誰がどのエンドポイントを叩いているのか。その「ノイズ」の中にこそ、真の攻撃の兆候が隠されている。

諸君、クラスターを信じるな。ログを信じ、自ら構築した防衛ラインのほころびを常に疑い続けろ。それが、この過酷なサイバー戦場で生き残るための唯一の流儀だ。