[この投稿は、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のサービスのみに関する責任を負います。その後、開発者は管理者を介することなく、割り当てられたネームスペース内にアプリケーションをデプロイします。開発者は、TLS証明書・鍵の管理、ドメイン名のロードバランシングの定義、およびVirtualServerまたは標準のIngressリソースを作成することによるアプリケーションの公開に対する責任を負います。
このモデルを説明するために、次の図に示すように、a.bookinfo.com と b.bookinfo.com という 2 つのサブドメインを持つサンプル bookinfo アプリケーション (Istio が作成) をデプロイしてみます。管理者が NGINX Ingress Controller を nginx-ingress ネームスペース（緑でハイライト）にインストールしデプロイした後、チーム DevA（ピンク）と DevB（紫）は独自の VirtualServer リソースを作成し、それぞれのネームスペース（それぞれ A と B）内に独立したアプリケーションをデプロイします。
チームDevAとDevBは、それぞれのドメインに対してIngressルールを設定し、外部からの接続をアプリケーションにルーティングします。
チームDevAは、Aネームスペースのa.bookinfo.comとしてアプリケーションを公開するため、以下のVirtualServerリソースを適用します。
同様に、チームDevBは、Bネームスペースのb.bookinfo.comとしてアプリケーションを公開するため、以下のVirtualServerリソースを適用します。
制限付きセルフサービスを導入する
制限付きセルフサービスモデルでは、管理者はクラスタに着信するトラフィックを適切なネームスペースに転送するため、VirtualServerリソースを構成しますが、ネームスペース内のアプリケーションに関する設定はその担当の開発チームに委任します。これらの各チームはVirtualServerリソースで示された、アプリケーションのサブルートのみに責任を持ち、VirtualServerRouteリソースを利用し、トラフィックのルールを定義し、自身のネームスペース内のアプリケーションのサブルートを設定します。
図に示すように、クラスタ管理者は NGINX Ingress Controller を nginx-ingress ネームスペース (緑でハイライト)にデプロイし、VirtualServerRoute リソースの定義を参照するパスベースのルールを設定する VirtualServer リソースを定義しています。
この VirtualServer リソースの定義では、2つのパスベースのルールを記述し、/productpage-A と /productpage-B という2つパスに対するVirtualServerRoute リソースの定義を参照します。
ネームスペース A と B のアプリケーションを担当する開発チームは、 VirtualServerRouteリソースを定義して、ネームスペース内のアプリケーションサブルートを公開します。各チームはネームスペースによって分離され、管理者が設定した VirtualServer リソースで指定されたサブルートのアプリケーションに限定されます。
-
チーム DevA (図のピンク色) は、以下の VirtualServerRoute リソースを適用して、管理者が
/productpage-Aに割り当てたアプリケーションのサブルートを示すルールを公開します。/p> -
チーム DevB (紫色) は、以下の VirtualServerRoute リソースを適用して、管理者が
/productpage-Bに割り当てたアプリケーションのサブルートを示すルールを公開します。
VirtualServer および VirtualServerRoute リソースで設定できる機能の詳細については、 NGINX Ingress Controller のドキュメントを参照してください。
注：Mergeable Ingressタイプを使用してネームスペース間のルーティングを設定できますが、制限付きのセルフサービスデリゲーションモデルでは、そのアプローチにVirtualServerおよびVirtualServerRouteリソースと比較して3つのデメリットがあります。
- セキュリティが低い
- Kubernetes環境が大きく複雑になると、Mergeable Ingressタイプは開発者がネームスペース内のホスト名に対してIngressルールを設定することを避けられないため、想定外の設定変更が発生しやすくなる
- VirtualServer や VirtualServerRoute リソースとは異なり、Mergeable Ingressタイプはプライマリ（「マスタ」）Ingress リソースが「ミニオン」Ingress リソースのパスを制御することができません
制限付きセルフサービスモデルでKubernetesのRBACを活用する
Kubernetesのロールベースアクセスコントロール（RBAC）を使用すると、ユーザに割り当てられたロールに基づいて、ネームスペースとNGINX Ingressリソースへのユーザアクセスを制御することができます。
例えば、制限付きセルフサービスモデルでは、特別な権限を持つ管理者のみがVirtualServerリソースへのアクセスを安全に許可されます。これらのリソースはKubernetesクラスタのエントリポイントを定義するため、誤った利用がシステム全体の停止につながる可能性があります。
開発者は VirtualServerRoute リソースを使用して、自分が所有するアプリケーションへのルートを Ingress ルールで構成します。管理者は開発者がこれらのリソースのみを作成できるように RBAC ポリシーを設定します。開発者のアクセスをさらに規制する必要がある場合は、その許可を特定のネームスペースに制限することも可能です。
フルセルフサービスモデルでは、開発者は安全に VirtualServer リソースへのアクセスを許可されますが、ここでも管理者はその許可を特定の ネームスペースに制限することができます。
RBACによる認可の詳細については、Kubernetesのドキュメントを参照してください。
ポリシーの追加
NGINX Policyリソースは、複数のチームがKubernetesのマルチテナントデプロイメントを設定するためのもう一つのツールです。ポリシーリソースは、OAuthやOpenID Connect（OIDC）を使った認証、レート制限、Webアプリケーションファイアウォール（WAF）などの機能を実現する事ができます。ポリシーリソースは VirtualServer と VirtualServerRoute リソースで参照され、Ingress の設定として反映されます。
例えば、クラスタのアイデンティティ管理を担当するチームは、OIDCのアイデンティティプロバイダ（IdP）としてOktaを使用する際に、次のようなJSON Web Token（JWT）またはOIDCポリシーを定義することができます。
NetOpsやDevOpsのチームは、VirtualServerやVirtualServerRouteリソースを利用し、これらのポリシーを参照します。以下がその例です。
NGINX Policy、VirtualServer、VirtualServerRouteリソースを組み合わせることで、管理者が他のチームに簡単に設定を委譲できる分散構成アーキテクチャが可能になります。チームは、ネームスペース全体でモジュールを組み立て、安全でスケーラブルかつ管理しやすい方法を用いて、高度なユースケースに対応したNGINX Ingress Controllerを構成することができます。
Policyリソースの詳細については、NGINX Ingress Controllerのドキュメントを参照してください。
この投稿は、当社のeBook「Managing Kubernetes Traffic with F5 NGINX: A Practical Guide」からの抜粋です。今すぐ無料でダウンロードしてください。
NGINX PlusをベースにしたNGINX Ingress Controllerを30日間の無料トライアルで今すぐお試しいただくことが可能です。また、お客様環境での使用例については弊社までお問い合わせください。
