本問題について耳にし、このガイドを参考にした後、もう少し詳しく調べてみたいと思いました。このリポジトリには、攻撃メカニズムを可能な限り単純な方法で示すいくつかのPodデプロイメントと補助シェルスクリプトが含まれており、Kubernetes管理者や運用者が深刻さと潜在的なリスクを完全に理解できるようにしています。認証済みユーザーであるか、Podのspec/template作成時に制御できる必要があるため、このエスケープが匿名で行われる可能性は低く、このような他の攻撃と組み合わせなければ実現しません。
Kubeletがボリューム/シークレット/ConfigMapなどをマウントする際、誤ってボリューム内のシンボリックリンクをそのスコープ外の場所にたどってしまいます。Kubeletはrootとして実行されているため、特権のないPodのコンテナ内にホストファイルシステムの特権部分をマウントするように仕向けられる可能性があります。
私のアプローチでは、2つの「通常の」コンテナを持つ単一のPodを使用しました。1つのコンテナが/または/home/ubuntuへのシンボリックリンクを作成し、もう1つのコンテナはそれが成功するまでクラッシュループし（これによりボリュームが再マウントされ、そのシンボリックリンクパスがたどられる）、ユーザーが2番目のコンテナにexecしてマウントポイントにアクセスできるようにします。
注：これらの例はUbuntu 16.04ホストでそのまま動作しますが、他の設定にも簡単に調整できます。
./run-as-root.shを実行します。./run-as-root-no-chroot.shまたは./run-as-user-1000.shを実行します。
これはまさに「パッチ必須」の状況です。残念ながら、こちらにリストされている回避策は、ほとんどの人にとって実用的ではありません。ほぼすべての旧バージョンが脆弱です。