セキュリティモデル

8分で読めます

このドキュメントは、Istioのさまざまなコンポーネントのセキュリティ態勢と、起こりうる攻撃がシステムにどのように影響するかを説明することを目的としています。

コンポーネント

Istioには、ここで説明するさまざまなオプションのコンポーネントが付属しています。概要については、Istioアーキテクチャを参照してください。Istioのデプロイは非常に柔軟であることに注意してください。以下では、主に最悪のシナリオを想定します。

Istiod

Istiod は Istio のコアコントロールプレーンコンポーネントとして機能し、多くの場合、XDS サービスコンポーネントとしての役割と、メッシュの mTLS 証明書認証局としての役割を果たします。

Istiod は、Kubernetes API サーバー自体と同様に、非常に特権的なコンポーネントと見なされています。

通常、Secret の読み取りアクセスや webhook の書き込みアクセスなど、高い Kubernetes RBAC 特権を持っています。
CA として機能する場合、任意の証明書をプロビジョニングできます。
XDS コントロールプレーンとして機能する場合、プロキシに任意の動作を実行させるようにプログラムできます。

そのため、クラスターのセキュリティは Istiod のセキュリティと密接に結びついています。Istiod のアクセスに関する Kubernetes のセキュリティベストプラクティスに従うことが最も重要です。

Istio CNIプラグイン

Istio は、オプションで Istio CNI プラグイン DaemonSet を使用してデプロイできます。この DaemonSet は、トラフィックが必要に応じて透過的にリダイレクトされるように、Istio でネットワークルールを設定する役割を担います。これは、後述する istio-init コンテナの代替となります。

CNI DaemonSet はノード上のネットワークルールを変更するため、昇格された securityContext が必要です。ただし、Istiod とは異なり、これはノードローカルの特権です。これによる影響については、後述します。

ネットワークのセットアップに必要な昇格された特権を、すべての Pod ではなく、単一の Pod に集約するため、このオプションが一般的に推奨されます。

サイドカープロキシ

Istio は、アプリケーションの隣にサイドカープロキシをオプションでデプロイできます。

サイドカープロキシは、すべてのトラフィックをプロキシ経由でルーティングするようにネットワークをプログラムする必要があります。これは、Istio CNI プラグインを使用するか、Pod に initContainer (istio-init) をデプロイすることで実行できます (CNI プラグインがデプロイされていない場合は自動的に実行されます)。istio-init コンテナには、NET_ADMIN および NET_RAW の機能が必要です。ただし、これらの機能は初期化中にのみ存在し、プライマリサイドカーコンテナは完全に特権がない状態です。

さらに、サイドカープロキシには、関連する Kubernetes RBAC 特権は一切必要ありません。

各サイドカープロキシは、関連する Pod サービスアカウントの証明書を要求する権限を持っています。

ゲートウェイとウェイポイント

ゲートウェイと、ウェイポイントは、スタンドアロンのプロキシデプロイとして機能します。サイドカーとは異なり、ネットワークの変更は必要ないため、特権は必要ありません。

これらのコンポーネントは、アプリケーションの ID とは異なる、独自のサービスアカウントで実行されます。

Ztunnel

Ztunnel はノードレベルのプロキシとして機能します。このタスクには、NET_ADMIN、SYS_ADMIN、および NET_RAW の機能が必要です。Istio CNI プラグインと同様に、これらはノードローカルの特権のみです。Ztunnel には、関連する Kubernetes RBAC 特権はありません。

Ztunnel は、同じノードで実行されている Pod のサービスアカウントの証明書を要求する権限を持っています。kubelet と同様に、これは明示的に任意の証明書を要求することを許可しません。これにより、これらの特権がノードローカルのみであることが保証されます。

トラフィックキャプチャのプロパティ

Pod がメッシュに登録されると、すべての受信 TCP トラフィックがプロキシにリダイレクトされます。これには、mTLS/HBONE トラフィックとプレーンテキストトラフィックの両方が含まれます。ワークロードに適用可能なポリシーはすべて、トラフィックをワークロードに転送する前に適用されます。

ただし、Istio は現在、送信トラフィックがプロキシにリダイレクトされることを保証していません。トラフィックキャプチャの制限を参照してください。そのため、アウトバウンドポリシーが必要な場合は、アウトバウンドトラフィックを保護する手順に従うように注意する必要があります。

相互TLSプロパティ

相互 TLS は、Istio のセキュリティ体制の大部分の基礎を提供します。以下では、相互 TLS が Istio のセキュリティ体制に提供するさまざまな特性について説明します。

認証局

Istio には、独自の認証局が組み込まれています。

デフォルトでは、CA は以下のいずれかのオプションに基づいてクライアントを認証できます。

Kubernetes TokenReview で検証される、istio-ca のオーディエンスを持つ Kubernetes JWT トークン。これが Kubernetes Pod のデフォルトの方法です。
既存の相互 TLS 証明書。
OIDC を使用して検証されるカスタム JWT トークン (構成が必要)。

CA は、クライアントが認証されている ID に対して要求された証明書のみを発行します。

Istio は、さまざまなサードパーティの CA とも統合できます。それらの動作の詳細については、それぞれのセキュリティドキュメントを参照してください。

クライアントmTLS

サイドカーモードでは、クライアントサイドカーは、mTLS をサポートしていると検出されたサービスに接続する際に、自動的に TLS を使用します。これは、明示的に構成することもできます。この自動検出は、Istio がトラフィックをサービスに関連付けることに依存していることに注意してください。サポートされていないトラフィックの種類または構成スコープによって、これが妨げられる場合があります。

バックエンドに接続する場合、許可される ID のセットは、すべてのバックエンドの ID の和に基づいて、サービスレベルで計算されます。

サーバーmTLS

デフォルトでは、Istio は mTLS および非 mTLS トラフィック (しばしば「許可モード」と呼ばれる) を受け入れます。ユーザーは、mTLS を必要とする PeerAuthentication または AuthorizationPolicy ルールを記述することで、厳格な適用を選択できます。

mTLS 接続が確立されると、ピア証明書が検証されます。さらに、ピア ID が同じ信頼ドメイン内にあることが検証されます。特定の ID のみが許可されることを検証するには、AuthorizationPolicy を使用できます。

検討された侵害の種類

上記の概要に基づいて、システムのさまざまな部分が侵害された場合にクラスターに与える影響について検討します。現実の世界では、セキュリティ攻撃に関するさまざまな変数が存在します。

実行の容易さ
必要な事前の特権
悪用できる頻度
影響 (完全なリモート実行、サービス拒否など)。

このドキュメントでは、主に最悪のシナリオを考慮します。つまり、侵害されたコンポーネントは、攻撃者が完全なリモートコード実行機能を持っていることを意味します。

ワークロードの侵害

このシナリオでは、アプリケーションワークロード (Pod) が侵害されています。

Pod は、サービスアカウントトークンへのアクセス権を持つ可能性があります。その場合、ワークロードの侵害は、単一の Pod からサービスアカウント全体の侵害にまで拡大する可能性があります。

サイドカーモデルでは、プロキシは Pod と同じ場所に配置され、同じ信頼境界内で実行されます。侵害されたアプリケーションは、管理 API やその他のサーフェスを介してプロキシを改ざんすることができます。これには、秘密鍵マテリアルの流出が含まれ、別のエージェントがワークロードを偽装できるようになります。侵害されたワークロードには、サイドカープロキシの侵害も含まれていると想定する必要があります。

このため、侵害されたワークロードは次の可能性があります。

相互 TLS の有無にかかわらず、任意のトラフィックを送信します。これらは、プロキシの構成や、プロキシ自体を完全にバイパスする可能性があります。Istio は、エグレスベースの承認ポリシーを提供していないため、エグレス承認ポリシーのバイパスは発生しないことに注意してください。
すでにアプリケーションに宛先指定されていたトラフィックを受け入れます。サイドカープロキシで構成されていたポリシーをバイパスする可能性があります。

ここで重要なのは、侵害されたワークロードが悪意のある動作をする可能性がありますが、これにより、他のワークロードのポリシーをバイパスする機能が得られるわけではないということです。

Istio は、このような侵害の影響を制限できるさまざまな機能を提供します。

監視機能を使用して、攻撃を特定できます。
ポリシーを使用して、ワークロードが送受信できるトラフィックの種類を制限できます。

プロキシの侵害 - サイドカー

このシナリオでは、サイドカープロキシが侵害されています。サイドカーとアプリケーションは同じ信頼ドメイン内にあるため、これは機能的にワークロードの侵害と同等です。

プロキシの侵害 - ウェイポイント

このシナリオでは、ウェイポイントプロキシが侵害されています。ウェイポイントには、ハッカーが悪用できる特権はありませんが、(潜在的に) 多くの異なるサービスとワークロードを提供します。侵害されたウェイポイントは、これらすべてのトラフィックを受信し、表示、変更、または削除できます。

Istio は、ウェイポイントデプロイの粒度を構成する柔軟性を提供します。より強力な隔離が必要な場合は、より隔離されたウェイポイントのデプロイを検討できます。

ウェイポイントは、サービスを提供するアプリケーションとは異なる ID で実行されるため、侵害されたウェイポイントは、ユーザーのアプリケーションを偽装できることを意味しません。

プロキシの侵害 - Ztunnel

このシナリオでは、ztunnel プロキシが侵害されています。

侵害されたztunnelは、攻撃者にノードのネットワーク制御を許します。

Ztunnelは、ノード上で実行されている各アプリケーションの秘密鍵素材にアクセスできます。侵害されたztunnelは、これらを漏洩させ、他の場所で使用される可能性があります。ただし、同一ノードに配置されたワークロードを超えるアイデンティティへの水平移動は不可能です。各ztunnelは、そのノードで実行されているワークロードの証明書にのみアクセスが許可されており、侵害されたztunnelの影響範囲を限定します。

ノードの侵害

このシナリオでは、Kubernetesノードが侵害されています。KubernetesとIstioはどちらも、単一ノードの侵害の影響範囲を制限するように設計されており、単一ノードの侵害がクラスター全体の侵害につながらないようにしています。

ただし、攻撃者はそのノードで実行されているすべてのワークロードを完全に制御できます。たとえば、同じ場所に配置されているウェイポイント、ローカルのztunnel、任意のサイドカー、同じ場所に配置されているIstiodインスタンスなどを侵害できます。

クラスター（APIサーバー）の侵害

Kubernetes APIサーバーの侵害は、事実上、クラスター全体とメッシュが侵害されたことを意味します。他のほとんどの攻撃ベクトルとは異なり、Istioがそのような攻撃の影響範囲を制御するためにできることはあまりありません。侵害されたAPIサーバーは、ハッカーにクラスターを完全に制御させ、任意のポッドでkubectl execを実行したり、IstioのAuthorizationPoliciesを削除したり、Istioを完全にアンインストールしたりするなどのアクションを実行できます。

Istiodの侵害

Istiodの侵害は、一般的にAPIサーバーの侵害と同じ結果になります。Istiodは、厳重に保護する必要がある非常に特権的なコンポーネントです。セキュリティのベストプラクティスに従うことは、安全なクラスターを維持するために非常に重要です。