Azure Kubernetes Service (AKS)
AKS クラスターは、さまざまなシナリオや方法で複数のテナント間で共有できます。 場合によっては、さまざまなアプリケーションが同じクラスターで実行される場合があります。 また、同じアプリケーションの複数のインスタンスを、テナントごとに 1 つずつ、同じ共有クラスターで実行できます。 マルチテナント
この記事では、マルチテナント システムを構築するときに使用できる AKS の機能の一部について説明します。 Kubernetes マルチテナントの一般的なガイダンスとベスト プラクティスについては、Kubernetes ドキュメント マルチテナント を参照してください。
マルチテナント型
複数のテナント間で AKS クラスターを共有する方法を決定する最初の手順は、使用できるパターンとツールを評価することです。 一般に、Kubernetes クラスターのマルチテナントは 2 つの主要なカテゴリに分類されますが、多くのバリエーションが引き続き可能です。 Kubernetes ドキュメント では、マルチテナントの 2 つの一般的なユース ケース (複数のチームと複数の顧客) について説明しています。
複数のチーム
マルチテナントの一般的な形式は、組織内の複数のチーム間でクラスターを共有することです。 各チームは、1 つ以上のソリューションをデプロイ、監視、運用できます。 これらのワークロードは、多くの場合、互いに通信し、同じクラスターまたは他のホスティング プラットフォーム上にある他の内部または外部アプリケーションと通信する必要があります。
さらに、これらのワークロードは、リレーショナル データベース、NoSQL リポジトリ、メッセージング システムなどのサービスと通信する必要があります。このシステムは、同じクラスターでホストされているか、Azure でサービスとしてのプラットフォーム (PaaS) サービスとして実行されています。
このシナリオでは、多くの場合、チームのメンバーは、kubectl などのツールを使用して Kubernetes リソースに直接アクセスできます。 または、メンバーは、GitOps コントローラー (Flux や Argo CDなど) または他の種類のリリース自動化ツールを介して間接的にアクセスできます。
このシナリオの詳細については、Kubernetes ドキュメント 複数のチーム を参照してください。
複数のお客様
マルチテナントのもう 1 つの一般的な形式には、サービスとしてのソフトウェア (SaaS) ベンダーが頻繁に含まれます。 または、サービス プロバイダーは、ワークロードの複数のインスタンスを実行します。これは個別のテナントと見なされ、顧客に対して行われます。 このシナリオでは、顧客は AKS クラスターに直接アクセスすることはできませんが、アプリケーションにのみアクセスできます。 さらに、アプリケーションが Kubernetes で実行されていることも知りません。 コストの最適化は、多くの場合、重要な問題です。 サービス プロバイダーは、
このシナリオの詳細については、Kubernetes ドキュメント 複数のお客様 を参照してください。
分離モデル
Kubernetes のドキュメントによると、マルチテナント Kubernetes クラスターは、テナントと呼ばれる複数のユーザーとワークロードによって共有されます。 この定義には、組織内のさまざまなチームまたは部門が共有する Kubernetes クラスターが含まれます。 また、SaaS アプリケーション共有の顧客ごとのインスタンスを持つクラスターも含まれます。
クラスター マルチテナントは、多くのシングルテナント専用クラスターを管理する代わりに使用できます。 マルチテナント Kubernetes クラスターのオペレーターは、テナントを互いに分離する必要があります。 この分離により、侵害されたテナントや悪意のあるテナントがクラスターや他のテナントに与える損害が最小限に抑えられます。
複数のユーザーまたはチームが同じクラスターを固定数のノードと共有している場合、1 つのチームがリソースの公平な共有を超える量を使用する可能性があります。 管理者は、リソース クォータ を使用して、この問題に対処できます。
分離によって提供されるセキュリティ レベルに基づいて、ソフト マルチテナントとハード マルチテナントを区別できます。
- ソフト マルチテナントは、テナントが互いに信頼する異なるチームまたは部門である単一の企業内で適しています。 このシナリオでは、分離は、ワークロードの整合性を保証し、さまざまな内部ユーザー グループ間でクラスター リソースを調整し、考えられるセキュリティ攻撃から保護することを目的としています。
- ハード マルチテナントは、異種テナントが互いを信頼しないシナリオを説明します。多くの場合、セキュリティとリソース共有の観点から説明します。
マルチテナント AKS クラスターを構築する予定の場合は、Kubernetes
- クラスター
- Namespace
- ノード プールまたはノード
- 莢
- コンテナ
さらに、複数のテナント間で異なるリソースを共有することのセキュリティへの影響を考慮する必要があります。 たとえば、同じノード上の異なるテナントのポッドをスケジュールすることで、クラスターに必要なマシンの数を減らすことができます。 一方、特定のワークロードが併置されないようにすることが必要な場合があります。 たとえば、組織外の信頼されていないコードを、機密情報を処理するコンテナーと同じノードで実行することを許可しない場合があります。
Kubernetes はテナント間の完全に安全な分離を保証することはできませんが、特定のユース ケースに十分な機能を提供します。 ベスト プラクティスとして、各テナントとその Kubernetes リソースを名前空間に分離する必要があります。 その後、Kubernetes ロールベースのアクセス制御 (RBAC)
AKS を使用してマルチテナント ソリューションを設計および構築するには、いくつかの方法があります。 これらの各方法には、インフラストラクチャのデプロイ、ネットワーク トポロジ、およびセキュリティの観点から、独自のトレードオフのセットが用意されています。 これらのメソッドは、分離レベル、実装作業、運用の複雑さ、コストに影響します。 要件に基づいて、コントロール プレーンとデータ プレーンでテナントの分離を適用できます。
コントロール プレーンの分離
コントロール プレーン レベルで分離している場合は、ポッドやサービスなど、異なるテナントが互いのリソースにアクセスしたり、他のユーザーのリソースに影響を与えたりできないことを保証できます。 また、他のテナントのアプリケーションのパフォーマンスに影響を与えることはできません。 詳細については、Kubernetes ドキュメント コントロール プレーンの分離 を参照してください。 コントロール プレーン レベルで分離を実装する最善の方法は、各テナントのワークロードとその Kubernetes リソースを個別の名前空間に分離することです。
Kubernetes のドキュメントによると、名前空間 は、1 つのクラスター内のリソース グループの分離をサポートするために使用する抽象化です。 名前空間を使用して、Kubernetes クラスターを共有するテナント ワークロードを分離できます。
- 名前空間を使用すると、互いの作業に影響を与えるリスクなしに、個別のテナント ワークロードを独自の仮想ワークスペースに存在できます。 名前が重複するリスクなしに、異なる名前空間で同じリソース名を使用できるため、組織内の個別のチームは名前空間を使用してプロジェクトを相互に分離できます。
- RBAC ロールとロール バインド は、チームが名前空間内のリソースとサービスにのみアクセスするようにテナント ユーザーとプロセスを制限するために使用できる名前空間スコープのリソースです。 複数のチームがロールを定義して、アクセス許可または機能のリストを 1 つの名前でグループ化できます。 次に、これらのロールをユーザー アカウントとサービス アカウントに割り当てて、承認された ID のみが特定の名前空間内のリソースにアクセスできるようにします。
- CPU とメモリに リソース クォータは名前空間オブジェクトです。 Teams では、それらを使用して、同じクラスターを共有するワークロードがシステム リソースの消費から厳密に分離されるようにすることができます。 この方法を使用すると、個別の名前空間で実行されるすべてのテナント アプリケーションに実行する必要があるリソースが確保され、同じクラスターを共有する他のテナント アプリケーションに影響を与える可能性がある、ノイズの多い近隣の問題を回避できます。
- ネットワーク ポリシー は、特定のテナント アプリケーションに対して許可されるネットワーク トラフィックを適用するためにチームが採用できる名前空間オブジェクトです。 ネットワーク ポリシーを使用すると、ネットワークの観点から同じクラスターを共有する個別のワークロードを分離できます。
- 個別の名前空間で実行されるチーム アプリケーションでは、異なる サービス アカウント を使用して、同じクラスター、外部アプリケーション、またはマネージド サービス内のリソースにアクセスできます。
- コントロール プレーン レベルでパフォーマンスを向上させるには、名前空間を使用します。 共有クラスター内のワークロードが複数の名前空間に編成されている場合、Kubernetes API では、操作の実行時に検索する項目が少なくなります。 この組織では、API サーバーに対する呼び出しの待機時間を短縮し、コントロール プレーンのスループットを向上させることができます。
名前空間レベルでの分離の詳細については、Kubernetes ドキュメントの次のリソースを参照してください。
データ プレーンの分離
データ プレーンの分離により、個別のテナントのポッドとワークロードが互いに十分に分離されることが保証されます。 詳細については、Kubernetes ドキュメント データ プレーンの分離 を参照してください。
ネットワークの分離
Kubernetes でマイクロサービス ベースの最新のアプリケーションを実行する場合、多くの場合、相互に通信できるコンポーネントを制御する必要があります。 既定では、AKS クラスター内のすべてのポッドは、同じクラスターを共有する他のアプリケーションを含め、制限なくトラフィックを送受信できます。 セキュリティを強化するために、トラフィックのフローを制御するネットワーク ルールを定義できます。 ネットワーク ポリシーは、ポッド間の通信用のアクセス ポリシーを定義する Kubernetes 仕様です。 ネットワーク ポリシー を使用して、同じクラスターを共有するテナント アプリケーション間の通信を分離できます。
AKS には、ネットワーク ポリシーを実装する 2 つの方法があります。
- Azure には、Azure ネットワーク ポリシーと呼ばれるネットワーク ポリシーの実装があります。
- Calico ネットワーク ポリシー は、Tigeraによって設立されたオープンソースネットワークおよびネットワーク セキュリティ ソリューションです。
どちらの実装でも、Linux iptables を使用して、指定されたポリシーを適用します。 ネットワーク ポリシーは、許可された IP ペアと許可されていない IP ペアのセットに変換されます。 これらのペアは、iptables フィルター 規則としてプログラミングされます。 Azure ネットワーク ポリシーは、Azure CNI ネットワーク プラグインで構成された AKS クラスターでのみ使用できます。 ただし、Calico ネットワーク ポリシーでは、Azure CNI
詳細については、Kubernetes ドキュメント ネットワーク分離 を参照してください。
ストレージの分離
Azure には、Azure SQL Database
AKS で実行されるワークロードでは、永続ボリュームを使用してデータを格納することもできます。 Azure では、Azure Storage でサポート Kubernetes リソースとして 永続ボリュームを作成できます。 データ ボリュームを手動で作成してポッドに直接割り当てたり、永続ボリューム要求を使用して AKS
AKS
たとえば、テナントごとにカスタム ストレージ クラスを構成できます。 その後、それを使用して、名前空間に作成された永続ボリュームにタグを適用して、コストを請求することができます。 詳細については、「AKSで Azure タグを使用する
詳細については、Kubernetes ドキュメント ストレージ分離 を参照してください。
ノードの分離
テナント ワークロードを個別のエージェント ノードで実行するように構成して、ノイズの多い近隣の問題 を回避し、情報漏えいのリスクを軽減できます。 AKS では、分離、セキュリティ、規制コンプライアンス、パフォーマンスに関する厳密な要件を持つテナント用に、個別のクラスターまたは専用ノード プールのみを作成できます。
一般に、AKS では、次のようなさまざまなレベルでワークロードの分離が提供されます。
- カーネル レベルでは、共有エージェント ノード上の軽量仮想マシン (VM) でテナント ワークロードを実行し、Kata Containersに基づく ポッド サンドボックス を使用します。
- 物理レベルでは、専用クラスターまたはノード プールでテナント アプリケーションをホストします。
- ハードウェア レベルでは、エージェント ノード VM が専用の物理マシンを実行することを保証、
Azure 専用ホストでテナント ワークロードを実行します。 ハードウェアの分離により、他の VM が専用ホスト上に配置されることがなくなります。これにより、テナント ワークロードに対して分離層が追加されます。
これらの手法を組み合わせることができます。 たとえば、Azure Dedicated Host グループ でテナントごとのクラスターとノード プールを実行して、ハードウェア レベルでワークロードの分離と物理的な分離を実現できます。 また、Federal Information Process Standard (FIPS)、
ノード分離を使用して、一連のノードまたはノード プールのコストを 1 つのテナントに簡単に関連付けてチャージバックします。 これは、ソリューションで採用されているテナント モデルに厳密に関連しています。
詳細については、Kubernetes ドキュメント ノード分離 を参照してください。
テナント モデル
AKS には、より多くの種類のノード分離モデルとテナント モデルが用意されています。
シングルテナントデプロイの自動化
自動シングルテナント デプロイ モデルでは、次の例に示すように、テナントごとに専用のリソース セットをデプロイします。
各テナント ワークロードは専用の AKS クラスターで実行され、個別の Azure リソースのセットにアクセスします。 通常、このモデルを使用して構築するマルチテナント ソリューションでは、コードとしてのインフラストラクチャ (IaC)
の利点:
- このアプローチの主な利点は、各テナント AKS クラスターの API Server が別々であるということです。 この方法では、セキュリティ、ネットワーク、およびリソース消費レベルからテナント間で完全に分離が保証されます。 コンテナーの制御を管理する攻撃者は、1 つのテナントに属するコンテナーとマウントされたボリュームにのみアクセスできます。 規制コンプライアンスのオーバーヘッドが高い一部のお客様にとって、完全分離テナント モデルは非常に重要です。
- テナントが互いのシステム パフォーマンスに影響を与える可能性は低いので、ノイズの多い近隣 問題回避できます。 この考慮事項には、API Server に対するトラフィックが含まれます。 API サーバーは、任意の Kubernetes クラスター内の共有の重要なコンポーネントです。 カスタム コントローラーは、API サーバーに対して規制されていない大量のトラフィックを生成し、クラスターが不安定になる可能性があります。 この不安定性により、要求エラー、タイムアウト、および API 再試行 storm が発生します。 アップタイム SLA 機能を使用して、トラフィックの需要に合わせて AKS クラスターのコントロール プレーンをスケールアウトします。 それでも、専用クラスターのプロビジョニングは、ワークロードの分離という点で強力な要件を持つお客様にとって、より優れたソリューションになる可能性があります。
- テナント間で更新プログラムと変更を段階的にロールアウトできるため、システム全体の停止の可能性が低くなります。 すべてのリソースが 1 つのテナントによって使用されるため、Azure のコストはテナントに簡単にチャージバックできます。
リスク:
- すべてのテナントが専用のリソース セットを使用するため、コスト効率は低くなります。
- テナントごとに 1 つずつ、複数の AKS クラスターでメンテナンス アクティビティを繰り返す必要があるため、継続的なメンテナンスには時間がかかる可能性があります。 運用プロセスを自動化し、環境を通じて段階的に変更を適用することを検討してください。 資産全体のレポートや分析など、他のクロスデプロイ操作も役立つ場合があります。 複数のデプロイ間でデータのクエリと操作を行う方法を計画していることを確認します。
完全マルチテナント デプロイ
完全マルチテナント デプロイでは、1 つのアプリケーションがすべてのテナントの要求を処理し、AKS クラスターを含むすべての Azure リソースが共有されます。 このコンテキストでは、デプロイ、監視、保守を行うインフラストラクチャは 1 つだけです。 次の図に示すように、すべてのテナントでリソースが使用されます。
特典:
- このモデルは、共有コンポーネントを使用してソリューションを運用するコストが低いため、魅力的です。 このテナント モデルを使用する場合は、より大きな AKS クラスターをデプロイし、すべての共有データ リポジトリに上位の SKU を採用することが必要になる場合があります。 これらの変更は、データ リポジトリなど、すべてのテナントのリソースが生成するトラフィックを維持するのに役立ちます。
リスク:
- このコンテキストでは、1 つのアプリケーションがすべてのテナントの要求を処理します。 テナントがアプリケーションを呼び出しであふれさせないように、セキュリティ対策を設計して実装する必要があります。 これらの呼び出しにより、システム全体が遅くなり、すべてのテナントに影響を与える可能性があります。
- トラフィック プロファイルが大きく変動する場合は、ポッドとエージェント ノードの数を変更するように AKS クラスター オートスケーラーを構成する必要があります。 構成は、CPU やメモリなどのシステム リソースの使用状況に基づいて行います。 または、カスタム メトリックに基づいてポッドとクラスター ノードの数をスケールアウトしてスケールインすることもできます。 たとえば、保留中の要求の数や、Kubernetes ベースのイベント ドリブン オートスケーラー (KEDA)
使用する外部メッセージング システムのメトリックを使用できます。 - テナントごとにデータを分離し、異なるテナント間のデータ漏洩を回避するためのセーフガードを実装してください。
- 実際 使用状況に基づいて、Azure のコスト を追跡し、個々のテナントに関連付ける必要があります。 kubecostなどの Microsoft 以外のソリューションは、さまざまなチームやテナントのコストを計算して分割するのに役立ちます。
- Azure リソースのセットを 1 つだけ更新し、1 つのアプリケーションを維持するだけで済むため、1 つのデプロイでメンテナンスが簡単になります。 ただし、インフラストラクチャまたはアプリケーション コンポーネントに対する変更が顧客ベース全体に影響を与える可能性があるため、リスクが高い場合もあります。
- スケールの制限も考慮する必要があります。 リソースの共有セットがある場合、Azure リソーススケールの制限に達する可能性が高くなります。 リソース クォータの制限に達しないように、テナントを複数の Azure サブスクリプションに分散できます。
水平方向にパーティション分割されたデプロイ
または、マルチテナント Kubernetes アプリケーションを水平方向にパーティション分割することを検討することもできます。 このアプローチでは、すべてのテナント間で一部のソリューション コンポーネントを共有し、個々のテナント専用のリソースをデプロイします。 たとえば、次の図に示すように、1 つのマルチテナント Kubernetes アプリケーションを構築し、テナントごとに 1 つずつ、個々のデータベースを作成できます。
の利点:
- 水平方向にパーティション分割されたデプロイは、ノイズの多い近隣の問題を軽減するのに役立ちます。 Kubernetes アプリケーションのトラフィック負荷の大部分が、テナントごとに個別にデプロイできる特定のコンポーネントが原因であることを特定する場合は、このアプローチを検討してください。 たとえば、クエリの負荷が高いため、データベースがシステムの負荷の大部分を吸収する可能性があります。 1 つのテナントが多数の要求をソリューションに送信する場合、データベースのパフォーマンスは悪影響を受ける可能性がありますが、他のテナントのデータベースや共有コンポーネント (アプリケーション層など) は影響を受けません。
リスク:
- 水平方向にパーティション分割されたデプロイでは、コンポーネント 、特に 1 つのテナントが使用するコンポーネントの自動デプロイと管理を考慮する必要があります。
- このモデルでは、内部ポリシーまたはコンプライアンス上の理由から、リソースを他のテナントと共有できないお客様に必要なレベルの分離が提供されない場合があります。
垂直方向にパーティション分割されたデプロイ
複数の AKS クラスターまたはノード プール間でテナントを垂直方向にパーティション分割するハイブリッド モデルを使用することで、シングルテナント モデルと完全マルチテナント モデルの利点を活用できます。 このアプローチでは、前の 2 つのテナント モデルに比べて次のような利点があります。
- シングルテナントデプロイとマルチテナント デプロイの組み合わせを使用できます。 たとえば、ほとんどの顧客がマルチテナント インフラストラクチャで AKS クラスターとデータベースを共有できます。 また、より高いパフォーマンスと分離を必要とする顧客向けに、シングルテナント インフラストラクチャをデプロイすることもできます。
- 異なる構成を使用して、複数のリージョン AKS クラスターにテナントをデプロイできます。 この手法は、テナントがさまざまな地域に分散している場合に最も効果的です。
このテナント モデルのさまざまなバリエーションを実装できます。 たとえば、さまざまなレベルの機能を持つマルチテナント ソリューションを異なるコストで提供することを選択できます。 価格モデルでは、リソース共有、パフォーマンス、ネットワーク、およびデータの分離の観点から、それぞれがパフォーマンスと分離の増分レベルを提供する複数の SKU を提供できます。 次のレベルについて考えてみましょう。
- Basic レベル: テナント要求は、他のテナントと共有される 1 つのマルチテナント Kubernetes アプリケーションによって処理されます。 データは、すべての Basic 層テナントが共有する 1 つ以上のデータベースに格納されます。
- Standard レベル: テナント要求は、別の名前空間で実行される専用の Kubernetes アプリケーションによって処理されます。このアプリケーションは、セキュリティ、ネットワーク、およびリソース消費の観点から分離境界を提供します。 テナントごとに 1 つずつ、すべてのテナントのアプリケーションは、同じ AKS クラスターとノード プールを他の Standard レベルのお客様と共有します。
- Premium レベル: テナント アプリケーションは、専用ノード プールまたは AKS クラスターで実行され、SLA の向上、パフォーマンスの向上、分離度の向上を保証します。 このレベルでは、テナント アプリケーションをホストするエージェント ノードの数と SKU に基づいて柔軟なコスト モデルを提供できます。 ポッド サンドボックス は、専用クラスターまたはノード プールの代替ソリューションとして使用して、個別のテナント ワークロードを分離できます。
次の図は、テナント A と B が共有 AKS クラスターで実行されるのに対し、テナント C は別の AKS クラスターで実行されるシナリオを示しています。
次の図は、テナント A と B が同じノード プールで実行されるのに対し、テナント C は専用ノード プールで実行されるシナリオを示しています。
このモデルでは、レベルごとに異なる SLA を提供することもできます。 たとえば、Basic レベルでは 99.9% アップタイムを提供でき、Standard レベルでは 99.95% アップタイムを提供でき、Premium レベルでは 99.99% アップタイムを提供できます。 高可用性ターゲットを有効にするサービスと機能を使用して、より高い SLA を実装できます。
の利点:
- まだインフラストラクチャを共有しているため、マルチテナントデプロイを共有することで、コスト上の利点の一部を引き続き得ることができます。 複数の Basic レベルおよび Standard レベルのテナント アプリケーション間で共有されるクラスターとノード プールをデプロイできます。このアプリケーションでは、エージェント ノードに対して低コストの VM サイズを使用します。 この方法により、密度とコストの削減が保証されます。 Premium レベルのお客様の場合は、VM サイズが大きく、ポッドのレプリカとノードの最大数が高い AKS クラスターとノード プールを、より高い価格でデプロイできます。
- 専用のシステム モード ノード プールで、
CoreDNS 、Konnectivity 、Azure Application Gateway イングレス コントローラーなどのシステム サービスを実行できます。 テイント、許容、ノード ラベル、ノード セレクター、ノード アフィニティ を使用して、1 つ以上のユーザー モード ノード プールでテナント アプリケーションを実行できます。 テイント 、許容 、ノード ラベル、ノード セレクター 、ノード アフィニティ を使用して、共有リソースを実行できます。 たとえば、特定の VM サイズ、自動スケーラー設定、可用性ゾーンがサポートされている専用ノード プールにイングレス コントローラーまたはメッセージング システムを設定できます。
リスク:
- マルチテナントデプロイとシングルテナントデプロイの両方をサポートするように Kubernetes アプリケーションを設計する必要があります。
- インフラストラクチャ間の移行を許可する場合は、マルチテナントデプロイから独自のシングルテナントデプロイに顧客を移行する方法を検討する必要があります。
- より多くの AKS クラスターを監視および管理するには、一貫した戦略と 1 つのウィンドウ (1 つの視点) が必要です。
自動スケール
テナント アプリケーションが生成するトラフィック需要に対応するために、クラスター オートスケーラー を有効にして、AKS のエージェント ノードをスケーリングできます。 自動スケールは、次の状況でシステムの応答性を維持するのに役立ちます。
- トラフィックの負荷は、1 年の特定の勤務時間または期間に増加します。
- テナントまたは共有の負荷が高い場合は、クラスターにデプロイされます。
- 可用性ゾーンの停止により、エージェント ノードが使用できなくなります。
ノード プールの自動スケールを有効にする場合は、予想されるワークロード サイズに基づいてノードの最小数と最大数を指定します。 ノードの最大数を構成することで、クラスター内のすべてのテナント ポッドが実行されている名前空間に関係なく、十分な領域を確保できます。
トラフィックが増加すると、クラスターの自動スケールによって新しいエージェント ノードが追加され、CPU やメモリなどのリソース不足のためにポッドが保留中の状態になるのを防ぐことができます。
負荷が減少すると、クラスターの自動スケールによって、指定された境界に基づいてノード プール内のエージェント ノードの数が減り、運用コストの削減に役立ちます。
ポッドの自動スケーリングを使用すると、リソースの需要に基づいてポッドを自動的にスケーリングできます。 HorizontalPodAutoscaler
Vertical Pod Autoscaler (VPA) により、ポッドの効率的なリソース管理が可能になります。 ポッドに割り当てられた CPU とメモリを調整することで、VPA を使用すると、テナント アプリケーションの実行に必要なノードの数を減らすことができます。 ノードを少なくすると、総保有コストが削減され、ノイズの多い近隣の問題回避できます。
容量予約グループ をノード プールに割り当てて、さまざまなテナントのリソース割り当てと分離を向上させます。
メンテナンス
クラスターまたはノード プールのアップグレード中にテナント アプリケーションに影響する可能性があるダウンタイムのリスクを軽減するには、AKS 計画メンテナンス をピーク時間外にスケジュールします。 ワークロードへの影響を最小限に抑えるために、テナント アプリケーションとノード プールを実行する AKS クラスターのコントロール プレーンを更新するように、毎週のメンテナンス期間をスケジュールします。 特定の日に日または時間の範囲を指定することで、クラスターで 1 つ以上の週単位のメンテナンス期間をスケジュールできます。 すべてのメンテナンス操作は、スケジュールされた期間中に行われます。
安全
次のセクションでは、AKS を使用したマルチテナント ソリューションのセキュリティのベスト プラクティスについて説明します。
クラスター アクセス
組織内の複数のチーム間で AKS クラスターを共有する場合は、異なるテナントを互いに分離するために、最小特権 の
AKS での認証と承認の詳細については、次の記事を参照してください。
- AKS のアクセスと ID オプションの
- AKS で管理される Microsoft Entra 統合 の
- AKS で Microsoft Entra ID を使用して Kubernetes ロールベースのアクセス制御を
する
ワークロード ID
1 つの AKS クラスターで複数のテナント アプリケーションをホストし、各アプリケーションが別々の名前空間にある場合、各ワークロードでは、異なる Kubernetes サービス アカウント と資格情報を使用してダウンストリーム Azure サービスにアクセスする必要があります。 サービス アカウントは、Kubernetes の主要なユーザーの種類の 1 つです。 Kubernetes API は、サービス アカウントを保持および管理します。 サービス アカウントの資格情報は Kubernetes シークレットとして格納されるため、承認されたポッドはそれらを使用して API Server と通信できます。 ほとんどの API 要求は、サービス アカウントまたは通常のユーザー アカウントの認証トークンを提供します。
AKS クラスターにデプロイするテナント ワークロードでは、Microsoft Entra アプリケーション資格情報を使用して、Azure Key Vault や Microsoft Graph などの Microsoft Entra ID で保護されたリソースにアクセスできます。 Kubernetes 用 Microsoft Entra Workload ID は、Kubernetes ネイティブ機能と統合して、外部 ID プロバイダーとフェデレーションします。
ポッドのサンドボックス化
AKS には、コンテナー アプリケーションとコンテナー ホストの共有カーネルとコンピューティング リソース (CPU、メモリ、ネットワークなど) の間の分離境界を提供する、ポッド サンドボックス と呼ばれるメカニズムが含まれています。 ポッド サンドボックスは、他のセキュリティ対策またはデータ保護制御を補完して、テナント ワークロードが機密情報をセキュリティで保護し、Payment Card Industry Data Security Standard (PCI DSS)、国際標準化機構 (ISO) 27001、医療保険の移植性とアカウンタビリティ法 (HIPAA) などの規制、業界、またはガバナンスのコンプライアンス要件を満たすのに役立ちます。
アプリケーションを個別のクラスターまたはノード プールにデプロイすることで、さまざまなチームまたは顧客のテナント ワークロードを強く分離できます。 複数のクラスターとノード プールを使用すると、多くの組織や SaaS ソリューションの分離要件に適している場合がありますが、共有 VM ノード プールを持つ単一のクラスターの方が効率的なシナリオがあります。 たとえば、信頼されていないポッドと信頼されたポッドを同じノードで実行する場合や、同じノードに DaemonSet と特権コンテナーを併置して、ローカル通信と機能のグループ化を高速化する場合に、1 つのクラスターを使用できます。 ポッドサンドボックス は、これらのワークロードを別々のクラスターまたはノード プールで実行しなくても、同じクラスター ノード上のテナント アプリケーションを厳密に分離するのに役立ちます。 その他の方法では、コードを再コンパイルしたり、他の互換性の問題を引き起こしたりする必要がありますが、AKS のポッド サンドボックスでは、強化されたセキュリティ VM 境界内で変更されていない任意のコンテナーを実行できます。
AKS でのポッドのサンドボックス化は、AKS スタック用の
詳細については、以下を参照してください。
- AKS を使用したポッドサンドボックスの
- ポッドサンドボックス のための AKS での Kata VM 分離コンテナーの
のサポート
Azure 専用ホスト
Azure Dedicated Host は、1 つの Azure サブスクリプション専用の物理サーバーを提供し、物理サーバー レベルでハードウェアを分離するサービスです。 これらの専用ホストは、リージョン、可用性ゾーン、および障害ドメイン内にプロビジョニングでき、VM をプロビジョニングされたホストに直接配置できます。
AKS で Azure Dedicated Host を使用するには、次のような利点があります。
ハードウェアの分離により、他の VM が専用ホスト上に配置されることがなくなります。これにより、テナント ワークロードに対して分離層が追加されます。 専用ホストは同じデータセンターにデプロイされ、他の非分離ホストと同じネットワークと基になるストレージ インフラストラクチャを共有します。
Azure Dedicated Host では、Azure プラットフォームが開始するメンテナンス イベントを制御できます。 メンテナンス期間を選択すると、サービスへの影響を軽減し、テナント ワークロードの可用性とプライバシーを確保できます。
Azure Dedicated Host は、SaaS プロバイダーがテナント アプリケーションが機密情報をセキュリティで保護するための規制、業界、ガバナンスのコンプライアンス要件を確実に満たすのに役立ちます。 詳細については、「AKS クラスターへの Azure 専用ホストの追加」を参照してください。
Karpenter
Karpenter は、Kubernetes 用に構築されたオープン ソースのノード ライフサイクル管理プロジェクトです。 Kubernetes クラスターに Karpenter を追加すると、そのクラスターでワークロードを実行する効率とコストを向上させることができます。 Karpenter は、Kubernetes スケジューラがスケジュール不可能としてマークするポッドを監視します。 また、ポッドの要件を満たすことができるノードを動的にプロビジョニングおよび管理します。
Karpenter では、マネージド クラスターでのノード プロビジョニングとワークロードの配置をきめ細かく制御できます。 この制御により、リソースの割り当てを最適化し、各テナントのアプリケーション間の分離を確保し、運用コストを削減することで、マルチテナント性が向上します。 AKS でマルチテナント ソリューションを構築する場合、Karpenter には、さまざまなテナントをサポートするためのさまざまなアプリケーション要件を管理するのに役立つ便利な機能が用意されています。 たとえば、GPU 最適化ノード プールで実行するテナントのアプリケーションや、メモリ最適化ノード プールで実行するアプリケーションが必要な場合があります。 アプリケーションでストレージの待機時間を短くする必要がある場合は、Karpenter を使用して、ストレージ層とアプリケーション層を併置できるように、ポッドに特定の可用性ゾーンで実行されるノードが必要であることを示すことができます。
AKS では、Karpenter を使用して AKS クラスターでノードの自動プロビジョニングを有効にします。 ほとんどのユーザーは、ノードの自動プロビジョニング モードを使用して、Karpenter をマネージド アドオンとして有効にする必要があります。 詳細については、「ノードの自動プロビジョニング
機密 VM
機密 VM を使用して、1 つ以上のノード プールを AKS クラスターに追加して、テナントの厳密な分離、プライバシー、およびセキュリティの要件に対処できます。 機密 VM 、ハードウェア ベースの 信頼された実行環境を使用。 AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) 機密 VM は、ハイパーバイザーやその他のホスト管理コードによる VM のメモリと状態へのアクセスを拒否します。これによって、オペレーター アクセスに対する防御層と詳細な保護が追加されます。 詳細については、「AKS クラスターで機密 VM を使用する」を参照してください。
Federal Information Process Standards (FIPS)
FIPS 140-3 は、情報技術製品およびシステムにおける暗号モジュールの最小セキュリティ要件を定義する米国政府の標準です。 AKS ノード プールの FIPS コンプライアンス
Azure ディスクを使用して独自のキーを持ち込む (BYOK)
Azure Storage は、AKS クラスターの OS ディスクとデータ ディスクを含め、保存時のストレージ アカウント内のすべてのデータを暗号化します。 既定では、データは Microsoft マネージド キーで暗号化されます。 暗号化キーをより詳細に制御するために、AKS クラスターの OS とデータ ディスクの残りの部分での暗号化に使用するカスタマー マネージド キーを提供できます。 詳細については、以下を参照してください。
- AKSで Azure ディスクを使用して BYOK を
します。 - Azure Disk Storageのサーバー側暗号化。
ホストベースの暗号化
AKS のホストベースの暗号化 により、テナントのワークロードの分離、プライバシー、セキュリティがさらに強化されます。 ホストベースの暗号化を有効にすると、AKS は基になるホスト マシン上の保存データを暗号化します。これにより、機密性の高いテナント情報が承認されていないアクセスから保護されます。 一時ディスクとエフェメラル OS ディスクは、エンド ツー エンド暗号化を有効にすると、プラットフォームマネージド キーを使用して保存時に暗号化されます。
AKS では、OS ディスクとデータ ディスクでは、プラットフォームマネージド キーを使用したサーバー側暗号化が既定で使用されます。 これらのディスクのキャッシュは、プラットフォームマネージド キーを使用して保存時に暗号化されます。 エンベロープ暗号化 (ラッピングとも呼ばれます) を使用して、データ保護キー を暗号化する独自の キー暗号化キー を指定できます。 OS ディスクとデータ ディスクのキャッシュも、指定した BYOK を介して暗号化されます。
ホスト ベースの暗号化により、マルチテナント環境のセキュリティレイヤーが追加されます。 OS およびデータ ディスク キャッシュ内の各テナントのデータは、選択したディスク暗号化の種類に応じて、カスタマー マネージド キーまたはプラットフォーム マネージド キーを使用して保存時に暗号化されます。 詳細については、以下を参照してください。
- AKS でのホストベースの暗号化の
- AKS で Azure ディスクを使用して BYOK を
する - Azure Disk Storage のサーバー側暗号化
ネットワーキング
次のセクションでは、AKS を使用したマルチテナント ソリューションのネットワークのベスト プラクティスについて説明します。
API サーバーへのネットワーク アクセスを制限する
Kubernetes では、API サーバーは、リソースの作成やノード数のスケーリングなど、クラスターでアクションを実行する要求を受け取ります。 組織内の複数のチーム間で AKS クラスターを共有する場合は、次のいずれかのソリューションを使用してコントロール プレーンへのアクセスを保護します。
プライベート AKS クラスター
プライベート AKS クラスターを使用すると、API サーバーとノード プール間のネットワーク トラフィックが仮想ネットワーク内に残っていることを確認できます。 プライベート AKS クラスターでは、コントロール プレーンまたは API サーバーには、AKS クラスターの同じ仮想ネットワークにある Azure プライベート エンドポイント経由でのみアクセスできる内部 IP アドレスがあります。 同様に、同じ仮想ネットワーク内のすべての仮想マシンは、プライベート エンドポイントを介してコントロール プレーンとプライベートに通信できます。 詳細については、「プライベート AKS クラスターの作成」を参照してください。
承認された IP アドレス範囲
クラスターのセキュリティを向上させ、攻撃を最小限に抑える 2 つ目のオプションは、承認された IP アドレス範囲
Private Link の統合
Azure Private Link サービス は、仮想ネットワークで定義され、Azure Load Balancer インスタンスのフロントエンド IP 構成に接続されている、Azure プライベート エンドポイント 経由でアプリケーションがサービスにプライベートに接続できるようにするインフラストラクチャ コンポーネントです。 Private Linkを使用すると、サービス プロバイダーは、データ流出リスクなしで、Azure 内またはオンプレミスから接続できるテナントにサービスを安全に提供できます。
Private Link サービス統合 を使用すると、パブリック インターネット上のパブリック エンドポイントを公開することなく、セキュリティで保護された方法でテナントに AKS でホストされるワークロードへのプライベート接続を提供できます。
Azure でホストされるマルチテナント ソリューションの Private Link を構成する方法の詳細については、「マルチテナントと Private Link」を参照してください。
リバース プロキシ
リバース プロキシ は、ロード バランサーと API ゲートウェイ であり、通常は、受信要求をセキュリティで保護、フィルター処理、ディスパッチするためにテナント アプリケーションの前で使用されます。 一般的なリバース プロキシでは、負荷分散、SSL 終了、レイヤー 7 ルーティングなどの機能がサポートされています。 リバース プロキシは通常、セキュリティ、パフォーマンス、信頼性を向上させるために実装されます。 Kubernetes の一般的なリバース プロキシには、次の実装が含まれます。
- NGINX イングレス コントローラー は、負荷分散、SSL 終端、レイヤー 7 ルーティングなどの高度な機能をサポートする一般的なリバース プロキシ サーバーです。
- Traefik Kubernetes イングレス プロバイダー は、イングレス仕様をサポートすることでクラスター サービスへのアクセスを管理するために使用できる Kubernetes イングレス コントローラーです。
- HAProxy Kubernetes イングレス コントローラー は、TLS 終端、URL パスベースのルーティングなどの標準機能をサポートする Kubernetes のもう 1 つのリバース プロキシです。
- Azure Application Gateway イングレス コントローラー (AGIC) は、Kubernetes アプリケーションです。これにより、AKS のお客様は、Azure ネイティブ Application Gateway L7 ロード バランサーを使用して、テナント アプリケーションをパブリック インターネットに公開したり、仮想ネットワークで実行される他のシステムに内部で公開したりできます。
AKS でホストされるリバース プロキシを使用して、複数のテナント アプリケーションへの受信要求をセキュリティで保護して処理する場合は、次の推奨事項を考慮してください。
- 高ネットワーク帯域幅と高速ネットワーク を有効にした VM サイズを使用するように構成された専用ノード プールでリバース プロキシ
ホストします。 - 自動スケール用にリバース プロキシをホストしているノード プールを構成します。
- テナント アプリケーションの待機時間とタイムアウトの増加を回避するには、自動スケール ポリシーを定義して、イングレス コントローラー ポッドの数を瞬時に拡張し、トラフィックの変動に合わせてコントラクトできるようにします。
- スケーラビリティと分離レベルを高めるために、イングレス コントローラーの複数のインスタンス間でテナント アプリケーションへの受信トラフィックをシャーディングすることを検討してください。
Azure Application Gateway イングレス コントローラー (AGIC)を使用する場合は、次のベスト プラクティスを実装することを検討してください。
- イングレス コントローラーが自動スケールに使用する
アプリケーション ゲートウェイ 構成します。 自動スケールを有効にすると、アプリケーション ゲートウェイと Web アプリケーション ファイアウォール (WAF) v2 SKU が、アプリケーション トラフィックの要件に基づいてスケールアウトまたはスケールインされます。 このモードにより、アプリケーションの弾力性が向上し、アプリケーション ゲートウェイのサイズまたはインスタンス数を推測する必要がなくなります。 このモードは、予想される最大トラフィック負荷に対してゲートウェイをピークプロビジョニング容量で実行する必要がないようにすることで、コストを節約するのにも役立ちます。 最小 (および必要に応じて最大) のインスタンス数を指定する必要があります。 - テナント アプリケーションの数がサイトの最大数
を超えた場合は、 AGIC の複数のインスタンス (それぞれ個別のアプリケーション ゲートウェイ に関連付けられている) をデプロイすることを検討してください。 各テナント アプリケーションが専用の名前空間で実行されていることを前提として、複数 名前空間サポート を使用して、AGICのより多くのインスタンスにテナント アプリケーションを分散します。
Azure Front Door との統合
Azure Front Door は、グローバル レイヤー 7 のロード バランサーであり、Microsoft の最新のクラウド コンテンツ配信ネットワーク (CDN) であり、世界中のユーザーと Web アプリケーション間の高速で信頼性の高い安全なアクセスを提供します。 Azure Front Door では、AKS でホストされるマルチテナント アプリケーションをパブリック インターネットに公開するときに使用できる、要求高速化、SSL 終了、応答キャッシュ、エッジでの WAF、URL ベースのルーティング、書き換え、リダイレクトなどの機能がサポートされています。
たとえば、AKS でホストされるマルチテナント アプリケーションを使用して、すべての顧客の要求に対応することができます。 このコンテキストでは、Azure Front Door を使用して、テナントごとに 1 つずつ、複数のカスタム ドメインを管理できます。 エッジ上の SSL 接続を終了し、すべてのトラフィックを、1 つのホスト名で構成された AKS ホスト型マルチテナント アプリケーションにルーティングできます。
バックエンド アプリケーションのドメイン名と一致するように、要求元ホスト ヘッダー を変更するように Azure Front Door を構成できます。 クライアントによって送信された元の
Azure Front Door Azure Web アプリケーション ファイアウォールは、Web アプリケーションの一元的な保護を提供します。 Azure Web Application Firewall は、悪意のある攻撃からインターネット上のパブリック エンドポイントを公開する AKS でホストされるテナント アプリケーションを保護するのに役立ちます。
Private Linkを使用して、内部ロード バランサーの配信元を介して AKS クラスターで実行される 1 つ以上のテナント アプリケーションにプライベートに接続するように Azure Front Door Premium
送信接続
AKS でホストされるアプリケーションが多数のデータベースまたは外部サービスに接続すると、クラスターがソース ネットワーク アドレス変換 (SNAT) ポート不足のリスクにさらされる可能性があります。 SNAT ポート、同じ一連のコンピューティング リソースで実行されるアプリケーションが開始する個別のフローを維持するために使用される一意の識別子を生成します。 共有 AKS クラスターで複数のテナント アプリケーションを実行すると、多数の送信呼び出しが行われる可能性があり、SNAT ポートが枯渇する可能性があります。 AKS クラスターは、次の 3 つの方法で送信接続を処理できます。
- Azure Load Balancer: 既定では、AKS は、送信接続用に設定および使用する Standard SKU Load Balancer をプロビジョニングします。 ただし、パブリック IP アドレスが許可されていない場合、またはエグレスに余分なホップが必要な場合は、既定のセットアップがすべてのシナリオの要件を満たしていない可能性があります。 既定では、パブリック ロード バランサーは、送信規則で使用 既定のパブリック IP アドレスを使用して作成されます。 送信規則を使用すると、パブリック標準ロード バランサーの SNAT を明示的に定義できます。 この構成では、ロード バランサーのパブリック IP アドレスを使用して、バックエンド インスタンスに送信インターネット接続を提供できます。 必要に応じて、SNAT ポートの枯渇を回避するために、パブリック ロード バランサーの送信規則を構成して、より多くのパブリック IP アドレスを使用できます。 詳細については、「アウトバウンド規則経由の送信にロード バランサーのフロントエンド IP アドレスを使用する」を参照してください。
-
Azure NAT Gateway: Azure NAT ゲートウェイを使用してテナント アプリケーションからのエグレス トラフィックをルーティングするように AKS クラスターを構成できます。 NAT ゲートウェイでは、パブリック IP アドレスあたり最大 64,512 の送信 UDP および TCP トラフィック フローが許可され、最大 16 個の IP アドレスが使用できます。 NAT ゲートウェイを使用して AKS クラスターからの送信接続を処理するときに SNAT ポートが枯渇するリスクを回避するには、より多くのパブリック IP アドレスまたは パブリック IP アドレス プレフィックス ゲートウェイに関連付けることができます。 詳細については、マルチテナント
Azure NAT ゲートウェイに関する考慮事項に関するページを参照してください。 -
ユーザー定義ルート (UDR): AKS クラスターのエグレス ルートをカスタマイズして、パブリック IP アドレスを禁止し、クラスターをネットワーク仮想アプライアンス (NVA) の背後に配置する必要があるカスタム ネットワーク シナリオをサポートできます。 ユーザー定義ルーティング
クラスターを構成する場合、AKS はエグレス パスを自動的に構成しません。 エグレスのセットアップを完了する必要があります。 たとえば、Azure Firewallを介してエグレス トラフィックをルーティングします。 AKS クラスターは、前に構成したサブネットを持つ既存の仮想ネットワークにデプロイする必要があります。 標準ロード バランサー アーキテクチャを使用していない場合は、明示的なエグレスを確立する必要があります。 そのため、このアーキテクチャでは、ファイアウォール、ゲートウェイ、プロキシなどのアプライアンスにエグレス トラフィックを明示的に送信する必要があります。 または、このアーキテクチャでは、Standard ロード バランサーまたはアプライアンスに割り当てられているパブリック IP によってネットワーク アドレス変換 (NAT) を実行できます。
モニタリング
Azure Monitor と コンテナー分析情報 を使用して、共有 AKS クラスターで実行されるテナント アプリケーションを監視し、個々の名前空間のコスト内訳を計算できます。 Azure Monitor を使用して、AKS の正常性とパフォーマンスを監視します。 これには、傾向を特定し、重大な問題を事前に通知するアラートを構成するために、収集されたデータの ログとメトリックの、テレメトリ分析、視覚化のコレクションが含まれます。 コンテナー分析情報 を有効にして、この監視を拡張できます。
また、
コスト
コスト ガバナンスは、コストを制御するためのポリシーを実装する継続的なプロセスです。 Kubernetes コンテキストには、組織がコストを制御および最適化するために使用できるいくつかの方法があります。 これらの方法には、ネイティブ Kubernetes ツールを使用してリソースの使用状況と消費を管理し、基になるインフラストラクチャを事前に監視および最適化することが含まれます。 テナントごとのコストを計算するときは、テナント アプリケーションが使用するリソースに関連するコストを考慮する必要があります。 テナントに料金を請求するために従う方法は、ソリューションが採用するテナント モデルによって異なります。 次の一覧では、テナント モデルについて詳しく説明します。
- 完全マルチテナント: 1 つのマルチテナント アプリケーションがすべてのテナント要求を処理する場合は、リソースの消費量と各テナントが生成する要求の数を追跡する必要があります。 その後、それに応じて顧客に請求します。
- 専用クラスター: クラスターが 1 つのテナント専用の場合、Azure リソースのコストを顧客に簡単に請求できます。 総保有コストは、VM の数とサイズ、ネットワーク トラフィックのネットワーク コスト、パブリック IP アドレス、ロード バランサー、ストレージ サービス (テナント ソリューションで使用されるマネージド ディスクや Azure ファイルなど) など、多くの要因によって異なります。 コスト課金操作を容易にするために、ノード リソース グループ内の AKS クラスターとそのリソースにタグを付けることができます。 詳細については、「クラスターにタグを追加する」を参照してください。
- 専用ノード プール: 1 つのテナント専用の新規または既存のノード プールに Azure タグを適用できます。 タグはノード プール内の各ノードに適用され、アップグレードによって保持されます。 タグは、スケールアウト操作中にノード プールに追加される新しいノードにも適用されます。 タグを追加すると、ポリシーの追跡やコストの請求などのタスクに役立ちます。 詳細については、「ノード プールへのタグの追加」を参照してください。
- その他のリソース: タグを使用して、専用リソースのコストを特定のテナントに関連付けることができます。 特に、Kubernetes マニフェストを使用してパブリック IP アドレス、ファイル、ディスクにタグを付けることができます。 この方法で設定されたタグは、後で別のメソッドを使用して更新した場合でも、Kubernetes の値を維持します。 パブリック IP アドレス、ファイル、またはディスクが Kubernetes を介して削除されると、Kubernetes が設定するすべてのタグが削除されます。 Kubernetes が追跡しないリソースのタグは影響を受けません。 詳細については、「Kubernetesを使用してタグを追加する」を参照してください。
KubeCostなどのオープン ソース ツールを使用して、AKS クラスターのコストを監視および管理できます。 コスト割り当てのスコープをデプロイ、サービス、ラベル、ポッド、および名前空間に設定できます。これによって、クラスターのユーザーのチャージ バックまたは表示方法を柔軟に行うことができます。 詳細については、「Kubecostを使用したコスト ガバナンスの
マルチテナント アプリケーションのコストの測定、割り当て、および最適化の詳細については、マルチテナント ソリューションでのコスト管理と割り当てのアーキテクチャ アプローチ
統治
複数のテナントが同じインフラストラクチャを共有すると、データのプライバシー、コンプライアンス、規制の要件の管理が複雑になる可能性があります。 強力なセキュリティ対策とデータ ガバナンス ポリシーを実装する必要があります。 共有 AKS クラスターは、データ侵害、未承認のアクセス、およびデータ保護規制への非準拠のリスクが高くなります。 各テナントには固有のデータ ガバナンス要件とコンプライアンス ポリシーがある可能性があるため、データのセキュリティとプライバシーの確保が困難になります。
Microsoft Defender for Containers は、Kubernetes 環境の脅威検出と保護機能を提供するクラウドネイティブのコンテナー セキュリティ ソリューションです。 Defender for Containers を使用すると、Kubernetes クラスターで複数のテナントをホストするときに、データ ガバナンスとコンプライアンス体制を強化できます。 Defender for Containers を使用して、機密データの保護、コンテナーの動作とネットワーク トラフィックの分析による脅威の検出と対応、規制要件の満たすのに役立ちます。 監査機能、ログ管理、およびレポート生成を提供して、規制機関と監査者へのコンプライアンスを示します。
貢献
この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。
プリンシパルの作成者:
- パオロ サルヴァトリ |プリンシパル カスタマー エンジニア
その他の共同作成者:
- ボーダン・チェルチク |シニア カスタマー エンジニア
- ジョン ダウンズ |プリンシパル ソフトウェア エンジニア
- チャド キットテル |プリンシパル ソフトウェア エンジニア
- アルセン ウラジミルスキー |プリンシパル カスタマー エンジニア
関連リソース
- マルチテナント ソリューション のアーキテクトおよび開発者向けの
リソース