Container Service for Kubernetes:マルチテナンシーのセキュリティ

ソフトマルチテナンシー

ネイティブのKubernetes の機能であるnamespace、Role、RoleBinding、ネットワークポリシー は、論理的なテナントの分離を提供します。RBAC は、テナントが互いのリソースにアクセスすることを防ぎます。クォータ とLimitRange はテナントごとのリソース消費を制御し、ネットワークポリシー は namespace 間の通信を制限します。

これらの制御では、異なるテナントのPod が同一ノードを共有することを防ぐことはできません。nodeSelector、アンチアフィニティ ルール、Taint、Toleration を使用して、テナントの Pod を専用ノードにスケジューリングします。テナント数が多い場合、このアプローチは複雑になり、コストもかさみます。

namespace を使用したソフトマルチテナンシーでは、namespace はクラスター スコープのリソースであるため、フィルタリングされた namespace のリストをテナントに提供することはできません。あるテナントが 1 つの namespace を表示できる場合、そのテナントはクラスター内のすべての namespace を表示できます。

デフォルトでは、テナントはクラスター内のすべてのサービスについてCoreDNS にクエリを実行できます。攻撃者は、任意のPod からdig SRV ..svc.cluster.local を実行することで、これを悪用する可能性があります。DNS レコードへのアクセスを制限するには、CoreDNS のファイアウォールまたはポリシー プラグインを使用します。「kubernetes-metadata-multi-tenancy-policy」をご参照ください。

• 社内エンタープライズ環境

  すべてのクラスター ユーザーは組織内のメンバーです。ID が管理されているため、セキュリティ リスクは管理可能です。各テナントは通常、部門やチームなどの管理単位に対応します。

  通常、クラスター管理者が namespace の作成とポリシーの管理を行います。委任モデルでは、個人に namespace に対する監督権限が付与され、Deployment、Service、Pod、Job などの非ポリシーオブジェクトに対するCRUD 操作が許可されます。

  ここでは Docker の分離メカニズムで十分です。追加の制御として Pod Security Policy (PSP) を追加します。より厳格な分離のためには、namespace 間のサービス通信も制限します。

• Kubernetes as a Service (KaaS)

  ソフトマルチテナンシーは、Kubernetes as a Service (KaaS) を提供する場合に適用されます。アプリケーションは、コントローラーと CRD が PaaS サービスを提供する共有クラスターでホストされます。テナントは Kubernetes API サーバーと直接対話し、非ポリシーオブジェクトに対して CRUD 操作を実行し、独自の namespace を作成および管理できます。テナントは信頼できないコードを実行すると想定されます。

  厳格なネットワークポリシーと Pod のサンドボックス化によってテナントを分離します。

• Software as a Service (SaaS)

  各テナントは、クラスター内の特定のアプリケーション インスタンスに関連付けられています。各インスタンスは独自のデータを持ち、多くの場合Kubernetes RBAC から独立した、個別のアクセス制御メカニズムを使用します。

  テナントはKubernetes API と直接対話しません。SaaS アプリケーションがKubernetes API と対話し、各テナントのオブジェクトを作成します。

Kubernetesのネイティブ設定

Kubernetes は、1 つのコントロールプレーン インスタンスをすべてのテナントで共有する、シングルテナントのオーケストレーションプラットフォームです。namespace とRBAC でテナントを論理的に分離し、リソースクォータ とLimitRange でテナントごとのリソース消費を制御します。しかし、クラスターが唯一の強力なセキュリティ境界です。ホストにアクセスできる攻撃者は、そのホスト上のすべてのSecret、ConfigMap、Volume を取得し、Kubelet になりすまし、ラテラルムーブメントを行うことができます。以下の設定は、これらのリスクを軽減します。

• namespace

  namespace はソフトマルチテナンシーの基盤であり、クラスターを論理的なレイヤーに分割します。リソースクォータ、ネットワークポリシー、サービスアカウント、およびその他のリソースは、namespace スコープ内で動作します。

• 認証、認可、アドミッション

  ACK クラスターの認可には、RAM 認可と RBAC 認可の 2 つのステップがあります。RAM 認可は、クラスターの可視性、スケーリング、ノードの追加などの CRUD 権限を含む、クラスター管理インターフェイスを制御します。RBAC 認可は、きめ細かな namespace レベルの権限で Kubernetes リソースへのアクセスを制御します。ACK は、事前定義されたロール テンプレートを提供し、ユーザー定義のクラスターロールのバインドや、ユーザーの一括認可をサポートしています。詳細については、「Authorization overview」をご参照ください。

• ネットワークポリシー

  デフォルトでは、Kubernetes クラスター内のすべての Pod は互いに通信することが許可されています。このデフォルトの動作を変更するには、ネットワークポリシーを使用します。

• ネットワークポリシーは、ラベルまたは IP アドレス範囲を使用して Pod の通信を制限します。厳格なテナントの分離のためには、次の 2 つのルールを追加します。

  • Pod 間の通信を拒否するデフォルトのルール。

  • すべての Pod が名前解決のために DNS サーバーにクエリを実行することを許可するルール。

• リソースクォータと LimitRange

  リソースクォータは、クラスターまたは namespace ごとの CPU、メモリ、およびリソース数に上限を設定します。LimitRange は、各 limit の最小値、最大値、およびデフォルト値を設定します。

  リソースをオーバーコミットすると使用率は最大化されますが、無制限のアクセスはリソーススタベーションを引き起こし、パフォーマンスと可用性を低下させる可能性があります。Pod の request が低すぎ、実際の使用量がノードの容量を超えると、ノードは CPU またはメモリのプレッシャーを受け、Pod の再起動や退去が発生します。

  namespace にリソースクォータを適用して、テナントに request と limit の指定を要求します。これにより、Pod ごとのリソース消費に上限を設けることで、サービス拒否 (DoS) のリスクも軽減されます。

  KaaS のシナリオでは、リソースクォータを使用して、テナントのニーズに合わせたリソースを割り当てます。

• Pod の優先度とプリエンプション

  Pod の優先度とプリエンプションにより、顧客に対してさまざまな QoS レベルを有効にできます。容量が不足している場合、優先度の高い Pod が優先度の低い Pod をプリエンプションします。SaaS 環境では、より良い QoS に対価を支払う意思のある顧客にサービスを提供します。

緩和策

マルチテナント環境のセキュリティ管理者として、主な目標は攻撃者が基盤となるホストにアクセスするのを防ぐことです。このリスクを軽減するために、以下の制御を適用します。

• Sandboxed-Container

  Sandboxed-Container は、独立したカーネルを持つ軽量な仮想マシン サンドボックス内でアプリケーションを実行し、標準の Docker ランタイムよりも強力な分離を提供します。

  Sandboxed-Container は、信頼できないアプリケーションの分離、障害分離、パフォーマンス分離、マルチユーザー ワークロードの分離などのシナリオに適しています。パフォーマンスへの影響は最小限であり、ロギング、モニタリング、弾力性の点で Docker コンテナと同じエクスペリエンスを提供します。詳細については、「Sandboxed-Container」をご参照ください。

• Open Policy Agent (OPA) と Gatekeeper

  RBAC の namespace レベルの分離では不十分な場合、Open Policy Agent (OPA) はオブジェクトモデル レベルできめ細かいアクセス ポリシー制御を提供します。Gatekeeper は、デプロイ時に OPA ポリシーを適用するアドミッションコントローラーです。

  OPA は、ラベルとアノテーションに基づくレイヤー 7 のネットワークポリシーと namespace 間のアクセス制御もサポートしており、ネイティブの Kubernetes のネットワークポリシーを強化します。

• Kyverno

  Kyverno は、リソース ポリシーを検証、変更、生成する Kubernetes ポリシーエンジンです。Kustomize スタイルの検証をサポートし、柔軟なトリガーに基づいて namespace 間でリソースをクローンできます。

  Kyverno を使用して、namespace を分離し、Pod セキュリティのベストプラクティスを実装し、ネットワークポリシーなどのデフォルト設定を生成します。「ポリシーリポジトリ」をご参照ください。

ハードマルチテナンシー

今後の方向性

Kubernetes コミュニティは、ソフトマルチテナンシーの限界とハードマルチテナンシーの課題を認識しています。Multi-Tenancy Special Interest Group (SIG) は、いくつかのインキュベーションプロジェクトを通じてこれらの課題に取り組んでいます。

• Virtual Cluster の提案では、各テナントに対して個別のコントロールプレーン インスタンス (API サーバー、controller manager、scheduler) を作成します。これは「Kubernetes on Kubernetes」としても知られています。

• Hierarchical Namespace Controller (HNC) の提案では、ポリシーオブジェクトの継承とテナント管理のサブ namespace を通じて、親子関係の namespace を実現します。

• Multi-Tenancy Benchmarks の提案では、namespace の分離に関するガイドラインと、コンプライアンスを検証するための CLI ツールである Kubectl-mtb を提供します。