Dan Walsh 氏がこのアイデアについて言及しており、このトピックについてのブログがいずれ掲載される可能性があり、ここではとくにこの点についてコメントすることは控えます。Dan Walsh 氏の語った「containers don’t contain (コンテナーは (攻撃を) ブロックする訳ではない)」という言葉は読者の皆さんもご存知のことでしょう (コンテナーは VM とは異なりローカル特権昇格の攻撃から保護されている訳ではないという意味)。Kubernetes を使用すると、異なるタイプの実行中のコードを分離する「アパートメント (apartment complexes)」(一般的に使われる表現ではありませんが、Walsh 氏の言葉を引用しています) を作成できます。たとえば、特定のセキュリティーレベルのアプリケーション用の VM があるとします。法律事務所で使用する場合、法律事務所のクライアント (ここでのクライアントは「クライアントサーバー」アーキテクチャーの「クライアント」ではなく、法律事務所にサービスを依頼するエンティティーのこと) 別に VM を用意し、弁護士達はその VM 内で実行されるコンテナーで作業するかもしれません (つまり、だれかが VM に侵入したとしても、対象領域はその VM 内のデータのみとなり、他の事例に関連するデータには影響がありません)。このような場合には、Kubernetes の上部で実行される Apache のリソース管理アプリケーションである Mesos を使用できます。

これは調査の必要な分野です。認可、ログインおよびクライアント証明書の検証についてはすべて調査が必要です。

Kubernetes についての最も大きな懸念点とは Kubernetes クラスターをコンテナー自体からいかに保護するかという点です。コンテナーが独自のネットワークアクセスを使用し、Kubernetes に対して承認されていないコンテナーを生成するように指示し、Kubernetes がその要求に従うという望ましくない状況が生じる可能性があります。今後は「多層防御 (defense in depth)」の一部として、この種の望ましくない攻撃をネットワークレベルで停止するだけでなく、パスワードとログおよび証明書を Kubernets に導入することについての調査が行われます。コンテナーが Kubernetes 機能にアクセスする必要がない場合、Kubernetes をネットワーキング関連の要求からブロックする必要があります。コンテナーについては、ライフサイクルの初期段階で Kubernetes から必要な機能を取得したコンテナーを作成し、コンテナーの独自のファイアウォールのセキュリティーを保護できるため、潜在的な攻撃ベクトルを排除し、環境の攻撃対象領域を最小にできます。