ACK クラスターにおけるマルチテナントセキュリティとは、共有クラスター内でテナント間のリソースを公平に割り当てるとともに、悪意のあるテナントが他のテナントに影響を与えることを防止する仕組みです。
隔離モデルの選択
マルチテナンシーは、隔離レベルに基づきソフト マルチテナンシーとハード マルチテナンシーに分類されます。
| ソフト マルチテナンシー | ハード マルチテナンシー | |
|---|---|---|
| 適用対象 | 信頼できるテナント（例：同一企業内の部門） | 信頼できないテナント（例：インフラストラクチャを共有する別組織） |
| 隔離メカニズム | Kubernetes ネイティブオブジェクト（名前空間、RBAC、ネットワークポリシー） | テナントごとの個別クラスター |
| コスト | 低 — リソースは共有される | 高 — クラスターごとにコントロールプレーン料金が発生し、リソース共有不可 |
| クラスター作成時間 | 名前空間の作成はほぼ即時 | クラスタープロビジョニングには大幅に長い時間がかかる |
| 適した業界 | 企業内プラットフォーム、KaaS、SaaS | 高度な規制対象業界、強固な隔離を必要とする SaaS |
各クラスターは強固なセキュリティ境界を提供します。クラスター内のホストへのアクセス権を攻撃者が取得した場合、そのホスト上にマウントされているすべての Secrets、ConfigMap、ボリュームを取得でき、kubelet を偽装してノード属性を操作したり、クラスター内で横方向に移動したりすることが可能です。この脅威を念頭に置いて、隔離モデルを選択してください。
ベストプラクティス： テナントが社内かつ信頼できる場合はソフト マルチテナンシーを使用してください。テナントが外部、信頼できない、または厳格な規制要件の対象となる場合はハード マルチテナンシーを使用してください。セキュリティ上の理由のみでハード マルチテナンシーをデフォルトとすることは避けてください。コストおよび運用オーバーヘッドが著しく大きくなります。
ソフト マルチテナンシー
ソフト マルチテナンシーでは、Kubernetes ネイティブリソース（名前空間、ロール、ロールバインディング、ネットワークポリシー）を使用して、テナント間に論理的な隔離を実現します。
ロールベースアクセス制御（RBAC）を使用して、テナントが互いのリソースにアクセスまたは変更できないようにします。
ResourceQuotas および LimitRanges を使用して、各テナントが消費できる CPU およびメモリを上限で制限します。
ネットワークポリシーを使用して、名前空間間の Pod 間通信をブロックします。
ノードレベルの隔離
上記のメカニズムでは、異なるテナントの Pod が同じノードを共有することを防げません。ノードレベルでの分離を強制するには、ノードセレクター、アンチアフィニティルール、Taint、Toleration を組み合わせて、各テナントの Pod を専用ノード（単一テナントノード）にスケジュールします。このアプローチは、特に多数のテナントがクラスターを共有する場合、コストと複雑さを増大させます。
ソフト マルチテナンシーでは、名前空間はグローバルスコープです。テナントが 1 つの名前空間へのアクセス権を持つ場合、クラスター内のすべての名前空間を表示できます。テナントに対してフィルターされた名前空間リストを提供する方法はありません。
デフォルトでは、テナントは CoreDNS にクエリを送信してクラスター内で実行中のすべてのサービスを列挙できます。攻撃者は、任意の Pod から dig SRV ..svc.cluster.local を実行することでこれを悪用できます。DNS アクセスを制限するには、ファイアウォールを設定するか、CoreDNS ポリシープラグインを使用してください。詳細については、「kubernetes-metadata-multi-tenancy-policy」をご参照ください。
ユースケース
企業環境
すべてのテナントが同一企業に属する場合、クラスター管理者が名前空間を作成し、ポリシーを一元的に管理します。ここではデリゲート管理モデルが有効です。具体的には、Deployment、Service、Pod、Job などのポリシーオブジェクト以外のオブジェクトに対して、特定のテナントに作成・読取・更新・削除（CRUD）操作の権限を付与し、管理者は引き続きポリシーオブジェクトの制御を保持します。
このシナリオでは、Docker の隔離モデルで十分です。より厳格な隔離が必要な場合は、Pod Security Policies（PSP）および名前空間レベルのネットワークポリシーも適用してください。
Kubernetes as a Service（KaaS）
KaaS 環境では、テナントが Platform as a Service（PaaS）機能を提供するコントローラーおよび CustomResourceDefinitions（CRD）をホストするクラスターを共有します。テナントは Kubernetes API サーバーに直接アクセスし、自身の名前空間を管理できます。テナントは信頼できないコードを実行していると見なされるため、厳格なネットワークポリシーを適用し、Pod サンドボックスを有効にしてください。詳細については、「サンドボックスコンテナ」をご参照ください。
Software as a Service（SaaS）
Software as a Service（SaaS）環境では、各テナントは Kubernetes RBAC とは別に独自のアクセス制御ポリシーを適用する専用アプリケーションインスタンスに関連付けられます。テナントは Kubernetes API サーバーに直接アクセスせず、SaaS アプリケーションが代わりに必要な Kubernetes オブジェクトを作成・管理します。
サービス階層を区別するには、Pod 優先度およびプリエンプションを使用します。プレミアム階層の顧客の Pod に高い優先度を割り当てることで、リソースが制約された場合に低優先度の Pod が最初にエビクトされるようにします。
Kubernetes 構成
名前空間
名前空間はソフト マルチテナンシーの基盤です。これらはクラスターを論理パーティションに分割し、ResourceQuotas、ネットワークポリシー、サービスアカウントなど、ソフトテナンシー関連のすべてのオブジェクトは名前空間スコープである必要があります。
認証、権限付与、アドミッション制御
Container Service for Kubernetes（ACK）の権限付与は、Resource Access Management（RAM）認可と RBAC 認可を組み合わせています。
RAM 認可 はクラスターレベルの操作（クラスターの作成・削除、クラスターのスケーリング、ノードの追加）を制御します。
RBAC 認可 は名前空間内の Kubernetes リソースに対してきめ細かなアクセス制御を提供します。
ACK では、一般的なテナントロール向けに事前定義されたロールテンプレートを提供しています。また、複数のカスタムクラスターロールを 1 人のユーザーにアタッチしたり、複数のユーザーに一度に権限を付与したりすることも可能です。詳細については、「RAM および RBAC を使用したアクセス制御の実装」をご参照ください。
ネットワークポリシー
デフォルトでは、クラスター内のすべての Pod が相互に通信できます。ネットワークポリシーは、ラベルまたは CIDR ブロックに基づいて通信を制限します。マルチテナント環境では、少なくとも次の 2 つのルールを追加してください。
すべての Pod 間通信をブロックするデフォルト拒否ルール。
DNS サーバーへの DNS クエリ送信を許可する許可ルール。
クォータとリミットレンジ
ResourceQuotas は、名前空間が消費できる CPU およびメモリの合計量を上限で制限します。LimitRanges は、個々の Pod の最小値、最大値、デフォルト値を設定します。
クォータがない場合、単一のテナントがクラスターリソースを枯渇させ、他のテナントの Pod がエビクトまたは再起動される可能性があります。マルチテナントクラスターのすべての名前空間に ResourceQuotas を追加し、テナントが Pod をスケジュールする際にリソースリクエストおよびリミットを宣言するようにしてください。KaaS 環境では、クォータを使用してクラスターリソースを各テナントに公平に割り当てます。
Pod 優先度およびプリエンプション
Pod 優先度およびプリエンプションにより、テナント間で異なるサービス品質（QoS）レベルを提供できます。リソース容量が不足している場合、kubelet は低優先度の Pod をエビクトして、高優先度の Pod のためのスペースを確保します。これは、プレミアム顧客がより高いサービス信頼性を期待する SaaS 環境で特に有効です。
緩和手法
Sandboxed-Container
Sandboxed-Container は代替コンテナランタイムであり、各 Pod を専用カーネルを備えた軽量仮想マシン内で実行します。これにより、標準コンテナランタイムよりも強固なリソース隔離と高いセキュリティ境界を提供します。
Sandboxed-Container は、信頼できないワークロード、障害分離、パフォーマンス隔離、テナント間のロード隔離に適しています。Docker と同様の運用体験（ロギング、モニタリング、弾力的スケーリングを含む）を、最小限のパフォーマンスオーバーヘッドで提供します。詳細については、「Sandboxed-Container の概要」をご参照ください。
Open Policy Agent（OPA）および Gatekeeper
Open Policy Agent（OPA）は、ポリシー決定を分離可能なポリシーエンジンです。RBAC の名前空間レベル隔離が不十分な場合、OPA は個々のオブジェクトレベルでのアクセス制御を可能にします。Gatekeeper は Kubernetes のアドミッションコントローラーであり、デプロイ時に OPA ポリシーを強制します。詳細については、「Gatekeeper」をご参照ください。
OPA はレイヤー 7 ネットワークポリシーや、ラベルおよびアノテーションに基づく名前空間間アクセス制御もサポートします。
Kyverno
Kyverno は Kubernetes ネイティブのポリシーエンジンであり、Kubernetes リソースの構成を検証・変更・生成します。検証には Kustomize スタイルのオーバーレイを、ミューテーションには戦略的マージパッチを使用し、設定可能なトリガーに基づいて名前空間間でリソースをクローンできます。詳細については、「Kyverno」および「ポリシーリポジトリ」をご参照ください。
Kyverno を使用して名前空間を隔離し、Pod セキュリティ標準およびその他のベストプラクティスを強制し、新規名前空間向けのネットワークポリシーなどのデフォルト設定を自動生成できます。
ハード マルチテナンシー
ハード マルチテナンシーでは、各テナントに個別のクラスターを作成し、インフラストラクチャレベルで強固な隔離を提供します。
主なトレードオフは以下のとおりです。
コスト： 各クラスターに個別のコントロールプレーン料金が発生します。クラスター間でコンピューティングリソースを共有できないため、未使用または過負荷のクラスターがリソースの断片化を引き起こします。
運用オーバーヘッド： 数百ものクラスターを長期的に管理するには、専用のツールが必要です。
プロビジョニング時間： クラスター作成には名前空間作成と比べて大幅に長い時間がかかります。
ハード マルチテナンシーは、高度な規制対象業界や、テナントが厳格なインフラストラクチャレベルの隔離を求める SaaS 環境に適しています。
今後の動向
Kubernetes マルチテナンシー特別興味グループ（SIG）は、ソフトおよびハード マルチテナンシーのギャップを埋める提案に積極的に取り組んでいます。
Virtual Cluster： 単一クラスター内で各テナント向けに API サーバー、コントローラーマネージャー、スケジューラーなどのコントロールプレーンコンポーネントの個別インスタンスを作成します（Kubernetes on Kubernetes）。詳細については、「Virtual Cluster」をご参照ください。
Hierarchical Namespace Controller（HNC）： Kubernetes Enhancement Proposal（KEP）で提案された HNC は、ポリシーオブジェクトの継承を伴う名前空間間の親子関係を定義します。テナント管理者はサブ名前空間を作成できます。詳細については、「HNC」をご参照ください。
Multi-Tenancy Benchmarks： 名前空間で隔離されたクラスターを安全に共有するためのガイドラインと、コンプライアンスを検証するための
kubectl-mtbCLI を提供します。詳細については、「Multi-Tenancy Benchmarks」をご参照ください。