NGINXで実現するKubernetesのマルチテナンシーと名前空間の分離

NGINX | 2022年6月14日

［編集部注—この記事は、包括的なeBook『Managing Kubernetes Traffic with F5 NGINX: A Practical Guide』からの抜粋です。今すぐ無料でダウンロードできます。］

組織の規模が拡大するにつれて、Kubernetesにおける開発と運用のワークフローは複雑になります。チームごとに専用のクラスターを用意するよりも、Kubernetesクラスターとリソースを複数のチームで共有する方が、一般的にコスト効率が高く、セキュリティも向上する可能性があります。ただし、チームがこれらのリソースを安全かつセキュアな方法で共有しなかった場合や、攻撃者に構成を悪用された場合、デプロイ環境に重大な損害が生じるおそれがあります。

ネットワークおよびリソースのレベルでマルチテナンシーを実践し、名前空間を分離することで、チーム間でKubernetesリソースを安全に共有しやすくなります。また、テナント単位でアプリケーションを分離することにより、侵害の規模を大幅に抑えることもできます。この方法は、侵害される可能性のある範囲を特定のチームが所有するアプリケーションの一部に限定し、その他の機能を提供するシステムを影響のない状態に保つことで、レジリエンスの向上に役立ちます。

NGINX Ingress Controllerは複数のマルチテナンシーモデルをサポートしていますが、主に2つのパターンがあります。インフラストラクチャサービスプロバイダーパターンでは通常、物理的に分離された複数のNGINX Ingress Controllerデプロイメントを使用します。一方、エンタープライズパターンでは通常、名前空間で分離された共有のNGINX Ingress Controllerデプロイメントを使用します。このセクションでは、エンタープライズパターンについて詳しく説明します。複数のNGINX Ingress Controllerを実行する方法については、ドキュメントをご覧ください。

NGINX Ingress Controllerによる委任

NGINX Ingress Controllerは、標準のKubernetes IngressリソースとカスタムNGINX Ingressリソースの両方をサポートしています。これにより、より高度なトラフィック管理と、複数のチームへの構成管理権限の委譲が可能になります。カスタムリソースは、VirtualServer、VirtualServerRoute、GlobalConfiguration、TransportServer、およびPolicyです。

NGINX Ingress Controllerでは、クラスター管理者がVirtualServerリソースを使用して、外部トラフィックをバックエンドアプリケーションにルーティングするIngressドメイン（ホスト名）ルールをプロビジョニングし、VirtualServerRouteリソースを使用して、特定のURLの管理をアプリケーション所有者やDevOpsチームに委任します。

Kubernetesクラスターにマルチテナンシーを実装する際は、次の2つのモデルから選択できます。完全セルフサービスと制限付きセルフサービスです。

フルセルフサービスの実装

完全なセルフサービスモデルでは、管理者はNGINX Ingress Controllerの設定に対する日常的な変更には関与しません。管理者が担当するのは、NGINX Ingress Controllerと、デプロイメントを外部に公開するKubernetesのServiceをデプロイすることだけです。その後、開発者は管理者を介さず、割り当てられた名前空間内にアプリケーションをデプロイします。開発者は、TLSシークレットの管理、ドメイン名の負荷分散設定の定義、およびVirtualServerリソースまたは標準のIngressリソースの作成によるアプリケーションの公開を担当します。

このモデルを説明するため、サンプルの「bookinfo」アプリケーション（Istioが作成したもの）を、次の図に示すように、2つのサブドメインa.bookinfo.comとb.bookinfo.comを使用して再現します。管理者がnginx-ingress名前空間（緑色）にNGINX Ingress Controllerをインストールしてデプロイすると、DevAチーム（ピンク色）とDevBチーム（紫色）は、それぞれ独自のVirtualServerリソースを作成し、各名前空間（それぞれAとB）内に分離されたアプリケーションをデプロイします。

Kubernetesクラスターにおける完全なセルフサービスのトポロジー。管理者はNGINX Ingress Controllerのデプロイと公開のみを行い、その後、開発者は管理者を介さずに、割り当てられた名前空間内にアプリケーションをデプロイします

チームDevAとDevBは、それぞれのドメインにIngressルールを設定し、外部接続を各自のアプリケーションにルーティングします。

チームDevAは、次のVirtualServerリソースオブジェクトを適用し、a.bookinfo.comドメインのアプリケーションをA名前空間で外部公開します。

コード例を読み込み中…

同様に、DevBチームは、b.bookinfo.comドメインのアプリケーションをB名前空間で公開するために、次のVirtualServerリソースを適用します。

コード例を読み込み中…

制限付きセルフサービスの実装

制限付きセルフサービスモデルでは、管理者がVirtualServerリソースを構成し、クラスターに入るトラフィックを適切な名前空間にルーティングします。一方、名前空間内のアプリケーションの構成は、担当する開発チームに委任します。各チームは、VirtualServerリソースにインスタンス化された自チームのアプリケーションサブルートのみを担当し、VirtualServerRouteリソースを使用してトラフィックルールを定義し、名前空間内でアプリケーションサブルートを公開します。

Kubernetesクラスターにおける制限付きセルフサービスのトポロジー図。管理者がVirtualServerリソースを構成し、アプリケーションの構成は開発チームに委任します。開発チームはVirtualServerRouteリソースを使用してトラフィックルールを定義し、アプリケーションのサブルートを公開します

図に示すように、クラスター管理者は緑色で示されたnginx-ingress名前空間にNGINX Ingress Controllerをインストールしてデプロイし、VirtualServerRouteリソース定義を参照するパスベースのルールを設定するVirtualServerリソースを定義します。

このVirtualServerリソース定義では、2つのサブルート（/productpage-Aと/productpage-B）について、VirtualServerRouteリソース定義を参照する2つのパスベースルールを設定します。

コード例を読み込み中…

名前空間AおよびB内のアプリを担当する開発チームは、各名前空間内のアプリケーションサブルートを公開するために、VirtualServerRouteリソースを定義します。チームは名前空間ごとに分離され、管理者がプロビジョニングしたVirtualServerリソースで設定されたアプリケーションサブルートのみをデプロイできます。

チームDevA（図中のピンク色）は、管理者が設定したアプリケーションサブルートのルールを公開するため、次のVirtualServerRouteリソースを適用します：/productpage-A。
コード例を読み込み中…
チームDevB（紫）は、管理者が設定したアプリケーションのサブルートルールを公開するために、次のVirtualServerRouteリソースを/productpage-Bに適用します。
コード例を読み込み中…

VirtualServerおよびVirtualServerRouteリソースで設定できる機能の詳細については、NGINX Ingress Controllerのドキュメントを参照してください。

注：マージ可能なIngressタイプを使用して名前空間をまたぐルーティングを構成できますが、制限付きセルフサービス委任モデルでは、この方法にはVirtualServerおよびVirtualServerRouteリソースと比べて次の3つの欠点があります。

セキュリティが低下します。
Kubernetesデプロイの規模が拡大して複雑になるにつれ、意図しない変更が加えられる可能性が高まります。これは、マージ可能なIngressタイプでは、開発者が自身の名前空間内のホスト名にIngressルールを設定することを防止できないためです。
VirtualServerリソースやVirtualServerRouteリソースとは異なり、マージ可能なIngressタイプでは、プライマリ（「master」）Ingressリソースから「minion」Ingressリソースのパスを制御できません。

制限付きセルフサービスモデルでのKubernetes RBACの活用

Kubernetesのロールベースアクセス制御（RBAC）を使用すると、ユーザーに割り当てられたロールに基づいて、名前空間およびNGINX Ingressリソースへのアクセスを制御できます。

たとえば、制限付きセルフサービスモデルでは、特別な権限を持つ管理者に限り、VirtualServerリソースへのアクセスを安全に許可できます。これらのリソースはKubernetesクラスターへのエントリーポイントを定義するため、誤用するとシステム全体の停止につながる可能性があります。

開発者はVirtualServerRouteリソースを使用して、自身が所有するアプリケーションルートのIngressルールを構成します。そのため、管理者は、開発者が作成できるリソースをVirtualServerRouteリソースのみに制限するRBACポリシーを設定します。開発者のアクセスをさらに厳密に制御する必要がある場合は、その権限を特定の名前空間に限定することもできます。

完全なセルフサービスモデルでは、開発者にVirtualServerリソースへのアクセス権を安全に付与できますが、この場合も管理者がその権限を特定の名前空間に制限することがあります。

RBAC認可の詳細については、Kubernetesドキュメントを参照してください。

ポリシーの追加

NGINX Policyリソースは、分散チームがマルチテナンシー環境でKubernetesを構成できるようにするためのもう1つのツールです。Policyリソースにより、OAuthやOpenID Connect（OIDC）を使用した認証、レート制限、Webアプリケーションファイアウォール（WAF）などの機能を利用できます。PolicyリソースはVirtualServerリソースおよびVirtualServerRouteリソースから参照され、Ingress構成に適用されます。

たとえば、クラスター内のID管理を担当するチームは、OktaをOIDC IDプロバイダー（IdP）として使用する、次のようなJSON Web Token（JWT）またはOIDCポリシーを定義できます。

コード例を読み込み中…

NetOpsチームとDevOpsチームは、次の例のように、VirtualServerまたはVirtualServerRouteリソースを使用してこれらのポリシーを参照できます。

コード例を読み込み中…

NGINX Policy、VirtualServer、VirtualServerRouteの各リソースを組み合わせることで、管理者が他のチームに設定を容易に委任できる分散設定アーキテクチャが実現します。各チームは、複数の名前空間にまたがるモジュールを組み合わせ、高度なユースケースに対応するようNGINX Ingress Controllerをセキュアかつスケーラブルで管理しやすい方法で設定できます。