クラウド環境
Kubernetesの脅威モデリングに関する考察
このレポートでは、世界中の多くの組織が依存するテクノロジであり、主要なコンテナオーケストレーションプラットフォームであるKubernetesの環境内で脅威モデリングを適切に実行するために必要となる観点と、その懸念事項について探ります。
Kubernetesは事実上、ほとんどの組織が好んで選択するコンテナオーケストレーションプラットフォームとなっています。しかしよく言われるように、偉大なる力には大きな責任が伴います。
世界中の多くの企業で使用されているというKubernetesの功績は大きいものですが、習得が難しく、環境も複雑に絡み合っているという理由から、その使用には適切に保護するという課題が伴います。その主要な2つの問題が、セキュリティのデフォルト設定と設定ミスです。
これらの問題を開発ライフサイクルの早い段階で検知する方法の1つに、脅威モデリング手法の利用があります。今回の調査の第1部では、Kubernetes環境で脅威モデリングを適切かつ徹底的に実行するために必要となるすべての観点と、その懸念事項について詳しく探ります。トップダウンのアプローチを採用し、Kubernetesクラスタを構成する各要素の複雑さや微妙な違いを掘り下げる前に、まずはより大きな最も重要となる観点について議論します。
脅威モデリング
この分野の経験豊富な専門家たちによって作成された脅威モデリングマニフェストによると、脅威モデリングとは、システムの表現を分析し、セキュリティとプライバシーの特性に関する懸念を浮き彫りにすることです。それは潜在的な脅威を体系的に特定し、優先順位を付け、文書化するプロセスであり、その主な目的は、脅威と脆弱性を特定し、それらを軽減する適切なセキュリティ制御を設計するための、構造化されたアプローチをシステム設計者とアーキテクトに提供することです。
しかしなぜ脅威モデルに従うことが不可欠なのでしょうか。前述したように、脅威モデリングはセキュリティの問題を早期に（場合によっては発生前に）特定して軽減するのに役立ちます。これにより組織は、問題の解決に必要となる費用と時間の両方を節約できます。さらに脅威モデルは、複雑なリスクを特定し、データフローをマッピングして、脅威をより深く理解することにも役立ちます。
脅威モデリングを実行する際、すべてに対応する万能の方法はないことに注意してください。システムやアプリケーションは多種多様で複雑なため、標準的な脅威モデリングシナリオを作成することは難しく、一般的なシナリオを自動化することさえ困難です。そのため、このプロセスの担当者は、ステップごとに細心の注意を払うことが有益です。
Microsoftセキュリティ開発ライフサイクル（SDL）によると、脅威モデリングのプロセスには5つの主要なステップがあります。
- セキュリティ要件の定義
- アプリケーション図の作成
- 脅威の特定
- 脅威の軽減
- 脅威が軽減されたことの検証
これらの5つのステップにより、脅威を特定、軽減、および検証するための体系的アプローチが実現されます。
特に、クラウドネイティブシステムのレイヤを分析すると、これらのステップを適切に実行するのに役立ちます。
クラウドネイティブシステムの4つのC
Kubernetesが属するクラウドネイティブシステムのセキュリティモデルは、4つのC（クラウド、クラスタ、コンテナ、コード）のそれぞれが、その前の最も外側のレイヤ上に構築されるように構成されています。したがってコードレイヤのサイバーセキュリティは、クラウドレイヤ、クラスタレイヤ、コンテナレイヤを基盤とした堅牢なセキュリティで強化されています。
コードレベルだけでなく、4つのCをすべて保護することが重要です。これは、サイバーセキュリティ対策をコードレベルで実装するだけでは、他の基盤となるレイヤの脆弱なセキュリティ標準を補うことはできず、むしろそれによりシステム全体が脆弱なままになるためです。
次のセクションでは、クラスタレイヤについて考察し、Kubernetesクラスタを構成する各コンポーネントと、それらが正しく設定されていない場合に攻撃者が利用できる方法について取り上げます。さらに、コードレイヤとコンテナレイヤに関する問題に加えて、それらを保護する方法についても議論します。
クラスタのコンポーネント
Kubernetesのアーキテクチャ設計は、相互に連結する一時的で独立したオブジェクトの原則に基づいています。次の図は、Kubernetesクラスタの2つの主要なコンポーネントである、コントロールプレーンとワーカノードを示しています。図にあるように、これらには一連のサブコンポーネントが含まれています。
コントロールプレーン
Kubernetesのコントロールプレーンはクラスタの最高位ノードとして動作し、ワーカノードを監視します。中枢神経系として機能することで、複雑な構造を運用可能で最適な状態に維持します。その主要なコンポーネントには次のものがあります。
- kube-apiserver：APIサーバです。Kubernetesのコントロールプレーンに不可欠な要素であり、Kubernetes APIに対するゲートウェイとして機能します。APIコールを送受信することで、Kubernetesのコントロールプレーンのユーザインタフェースとして機能します。
- etcd：クラスタの心臓部であり、Kubernetesがすべての内部情報を保存するデータベースです。どのノードがクラスタの一部であり、どのリソースが存在するかなど、すべてのクラスタデータに対するKubernetesのリポジトリとして機能します。Key-Valueストアは信頼性が高く、常にアクセス可能です。
- kube-scheduler：どのノードにもまだ割り当てられていない新しいポッドの作成を監視し、それらが動作するノードを指定するコンポーネントです。ポッドが実行される場所を決定します。
- kube-controller-manager：ノードコントローラ、ポッドコントローラ、サービスコントローラなどのコントローラプロセスを介してクラスタのさまざまな内部タスクを処理します。
- cloud-controller-manager：クラウド特有の制御ロジックを組み込んだコンポーネントです。これにより、クラスタとクラウドプロバイダのAPIとの統合が可能になります。またクラウドプロバイダと対話し、ロードバランサやディスクボリュームなどのリソースを管理します。
ワーカノード
コントロールプレーンを操作の中枢とみなすと、ワーカノードはシステムの腕力のようなもので、クラスタ内のすべてのポッドとコンテナを実行および管理します。クラスタにはゼロから多数のワーカノードを含めることができますが、通常、コントロールプレーンと同じノードでポッドを操作することは推奨されません。ワーカノードの主要なコンポーネントには次のものがあります。
- kubelet：クラスタ内のすべてのノードで動作するエージェントで、その主な役割は、ポッド内のコンテナが正しく機能していることを確認することです。コンテナランタイムが必要に応じてコンテナを実行するかどうかを監視し、実行情報を収集します。
- kube-proxy：クラスタ内のすべてのノードで動作するネットワークプロキシです。ネットワーク通信を管理し、さまざまなコンテナが相互に通信できるようにします。外部リクエストにも対応します。
- コンテナランタイム：コンテナの実行を担当するソフトウェアを指します。コンテナ自身を作成して実行するのもコンテナランタイムです。これは通常、Docker、containerd、またはCRI-Oになります。
ポートとプロトコル
Kubernetesのコンポーネントで使用されるポートやプロトコルを理解することは、特にネットワークファイアウォールを備えた物理データセンターやパブリッククラウド内の仮想ネットワークなど、厳格なネットワークパラメータを用いた設定でシステムを運用する際に役立ちます。コントロールプレーンとワーカノードそれぞれのポートとプロトコルの概要を次に示します。
コントロールプレーン
ワーカノード
ここで、Cloud Native Computing Foundation（CNCF）Financial Services User Groupが提供する上記のデータフロー図を使用して、いくつかの主要なクラスタコンポーネントと、それらを脅威アクタがどのように悪用できるかについて分析します。
Kube APIサーバ
前述したように、Kube APIサーバはKubernetes APIに対するゲートウェイであり、ユーザアカウントとサービスアカウントの両方にアクセスを提供します。すべての通信はTLSで暗号化され、デフォルトではポート6443（マネージドKubernetesの場合は443）を介して提供されます。次の図（Kubernetes.ioで紹介している元の図から再作成したもの）は、APIサーバへのすべてのリクエストで行われる主な手順を示しています。
- 認証（AuthN）
- 認可（AuthZ）
- アドミッションコントロール
これまでの記事で、トレンドマイクロは外部に公開されているKubernetesクラスタの危険性について一貫して警告してきました。それでも、認証が有効になっているかクラスタに脆弱性がない限り、kube-apiserverへの認証されていないアクセスで攻撃者ができることは限られています。認証されていない（匿名の）APIリクエストを受け入れるAPIエンドポイントには、次のようなものがあります。
- /version
- /healthz
- /livez
- /readyz
この場合、ほとんどの企業は、仮想プライベートネットワーク（VPN）や企業の内部ネットワークなど、特定のIPアドレスまたはClassless Inter-Domain Routing（CIDR）の範囲を介してのみクラスタにアクセスできるように制限しています。これにより、攻撃対象領域が減少し、侵害が発生した場合の影響範囲が制限されます。
kubelet
kubeletは、クラスタのすべてのノードにデプロイされるエージェントで、ポッド内のすべてのコンテナが確実に動作するようにします。また、ノードの設定変更を実装するエージェントとしても機能します。Kubernetesの主なアーキテクチャ図には描かれていないかもしれませんが、マスターノードでもkubelet（およびkube-proxy）エージェントを操作し、そこで追加のポッドを実行できます。ただし、Kubernetesを実行するコンテナとユーザのアプリケーションを管理するコンテナは分離する必要があるため、この方法は一般的には推奨されません。
kubelet APIはデフォルトでポート10250を使用します。このポートは、APIサーバコントロールプレーンとワーカノードの両方を含む、クラスタ内のすべてのノードで開かれていますが、通常、その公開先は内部に限定され、外部サービスからはアクセスできません。一方、他の認証方法でブロックされていないkubeletのAPIエンドポイントへのリクエストは、デフォルトで匿名とみなされます。文書化されていないkubeletのAPIエンドポイントの1つに_/runningpods_がありますが、これはkubeletが属するノードで稼働しているすべてのポッドに関する情報を提供します。また、ユーザがポッドで直接コマンドを実行できる_/run_エンドポイントもあります。
kubeletのセキュリティ設定は、次の極めて重要な3つの要素に依存します。
- kubelet認証を有効にする。Kubernetesのドキュメントに記載されているように、kubeletのAPIエンドポイントに対して行われるリクエストは、他の認証方法でブロックされていない限りデフォルトで匿名リクエストになります。匿名アクセスを無効にするには、_--anonymous-auth=false_フラグを使用してkubeletを起動することをお勧めします。詳細については、kubelet認証について公式のKubernetesガイドラインを参照してください。
- kubeletの権限を制限し、kubelet認証情報を保護する。これにより、コンテナからエスケープした後に有害なアクションを実行しようとする可能性のある、潜在的な攻撃者から認証情報を保護できます。
- kubelet認証情報を定期的に変更する。こうした有効期限の短い証明書は、セキュリティ侵害が発生した場合に潜在的な損害を制限するのに役立ちます。
etcd
etcdは、すべてのクラスタオブジェクトを格納する、クラスタの主要なストレージとして機能します。その階層的で標準化された構造のため、Kubernetesデプロイメントでは、REST APIオブジェクトとインストール設定を保持するためにetcdが使用されています。etcdが外部に公開されると、重大なデータ漏えいが意図せず発生する可能性があります。残念ながら、誤って設定されたetcdインスタンスは依然として広く存在しており、今年、4,000件を超えるそのような公開されたサービスがShodanで検知されました。
Kubernetesの脅威モデリングを実行するためのもう1つのアプローチは、コンテナ用のMITRE ATT&CKを利用することです。この最初のバージョンは、MITREとトレンドマイクロの研究チームとの協力によって2021年に公開されました。現時点では、脅威アクタが実際のコンテナやクラスタを侵害するために利用する手法とサブ手法が規定されています。このマトリックスを利用することで、組織は、これらの環境で攻撃者が悪用する最も一般的な弱点に注目することができます。ここでは、コンテナオーケストレーションとKubernetesに関連するいくつかの弱点について分析します。
T1609 – Container Administration Command（コンテナ管理コマンド）。必要な権限が与えられると、攻撃者はkube-apiserver、kubelet、またはkubectl execコマンドを介して、ポッドやコンテナに対してリモートからコマンドを実行することができます。この弱点を頻繁に悪用した脅威アクタの1つがTeamTNTです。これを検知するには、疑わしいコマンドが実行されていないか、Kubernetes監査ログなどの適切なログを監視することが重要です。前述したように、Kubernetes APIエンドポイントは、適切に保護されていない場合、この手法を使用して悪用される可能性があります。以下は、脅威アクタがmasscanを使用し、ネットワーク内から直接kubelet APIエンドポイントを見つけてアクセスし、稼働中のポッドに対して直接コマンドを実行する例を示しています。
T1611 – Escape to Host（ホストへのエスケープ）。コンテナやポッドといった牢獄からのエスケープは、何も新しいことではありません。それでも、この権限昇格の手法により、クラスタの設定方法によっては、攻撃者がワーカノードやコントロールプレーンノードにすらアクセスできる可能性があります。MITREによると、ホストへのアクセスを取得することで、敵対者は、永続化、横展開（ラテラルムーブメント）、コマンドアンドコントロール（C&C）チャネルの設定といった新たな目的を達成できる可能性があります。以下は、IsovalentのフィールドCTOであるDuffie Cooley氏による、有名かつ現在でも（ほとんどの場合に）機能するポッドエスケープ手法です。
T1613 – Container and Resource Discovery（コンテナとリソースの検出）。攻撃者がさまざまなシステムを侵害するために使用する主な手法の1つは、偵察です。彼らはこれを、ホストを侵害する前後に広範囲に使用する傾向があります。コンテナやKubernetesの場合も同じです。攻撃者は、Nmap、masscan、zgrabなどのネットワークおよびポートスキャンツールを利用して、これらのアクションを実行します。MITREによると、不審なユーザによる検出コールなど、ポッド情報収集アクションのログを監視することが不可欠です。
以下は、Kubernetesクラスタを攻撃するTeamTNTの悪意のあるスクリプトコードの例です。クラウド環境やコンテナ環境を標的にすることで知られるこの脅威グループは、2021年に活動の終了を表明しました。しかし、TeamTNTに一致する戦術を特徴とする最近の活動は、このグループがまだ活動しているのか、それとも他のグループがその手法を模倣しているだけなのかという疑問を提起しています。
T1610 – Deploy Container (or Pod)（コンテナ（またはポッド）のデプロイ）。攻撃者が必要な権限を持っている場合、これはさまざまな理由から実行される可能性があります。その1つは、前述したように、特権ポッドのデプロイを介してホストにエスケープすることです。もう1つの理由であり、最も一般的なシナリオは、暗号通貨マイニングツールを備えた新しいコンテナをデプロイし、暗号通貨（主にMonero）のマイニングを開始することです。これは、Kube APIサーバを介して直接実行することも、図10（T1611）に示すようなkubectlコマンドを介して実行することもできます。次のスクリーンショットは、Kubernetesクラスタの攻撃に使用されたラボ環境のAmazon CloudWatchログから取得したもので、Elastic Kubernetes Service（EKS）での悪意のあるアクションのポッドデプロイの別の例です。
まとめ
Kubernetesは習得が難しく、デフォルトでは保護されていません。Kubernetesを保護するには、主要コンポーネントがどのように機能し、攻撃者がこれらをどのように利用できるかを理解することが不可欠です。したがって組織は、Kubernetesクラスタをデプロイおよび管理する際のセキュリティを強化するため、この記事で取り上げた内容を念頭に置いておく必要があります。Kubernetesのセキュリティに関する詳細な洞察については、この記事の第2部で、Kubernetesを取り巻く脅威と脆弱性についてさらに深く掘り下げます。
参考記事
A Deep Dive Into Kubernetes Threat Modeling
By: Magno Logan