Kubernetesの侵入テストの結果:考察とTwistlockによる対応

195 people reacted 0 1 min. read

By and

Category: カテゴリーなし

Tags:

This post is also available in: English (英語)

クラウド ネイティブ コンピューティングを推進する非営利団体Cloud Native Computing Foundation(CNCF)は昨年末、Kubernetesの未知のセキュリティ脆弱性と設計上の弱点を特定するために侵入テスト(ペネトレーション テスト)を委託しました。最終レポートワーキンググループのリポジトリを参照してください。

侵入テストは、うまくいけば、ソフトウェアのセキュリティ品質の強化につながります。Kubernetesの侵入テストは綿密かつ適切に設計されており、多数の新しい脆弱性が特定され、新しいセキュリティ機能の強化を実装するよう推奨されるなど、数多くの調査結果が得られました。Kubernetesプロジェクトでは、特定された37件の問題の進捗状況を追跡するためのトラッカーとして、#81146をオープンしました。

このレポートについては、多くのユーザー企業から質問が寄せられています。代表的な質問と回答は次のとおりです。

  1. すべての問題が修正される前にレポートが公開されたのはなぜですか?

調査結果の開示については、公開前に発表されておらず、調整が充分になされていませんでした。コミュニティでは、侵入テストについては認識していたものの、未修正の脆弱性を含む結果まですべて開示されることは想定していませんでした。Palo Alto Networksの研究チームを率いるアリエル・ゼリバンスキー(Ariel Zelivansky)は、すべての製品のセキュリティを強化するという精神のもと、コミュニティのリポジトリで#3982をオープンし、今後の情報開示や、予防のための改善策に向けたプロセスの調整について話し合いを重ねてきました。将来的には、開示時点で脆弱性が修正されるよう、脆弱性に関する調査結果をメンテナとベンダーの間で調整するのが理想的です。

2. Twistlock(※)でこれらの新しい脆弱性を検出することはできますか?

当社のインテリジェンスストリームは、多数のベンダーやアップストリーム・プロバイダーからの脆弱性データを使用して、お客様の各環境での脆弱性を特定するためのデータセットを構築します。今回のレポートは予期せずにリリースされ、多くの脆弱性にCVEが割り当てられていないため、多くのベンダーは自分たちのディストリビューションが脆弱かどうかを評価することができませんでした。ベンダーがこれらの評価を実施して調査結果を公開すると、インテリジェンスストリームがこれらの脆弱性を自動的に検出し、Twistlockで検出できるようになります。新たに公開された脆弱性のベンダー分析は、多くの場合は公開から数時間以内に、迅速に行われます。ただ今回は調査結果の量が多いことから、重大度の低い調査結果とCVEデータの公開は、少し時間がかかる場合があります。

お客様によるアクションは必要ありません。ベンダーが脆弱性データを公開した時点で、そのデータをインテリジェンスストリームが取得し、お客様の環境内での脆弱性を検出します。

3. Twistlockはこのような脆弱性からユーザーをどのように保護しますか?

Twistlockには、調査結果の問題点を解消できるように、さまざまな管理機能が搭載されています。今回の37件の調査結果のうち、影響度が高いと評価されたのは5件のみです。また、この5件のうち1件は、脆弱性ではなく推奨された拡張機能です。この5件の結果を以下で検証します。

4. Twistlockは、以下の問題に対してどのように対策しますか?

  1. Finding ID TOB-K8S-038: hostPath PersistentVolumes enable PodSecurityPolicy bypass (hostPathのPersistentVolumesでPodSecurityPolicyのバイパスが有効になる)

Twistlockには2つの緩和策があります。ひとつは、Kubernetesの監査モニタリングで特権を追加(ホストのマウントへのアクセス)して作成されたポッド について、アラートを生成することです。もうひとつは、ポッドがホストのマウントで作成された場合にアラート/ブロックする組み込みのコンプライアンス ルールを使うことです(Twistlockの55番目のコンプライアンス チェック)。

  1. Finding ID TOB-K8S-028: Kubernetes does not facilitate certificate revocation (Kubernetesでは証明書の失効処理が容易にできない)

この問題はセキュリティ面の強化のために提起されています。証明書チェーンのキーの再生成は非常に手のかかる作業です。このため、調査結果では、そのような作業を簡素化することを推奨しています。実用的なセキュリティ技術の進歩と考えられますが、これは脆弱性ではなく、ユーザーに今すぐ直接的なリスクをもたらすものでもありません。この問題はプラットフォームの強化に向けた提案であって、セキュリティ製品としての焦点の対象外です。

  1. Finding ID TOB-K8S-034: HTTPS connections are not authenticated (HTTPS接続が認証されない)

ここでの主なリスクは、最終的にetcdにアクセスする点です。ポッドは通常、etcdに直接アクセスしません。TwistlockのCloudNative Network Firewallは、通常のトラフィックパターンを自動的に学習するため、この異常な接続を見つけてブロックします。さらに攻撃には、悪意のあるkubeletを作成する必要があります。ここで、承認されたレジストリやリポジトリからのみソフトウェアを実行できるよう、ユーザーはTrusted Images機能を使用して影響を抑えることができます。

  1. Finding ID TOB-K8S-022: TOCTOU when moving PID to manager’scgroup via kubelet (kubelet経由でPIDをマネジャーのcgroupに移動する際に”Time Of Check vs Time Of Use”攻撃の可能性)

この脆弱性では、コンテナ内のプロセスによって、最終的にホスト上のデバイスに書き込みが行われます。ランタイム防御機能は、このようなタイプの攻撃を自動的に検出して防止します。Twistlockは、これが通常のファイル システムのアクセス動作ではないことを自動的に学習して防止します。

  1. Finding ID ATR-K8S-001: Improperly patched directory traversal in kubectl cp (kubectl cpのディレクトリ トラバーサル問題に対応する修正が不十分)

この問題はCVE-2019-1002101で管理されており、今年初めにゼリバンスキーによって発見されました。詳細については、元のブログ記事を参照してください。このCVEでは、悪意のあるイメージ(Trusted Images機能で回避できる)が使用されていますが、rootfsを読み取り専用にすることで解消できます。Twistlock ではこの問題に対して、コンプライアンス チェックを実施します。

(※)Twistlockは、2019年6月にPalo Alto Networksが買収したコンテナ セキュリティのリーダー企業Twistlock社のソリューションであり、今後、Palo Alto Networksのクラウド セキュリティ製品群Prismaに統合されます。クラウド ネイティブなアプリケーションやワークロードの脆弱性調査、コンプライアンス管理、振る舞い監視など、クラウド ネイティブなセキュリティ プラットフォーム実現のための機能を備えています。

Got something to say?