ネームスペース

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

EMQX のネームスペース機能は以下の2つの部分で構成されています：

• MQTT クライアントネームスペース — MQTT クライアントを（ユーザー名、SNI、その他の接続メタデータによって）論理的にグループ化し、ネームスペースごとのクォータ、レート制限、クライアントIDおよびトピックの分離設定を適用します。
• 管理ユーザーネームスペース — Dashboard、CLI、API ユーザーを namespaced roles を通じて特定のネームスペースにスコープし、委譲された管理者が割り当てられたネームスペース内のリソースのみを閲覧・操作できるようにします。EMQX 6.0 以降で利用可能です。

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

管理ユーザーネームスペース は、同一組織内のチームや事業部門を分離するなど、信頼できる内部デプロイメント向けに設計されています。誤って相互の設定を変更するリスクを減らすためのものであり、強固な分離保証を提供せず、パブリックまたは信頼できないマルチテナント環境のセキュリティ境界としては適していません。パブリックなマルチテナント環境で管理ユーザーネームスペースの利用を検討されている場合は、EMQ の営業担当までお問い合わせください。このユースケースは現時点で標準機能としてはサポートされていません。

MQTT クライアントネームスペース については、ネームスペース間のクライアント分離はオプトインであり、明示的に設定する必要があります。ネームスペース間のクライアントが相互に信頼されていない場合は、分離メカニズム を参照し、必要なクライアントIDのオーバーライドやトピックマウントポイントの設定を行ってください。

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

ネームスペースとは

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

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

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

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

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

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

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

  補足

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

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

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

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

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

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

  ネームスペースごとに接続数やメッセージスループットなどのメトリクスを収集でき、容量計画や運用インサイトに役立ちます。

• 管理ユーザーの分離

  EMQX 6.0 以降、ネームスペースは Dashboard、CLI、API ユーザーにも namespaced roles を通じて拡張されています。このページ上部の 信頼できるデプロイメントのみ の注意事項をご確認ください。

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

• マルチテナント管理

  システム管理者は同一クラスター内で複数のネームスペースを管理でき、各テナントは分離されたリソースとユーザー権限を持つ自己完結型の環境で運用可能です。

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

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

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

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

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

分離メカニズム

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

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

しかし、分離ポリシーはビジネス要件に応じて明示的に設定する必要があります。ネームスペースを有効にしただけでは、クライアントIDやトピックの分離は自動的には有効になりません。

クライアントIDオーバーライド

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

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

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

異なるネームスペースのクライアントが同じクライアントIDを使えるようにするには、クライアントIDオーバーライドルールを設定します。例：

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

このルールはクライアントIDにネームスペースをプレフィックスとして付与し、競合を回避します。

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

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

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

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

複数リスナー環境では設定が煩雑でした。

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

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

EMQX 6.1 以降、以下の設定でこの挙動を有効化できます：

authorization.include_mountpoint = true

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

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

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

• 管理プレーンと MQTT ネームスペースの統合管理（6.0）

  Dashboard、CLI、API と MQTT データプレーンで共通のネームスペースモデルを共有。

• 組み込みデータベース認証の分離対応（6.1）

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

• 組み込みデータベース認可の分離対応（6.1）

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

• Prometheus メトリクスの分離対応（6.1）

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

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

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

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

次のステップ

ネームスペースの概要と実現できることを理解したら、EMQX での利用を開始するために以下のステップをお勧めします：

• ネームスペースの作成：Dashboard や REST API を使った明示的な作成方法や、クライアントメタデータに基づく自動作成方法を学びます。
• ネームスペースの設定と管理：Dashboard や REST API でレート制限やセッションクォータを設定します。
• ネームスペースのグローバル設定：クラスター全体のネームスペース動作、ネームスペース解決、分離メカニズム、トピックマウントポイント、認可処理を設定します。
• クイックスタート：ネームスペース体験：MQTTX を使ったハンズオンガイドで、ネームスペースベースのクライアントおよびトピック分離をすばやく試せます。