Skip to content

ネームスペース

EMQX 5.9.0以降、ネームスペース機能により、ユーザーはMQTTクライアントを論理的にグループ化し、単一のEMQXクラスター内でトラフィック制限を適用できるようになりました。この機能は、複数のクライアントグループ(事業部門、アプリケーション、顧客など)が同じインフラを共有しつつ、論理的に分離されたスケーラブルなデプロイメントを実現します。

注意

この機能はEMQX 5.9ではネームスペースと呼ばれていますが、マルチテナンシー設計原則に従っています。

EMQX 6.1以降、ネームスペース関連の機能が強化されましたが、元の意味論は変更されていません。これらの強化により、マルチテナントの分離設定が簡素化され、トピック分離の動作が統一されました。

ネームスペースとは

EMQX Enterpriseにおけるネームスペースは、MQTTクライアントの論理的分離およびリソース管理のための仕組みです。異なる事業やテナントのクライアントを共有クラスター内の別々のネームスペースに分割し、接続、メッセージ、クォータなどの分離を実現します。

ネームスペースは、tns(テナントネームスペース)という特別なクライアント属性で識別されます。この属性は自動的に作成されるものではなく、ユーザー名やServer Name Indication(SNI)などのクライアント接続メタデータから設定によって導出されます。

ネームスペースは、ダッシュボードやREST APIで明示的に作成された場合でも、クライアント接続時に定義されたルールに基づいて自動的に作成された場合でも、有効になります。

典型的なユースケース例:企業内の複数事業部門によるクラスター共有、テナント単位のリソース分離管理、集中アクセス制御など。

ネームスペースで実現できること

  • クライアントとメッセージの論理的分離

    ネームスペースにより、異なるテナント間でクライアントIDやトピックスペースを論理的に分離できます。

    注意

    ネームスペースを有効にしても、クライアントIDの上書きやトピックプレフィックスは自動的には適用されません。これらの機能は手動で設定する必要があります。詳細は分離メカニズムをご覧ください。

  • テナント単位のクォータおよび接続制御

    ネームスペースごとに同時接続数やメッセージパブリッシュレートの制限を設定でき、公平な利用とシステムの安定性を確保します。

  • 強化されたログと運用可視性

    ログには自動的にネームスペース識別子(tns)が含まれ、クライアントの活動追跡や問題検出、テナント単位の診断が容易になります。

  • ネームスペースベースのリソース監視

    ネームスペースはテナントごとの接続数やメッセージスループットなどのメトリクス収集の明確な境界を提供し、キャパシティプランニングや運用インサイトに役立ちます。

  • 管理ユーザーの分離

    EMQX 6.0以降、ネームスペースはダッシュボード、CLI、APIユーザーにもネームスペース付きロールを通じて拡張されています。

    信頼できるデプロイメントのみ

    管理ネームスペースは、組織内のチームや事業部門を分離し、誤って互いの設定を変更するリスクを減らすための信頼できる内部デプロイメント向けです。この機能は強力な分離保証を提供せず、パブリックまたは信頼できないマルチテナント環境のセキュリティ境界としては適していません。

    委任管理者にネームスペーススコープのリソース管理を許可する場合は、管理ネームスペースの運用セキュリティをご参照ください。

    • 管理ユーザーは、例として ns:team_a::administrator のように特定ネームスペースに限定したロールで作成可能です。
    • ネームスペース付きユーザーは割り当てられたネームスペース内のリソースのみを閲覧・操作できます。
    • ネームスペース非対応のクラスター全体設定は閲覧のみ可能で、変更はグローバル管理者のみが行えます。
    • これにより、データ分離とともにテナント固有の安全な管理アクセスが実現します。
  • マルチテナント管理

    システム管理者は同一クラスター内で複数のネームスペースを管理でき、各テナントは独立した環境でリソースとユーザー権限を分離して運用できます。

管理ネームスペースの運用セキュリティ

委任されたネームスペース管理者は、コネクター、ブリッジ、アクションなどのアウトバウンドターゲットを設定できます。追加の制御がない場合、内部や機密ネットワークへの意図しないアクセスを許す可能性があります。

利用可能な場合は rule_engine.ssrf を有効にして、ルールエンジン管理のアウトバウンドターゲットを検証してください。さらに、ランタイムのネットワーク制御が必要な場合はEMQXホスト側でイグレス制御を追加します。

  • IdP、Webhook、コネクターバックエンドなど承認済みの宛先へのアウトバウンドアクセスのみ許可します。
  • インスタンスメタデータサービス、ループバックアドレス、リンクローカルアドレス、内部管理ネットワークへのアクセスは明示的に必要な場合を除き拒否します。典型的なブロック対象のメタデータエンドポイントは 100.100.100.200169.254.169.253169.254.169.254fd00:ec2::254 などです。
  • 新しい統合や管理機能でアウトバウンドHTTP/TCP接続を開始する場合は、必ずファイアウォールルールを見直してください。

詳細はルールエンジンポリシーとファイアウォールルールによるSSRF緩和をご覧ください。

分離メカニズム

EMQXは非常に柔軟で、ネームスペース導入前から複数の分離メカニズムをサポートしています。

ネームスペースは統一されたテナント識別子(client_attrs.tns)を提供し、クライアントID、トピックマウントポイント、関連設定を一貫したテナントコンテキストで整理できます。

しかし、分離ポリシーはビジネス要件に基づいて明示的に設定する必要があります。ネームスペースを有効にしても、EMQXはクライアントIDやトピックの分離を自動的には有効化しません。

クライアントIDの上書き

信頼できないマルチテナント環境では必須

異なるネームスペースのクライアントが相互に信頼されていない場合(例えば、各ネームスペースが外部顧客や別組織を表す場合)、mqtt.clientid_override の設定が必須です。これを設定しないと、あるネームスペースのクライアントが他テナントのクライアントIDを再利用し、そのクライアントを強制切断したり、永続セッションを乗っ取ったり、サービス拒否を引き起こしたりする恐れがあります。認証はこれを防げません。セッションの乗っ取りはACL適用前の接続レイヤーで発生します。

マウントポイントを使ったトピック分離と組み合わせて、トピックレベルのアクセスもネームスペースを跨がないようにしてください。

異なるネームスペースのクライアントが同じクライアントIDを使えるように、クライアントID上書きルールを設定できます。例:

hocon
mqtt.clientid_override = "concat([client_attrs.tns, '-', clientid])"

このルールはクライアントIDの前にネームスペースを付加し、競合を防ぎます。

マウントポイントを使ったトピック分離

異なるネームスペースのクライアントが同じトピック名をパブリッシュ/サブスクライブしても干渉しないように、マウントポイントを使ってトピックにネームスペースを自動的にプレフィックスできます。

EMQX 6.0以前では、マウントポイントは通常リスナー単位で設定されていました。例:

hocon
listener.{TYPE}.{NAME}.mountpoint = "${client_attrs.tns}/"

複数リスナー環境では設定の重複が必要でした。

EMQX 6.1以降は、ネームスペースを統一されたトピックマウントポイントとして利用できます。ネームスペースが特定されると、EMQXは内部的に {namespace}/ をトピックプレフィックスとして適用し、リスナーごとの設定不要で同様の分離効果を実現します。

後方互換性のため、デフォルトでは認可(ACL)チェックにマウントポイントプレフィックスは含まれません。

EMQX 6.1以降、以下を設定することでこの動作を有効化できます。

hocon
authorization.include_mountpoint = true

これにより認可バックエンドはマウントポイント付きトピックを受け取れます。

マルチテナンシー対応状況

ネームスペースはEMQXマルチテナンシーの中核です。EMQX 5.9で導入され、6.1で強化され、複数サブシステムでテナント分離をサポートしています。現在の対応状況は以下の通りです。

  • 管理面とMQTTネームスペースの統一(6.0)

    管理プレーン(ダッシュボード、CLI、API)とMQTTデータプレーンが同一のネームスペースモデルを共有。

  • 組み込みデータベース認証の分離(6.1)

    組み込みデータベースに保存された認証情報をネームスペース単位で分離可能。

  • 組み込みデータベース認可の分離(6.1)

    認可ルールを特定ネームスペースにスコープ可能。

  • Prometheusメトリクスの分離(6.1)

    ネームスペース別にメトリクスを公開・集約し、マルチテナント環境での可観測性を向上。

  • 保持メッセージクォータの分離

    ネームスペースごとに保持メッセージ関連のリソース使用を制限可能。

さらに、EMQX 6.0以降、ルール、アクション、ソース、コネクターに対するネームスペース分離が完全に実装され、今後のロードマップには含まれていません。

次のステップ

ネームスペースの概要と実現できることを理解したら、EMQXでの利用を開始するために以下を参照してください。