Skip to content

ネームスペース ​

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

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

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

信頼されたデプロイメントのみ

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

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

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)で作成可能です。
    • ネームスペース付きユーザーは割り当てられたネームスペース内のリソースのみを参照・操作できます。
    • ネームスペース非対応のクラスター全体設定は参照可能ですが読み取り専用で、グローバル管理者のみが変更可能です。
    • EMQX 6.0.4以降、ネームスペース管理者は自身のネームスペース内でAPIキーを管理可能です。グローバルキーや他ネームスペースのキーにはアクセスできません。
    • これにより、データ分離とともにテナント固有の安全な管理アクセスが保証されます。
  • マルチテナント管理

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

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

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

rule_engine.ssrfを有効にすると、コネクター設定のテスト、作成、更新時にHTTPおよびMQTTコネクターのターゲットを検証します。EMQX 6.0.4以降、このポリシーは他のコネクタータイプやランタイム接続には適用されません。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オーバーライド ​

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

異なるネームスペースのクライアントが相互に信頼されていない場合(例:各ネームスペースが外部顧客や別組織を表す場合)、EMQXがネームスペースを判定した際に適切なクライアントIDオーバーライド機構を必ず設定してください。

オーバーライドがないと、あるネームスペースのクライアントが別テナントのクライアントIDを再利用でき、そのテナントのクライアントを切断したり、永続セッションを乗っ取ったり、サービス拒否を引き起こす可能性があります。認証だけでは防げません。EMQXはセッションを実効クライアントIDでグローバルに識別するためです。

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

EMQXがユーザー名、クライアントID、クライアント証明書などの接続情報から認証前にネームスペースを判定できる場合、mqtt.clientid_overrideを設定します。例:

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

このルールはクライアントIDにネームスペースをプレフィックスとして付加し、競合を回避します。認証バックエンドがネームスペースやオーバーライド用の値を判定する場合は、バックエンド側でclientid_overrideを返すよう設定してください。両方の機構を同時に設定しないでください。詳細はクライアント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

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

ルールのネームスペース分離 ​

rule_engine.limit_selects_in_namespaceが有効(デフォルト)な場合、他のネームスペースのメッセージやクライアント関連イベントがネームスペース付きルールをトリガーすることを防ぎます。EMQXはクライアント属性client_attrs.tnsでクライアントのネームスペースを特定します。EMQX 6.1.5以降、この設定はルールのRepublishアクションの出力トピックもルールのネームスペース内に限定します。

トピックテンプレートのレンダリング後、レンダリング結果がすでに<namespace>/で始まっていなければ、EMQXは<namespace>/を先頭に付加します。すでに<namespace>/で始まるトピックは変更されません。グローバルルールやrule_engine.limit_selects_in_namespace = falseのデプロイメントは、ルールネームスペースを付加せずにレンダリング済みトピックにパブリッシュし続けます。

このRepublishの挙動はmqtt.namespace_as_mountpointに依存しません。この設定はクライアントのトピックパブリッシュやサブスクライブをネームスペース間で制限しません。クライアントのトピックアクセスを分離するには、マウントポイントと認可ルールによるトピック分離を設定してください。

マルチテナンシー機能のサポート状況 ​

ネームスペースはEMQXのマルチテナンシーの中核です。EMQX 5.9で導入されて以来、複数のサブシステムで段階的に対応が拡大しています。EMQXがサポートするマルチテナンシー機能は以下の通りです。

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

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

  • ルールおよびデータ統合の分離(6.0)

    ルール、アクション、ソース、コネクターにネームスペース分離を適用。

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

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

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

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

  • Prometheusメトリクスの分離(6.1、6.3で拡張)

    EMQX 6.1以降、メトリクスをネームスペースごとに公開・集約可能。6.3以降はルール、アクション、コネクターのデータ統合メトリクスにもネームスペース分離を適用。詳細はネームスペース別データ統合メトリクスのスクレイプを参照。

  • トピックメトリクス収集の分離(6.3)

    ネームスペース管理者が作成したトピックメトリクス収集は、同一ネームスペースのクライアントがパブリッシュしたメッセージのみをカウント。ネームスペース管理者は自身のネームスペースの収集のみ管理可能で、グローバル管理者は全ネームスペースの収集を一覧可能。詳細はトピックメトリクスを参照。

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

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

次のステップ ​

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