Kubeletの深淵：匿名認証という「開かれた門」をいかにして閉ざすか
Kubernetesの堅牢性は、コントロールプレーンの保護だけでは担保できない。多くのアーキテクトがAPIサーバーのRBACに腐心する一方で、各ワーカーノードの心臓部であるkubeletが、デフォルト設定のまま「野晒し」になっている現場を幾度となく見てきた。
kubeletが公開する10250ポートは、本来ノードのメトリクスやポッドのライフサイクル管理のためのものだ。しかし、ここが認証なしで叩ける状態にあるということは、クラスターの内部構造を外部に暴露し、さらに攻撃者に「足場」を与えることを意味する。今日は、この脆弱性の本質と、防衛の最前線について語ろう。
—
脆弱性の本質：なぜ「匿名アクセス」が危険なのか
kubeletの--anonymous-authがtrue（あるいは未設定でデフォルト値がtrue）の状態は、悪意ある第三者に対して、ノード上のポッド一覧の取得やログの閲覧、さらには特定のコマンド実行を許容する極めて危険な状態だ。
攻撃者は、この認証バイパスを利用して、クラスター内に存在するシークレット情報の断片を収集し、そこからIAMロールの奪取や、さらなる水平移動（Lateral Movement）へと繋げる。これは単なる設定ミスではなく、インフラストラクチャにおける「認証なき特権」という、プロトコル設計レベルの欠陥を放置しているのと同義である。
攻撃者がパケットを見る視点
攻撃者は、https://<node-ip>:10250/pods に対してリクエストを投げ、返ってきたJSONレスポンスから、実行中のコンテナイメージ、マウントされたボリューム、そして環境変数に埋め込まれたAPIキーを抽出する。ここには暗号化の欠如以前に、認可の欠如という根本的な「ゲートウェイの不在」がある。
—
防衛のアーキテクチャ：Kubeletの要塞化
kubeletを保護する基本は、認証の強制と、APIサーバー経由でのアクセスへの限定だ。以下の設定を、ノードのkubelet-config.yaml（あるいは構成ファイル）に適用せよ。
# Kubeletの設定ファイル例 (kubelet-config.yaml)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
# 1. 匿名認証を明示的に無効化する。これが最初の防衛線
authentication:
anonymous:
enabled: false
webhook:
enabled: true # APIサーバーによる認証を有効化
x509:
clientCAFile: "/etc/kubernetes/pki/ca.crt" # クライアント証明書による認証を強化
# 2. 認可もAPIサーバーに委譲する
authorization:
mode: Webhook # APIサーバーのSAR (SubjectAccessReview) を使用する
# 3. サーバー証明書の自動回転を有効化（耐量子暗号を見据えた長期的視点）
rotateCertificates: true設定適用のポイント
anonymous.enabled: false: これにより、無認証のリクエストは直ちに401 Unauthorizedで拒絶される。authorization.mode: Webhook: ノードに対する操作をAPIサーバーに問い合わせることで、クラスター全体のRBACポリシーと統合する。個別のノードで許可設定を管理する泥臭い作業から解放され、監査ログも一元化される。
—
監査の視点：アーキテクトがチェックすべき「盲点」
設定を終えた後、本当に防衛が機能しているかを確認するために、以下の監査項目を定常的に回すことを推奨する。
1. 10250ポートのパケットキャプチャ: 外部からノードに対して当該ポートへのアクセスを試み、401が返却されることを確認する。
2. 監査ログの精査: APIサーバーの監査ログを有効化し、system:nodes グループ以外のユーザーが kubelet APIを叩こうとした試跡を監視せよ。
3. 証明書のライフサイクル管理: rotateCertificates: true を設定していても、CA局の信頼性が揺らいでは意味がない。証明書の失効リスト（CRL）やOCSPの運用、さらには将来的には耐量子暗号（PQC）対応の証明書発行を見据えた、ハードウェアセキュリティモジュール（HSM）との連携を設計しておくべきだ。
—
結論：セキュリティは「設定」ではなく「規律」である
Kubeletの要塞化は、Kubernetesセキュリティの「基礎の基礎」だ。しかし、この基礎を疎かにする組織は、どれほど高価なWAFを導入しようが、生成AIガードレイルを構築しようが、内部からの侵入に対して無防備であることに変わりはない。
我々エンジニアが目指すべきは、ツールに頼るセキュリティではなく、プロトコルの挙動を理解し、その上で堅牢な境界を設計し続ける「執念」である。君たちのクラスターのkubeletは、今夜も「開かれた門」のままになっていないだろうか？ ログを確認してほしい。それが、プロの仕事だ。
コメント