NGINX を使用した Kubernetes でのマルチテナントと名前空間分離の有効化

[編集者– この投稿は、当社の包括的な電子書籍「F5 NGINX による Kubernetes トラフィックの管理」からの抜粋です。 実用ガイド。 今すぐ無料でダウンロードしてください。

組織の規模が拡大するにつれて、Kubernetes での開発および運用ワークフローはより複雑になります。 一般的に、各チームが独自のクラスターを取得するよりも、チームで Kubernetes クラスターとリソースを共有する方がコスト効率が高く、より安全です。 しかし、チームがそれらのリソースを安全かつセキュアな方法で共有しなかったり、ハッカーが構成を悪用したりすると、展開に重大な損害が発生する可能性があります。

マルチテナントの実践と、ネットワークおよびリソース レベルでの名前空間の分離により、チームは Kubernetes リソースを安全に共有できます。 また、テナントごとにアプリケーションを分離することで、侵害の規模を大幅に軽減することもできます。 この方法は、特定のチームが所有するアプリケーションのサブセクションのみが侵害される可能性があり、他の機能を提供するシステムはそのまま残るため、回復力を高めるのに役立ちます。

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

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 ) 内で分離されたアプリケーションをデプロイします。

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

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

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

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

制限付きセルフサービス モデルでは、管理者は、クラスターに入るトラフィックを適切な名前空間にルーティングするように VirtualServer リソースを構成しますが、名前空間内のアプリケーションの構成は担当の開発チームに委任します。 各チームは、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 つの欠点があります。

1. 安全性は低くなります。
2. Kubernetes のデプロイメントが拡大し、より大きく複雑になるにつれて、マージ可能な Ingress タイプでは開発者が名前空間内のホスト名に対して Ingress ルールを設定することを妨げないため、偶発的な変更が発生する可能性が高くなります。
3. VirtualServer および VirtualServerRoute リソースとは異なり、マージ可能な Ingress タイプでは、プライマリ（「マスター」）Ingress リソースが「ミニオン」Ingress リソースのパスを制御することはできません。

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

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

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

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

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

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

ポリシーの追加

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

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

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

NGINX ポリシー、VirtualServer、VirtualServerRoute リソースを組み合わせることで、管理者が他のチームに簡単に構成を委任できる分散構成アーキテクチャが可能になります。 チームは、名前空間全体にわたってモジュールを組み立て、安全かつスケーラブルで管理しやすい方法で、洗練されたユースケースを使用して NGINX Ingress Controller を構成できます。

ポリシー リソースの詳細については、 NGINX Ingress Controller のドキュメントを参照してください。

この投稿は、当社の包括的な電子書籍「NGINX を使用した Kubernetes トラフィックの管理」からの抜粋です。 実用ガイド。 今すぐ無料でダウンロードしてください。

今すぐ30 日間の無料トライアルで NGINX Plus ベースの NGINX Ingress Controller をお試しいただくか、弊社にお問い合わせの上、ユースケースについてご相談ください。