マネージド Kubernetes の特権 Pod から他テナントまで：クラウド内部の分離を崩した不備の連鎖

ある大手クラウドへのバグ報奨金調査で、利用者が作れた特権 Pod を起点に、ワーカーノード、コントロールプレーン、フラットな内部ネットワークを経て他テナントのクラスターや DB まで届いた（事業者は匿名化、すべて修正済み）。自前で基盤を運用する側にとっての点検リストとして読める。

特権 Pod が作れた: k0s ベースのマネージド Kubernetes で特権 Pod の作成が制限されておらず、ワーカーノードの root を取得。
ノード上のトークン: Konnectivity（コントロールプレーンとノード間のトンネル）のサービスアカウントトークンを入手。ノード発の接続要求をコントロールプレーンが指定先へそのまま中継する作りを使い、コントロールプレーン上で限定権限のコマンド実行に至った（k0s 開発元の Mirantis も確認）。
古いカーネル: OverlayFS の既知の欠陥で root へ昇格（ユーザー名前空間が有効な Ubuntu 22.04、カーネル 5.15 系）。SaltStack の minion 鍵も見つかった。
フラットな内部網: 各マネージドサービスが互いに見え、ログ基盤（VictoriaLogs）は認証なしで全リソースのログを読めた。そこに cloud-init が生成した root 用 SSH 秘密鍵が残っていた。
管理口の無防備: Kafka の JMX 公開、Redis 監視ツールが認証情報を任意の宛先へ送る作り、Patroni の etcd にアクセス制限なし。全 DB バックアップを置く S3 の認証情報まで発見。
独自拡張の SQL インジェクション: SaltStack 本体は最新でも、事業者独自の拡張スクリプトの欠陥で全 Salt マスターの認証トークンが取れた。

特権 Pod を止める: Pod Security Admission を restricted（最低でも baseline）で強制し、privileged、hostPID、hostPath などを許可しない。マネージド K8s でも、利用者に何が許されているかを確認する。
ノード上のトークンを最小にする: ノードに置かれるサービスアカウントトークンの権限を棚卸しし、中継系コンポーネントが任意の宛先へ接続できないようにする。
ノードのカーネル更新: 既知の権限昇格が最後の一押しになる。ノードイメージを定期的に入れ替え、非特権ユーザー名前空間を不要なら無効化する。
管理系のネットワークを分ける: ログ基盤、etcd、JMX、監視ツールは利用者側ネットワークから到達できないようにし、すべて認証を付ける。
ログに秘密を残さない: cloud-init やプロビジョニングの出力に鍵やトークンが含まれないか検索し、ログ基盤の閲覧権限を絞る。
自社拡張コードも診断対象に: 構成管理ツール本体を更新していても、社内で足したスクリプトが穴になる。