Azure Kubernetes Service (AKS) のネットワーク分離を構成する

完了

Azure Kubernetes Service (AKS) でクラスターを管理する際は、多くの場合、チームとワークロードを分離する必要があります。 AKS を使用すると、柔軟にマルチテナント クラスターを実行してリソースを分離することができます。 Kubernetes への投資を最大限に活用するには、AKS のマルチテナントおよび分離機能を理解することが重要です。

マルチ テナント用にクラスターを設計する

Kubernetes では、同じクラスター内のチームとワークロードを論理的に分離できます。 目標は、各チームが必要とするリソースに限定して、最小限の数の特権を提供することです。 Kubernetes の名前空間では、論理的な分離境界が作成されます。 その他の Kubernetes の機能および分離とマルチテナントに関する考慮事項には、次の領域が含まれます。

  • Azure Kubernetes Services (AKS) でのクラスターの分離に関するベスト プラクティス
    • マルチ テナント用にクラスターを設計する
      • スケジュール設定
      • ネットワーク
      • 認証と権限承認
      • Containers
  • 論理的に分離されたクラスター
  • 物理的に分離されたクラスター

スケジュール設定

"スケジュール設定" では、リソース クォータやポッドの中断バジェットなどの基本的な機能を使用します。

より高度なスケジューラ機能は次のとおりです。

  • テイントと容認。
  • ノード セレクター。
  • ノードとポッドのアフィニティまたは非アフィニティ。

ネットワーク

"ネットワーク" では、ポッド内外のトラフィックのフローを制御するためのネットワーク ポリシーが使用されます。

認証と権限承認

"認証と認可" では次のものが使用されます。

  • ロール ベースのアクセス制御 (RBAC)。
  • Microsoft Entra 統合。
  • ポッド ID。
  • Azure Key Vault のシークレット。

Containers

"コンテナー" には次のものが含まれます。

  • ポッド セキュリティを適用するための AKS 用の Azure Policy アドオン。
  • Pod Security Admission。
  • イメージとランタイムの脆弱性のスキャン。
  • 基になるノードへのコンテナー アクセスを制限するための App Armor や Seccomp (セキュア コンピューティング) の使用。

論理的に分離されたクラスター

ベスト プラクティスのガイダンス: 論理的な分離を使用してチームとプロジェクトを分離します。 チームまたはアプリケーションを分離するためにデプロイする物理 AKS クラスターの数を最小限にします。

論理的な分離によって、1 つの AKS クラスターを複数のワークロード、チーム、または環境に使用できます。 Kubernetes の名前空間では、ワークロードとリソースの論理的な分離境界を形成します。

論理的に分離されたクラスターの例を示す図。

クラスターを論理的に分離すると、通常、物理的に分離されたクラスターよりもポッド密度が高くなり、クラスター内でアイドル状態の過剰なコンピューティング容量が少なくなります。 Kubernetes クラスターの自動スケーラーを組み合わせることで、ノード数をスケール アップまたはスケール ダウンして需要を満たすことできます。 このベスト プラクティスの方法を使用すれば、必要な数のノードのみを実行することでコストが最小限に抑えられます。

Kubernetes 環境は、悪意のあるマルチテナントの使用に対して完全に安全ではありません。 マルチテナント環境では、複数のテナントが共有インフラストラクチャ上で動作します。 すべてのテナントを信頼できない場合は、テナントが他のテナントのセキュリティやサービスに影響を与えることを防ぐために、追加の計画が必要です。

ノード用の Kubernetes RBAC など、その他のセキュリティ機能により、悪用を効率的にブロックします。 悪意のあるマルチテナント ワークロードを実行する場合の真のセキュリティを実現するために、ハイパーバイザーのみを信頼してください。 Kubernetes 用のセキュリティ ドメインはクラスター全体になり、個々のノードにはなりません。

この種の悪意のあるマルチテナント ワークロードでは、物理的に分離されたクラスターを使用する必要があります。

物理的に分離されたクラスター

ベスト プラクティスのガイダンス: 個々のチームまたはアプリケーションのデプロイごとの物理的な分離の使用を最小限に抑え、代わりに論理的な分離を使用します。

AKS クラスターを物理的に分離することが、クラスターを分離するための一般的な方法です。 この分離モデルでは、チームまたはワークロードに独自の AKS クラスターが割り当てられます。 物理的な分離は、ワークロードやチームを分離する最も簡単な方法のようですが、管理と財務のオーバーヘッドが増えます。 物理的に分離されたクラスターでは、複数のクラスターを維持し、個別にアクセスを提供してアクセス許可を割り当てる必要があります。 また、個々のノードごとに課金されます。

物理的に分離されたクラスターの例を示す図。

物理的に分離されたクラスターは通常、ポッドの密度が低くなります。 各チームまたはワークロードには独自の AKS クラスターがあるため、クラスターは多くの場合、コンピューティング リソースで過剰にプロビジョニングされます。 多くの場合、ノード上には数個のポッドがスケジュールされます。 ノード上の未使用の容量は、他のチームによって開発中のアプリケーションやサービスで使用することはできません。 これらの過剰なリソースは、物理的に分離されたクラスターで余計なコストの原因になります。