EMQX Enterprise

日本語

简体中文
English

日本語

简体中文
English

Appearance

お問い合わせ
お問い合わせ

グローバルネームスペース設定 ​

EMQX 6.1では、個別のネームスペースインスタンスを設定するだけでなく、ネームスペースの識別方法、分離動作の適用方法、トピックおよび認可の取り扱いを制御する一連のグローバルネームスペース設定が利用可能です。

これらの設定はクラスター全体に適用され、すべてのネームスペースおよびクライアント接続に影響します。通常、ネームスペース関連機能を有効化して使用する前に設定します。

グローバルネームスペース設定はダッシュボードの Management -> Namespaces -> Settings から管理できます。

注意事項

後方互換性を保つため、EMQX 6.1のほとんどのグローバルネームスペース設定（Client ID Isolation、Namespace as Mountpoint、Mount Prefix for Authorizationなど）はデフォルトで無効化されています。

対応する分離機能を有効にするには、Namespace Related Configurations の下で明示的にオンにする必要があります。

namespace_global_settings

明示的に作成されたネームスペースのみ許可 ​

この設定は、クライアントが明示的に作成されたネームスペースにのみ接続を許可するかどうかを制御します。

この設定が有効な場合、EMQXは接続処理中にクライアントのネームスペースを検証し、接続を許可するか拒否するかを判断します。

  • 有効:
    • ダッシュボードまたはREST APIで明示的に作成されていないネームスペースに解決されたクライアントは接続を拒否されます。
    • ネームスペースが解決できないクライアント（例えば、ネームスペースソースが設定されていないか有効な値を生成しない場合）も接続拒否されます。
  • 無効:
    • 明示的に作成されていないネームスペースへの接続も許可されます。
    • ネームスペースソースが設定されている場合、EMQXは必要に応じて自動的にネームスペースを作成することがあります。

注意事項

この設定を無効にする前に、Take Namespace From が正しく設定されていて、すべての有効なクライアントが正常にネームスペースを解決できることを確認してください。そうでないと、ネームスペースが解決できずにクライアントが拒否される可能性があります。

When to Resolve Namespace で After Authentication モードが選択されている場合、認証前のネームスペースチェックはスキップされます。明示的に作成されたネームスペースのチェックは認証完了後に実行されます。

デフォルトの最大セッション数 ​

この設定は、新規作成されるネームスペースのデフォルトの同時セッション最大数を定義します。

  • 有効:
    • 新規作成されるネームスペースは自動的にこの最大セッション制限を継承します。
  • 無効:
    • 新規作成されるネームスペースはデフォルトでセッション制限なし（infinity）となります。

この設定は設定適用後に作成されるネームスペースにのみ適用されます。既存のネームスペースには影響せず、必要に応じて個別に更新する必要があります。

ネームスペースを解決するタイミング ​

この設定は、接続ライフサイクルのどの段階でEMQXがクライアントのネームスペース識別子を解決するかを制御します。

EMQXはダッシュボードの When to Resolve Namespace ラジオボタンで選択可能な2つのモードをサポートしています。

  • Before Authentication（デフォルト）: 認証チェーンが実行される前にネームスペース式を評価し、その時点で利用可能な接続メタデータ（username、clientid、cert_common_nameなど）のみを使用します。これは設定ファイルの mqtt.client_attrs_init で tns を設定することに対応します。
  • After Authentication: 認証チェーンが完了した後にネームスペース式を評価します。標準の接続メタデータに加え、認証バックエンドから返された属性を含む client_attrs.* の値も利用可能です（例：HTTP認証レスポンスの tag フィールド）。これは設定ファイルの multi_tenancy.post_auth_tns_expression に対応します。

TIP

これら2つのモードは相互排他的です。After Authentication が設定されている場合、認証前の mqtt.client_attrs_init による tns 値は上書きされ優先されます。

明示的に作成されたネームスペースのみ許可との連携 ​

After Authentication モードが選択されている場合、Allow Only Explicitly Created Namespaces が有効でも認証前のネームスペースチェックは完全にスキップされます。解決されたネームスペースの存在確認やクォータチェックなどのすべての強制は認証完了後に実施されます。

ネームスペースの取得元 ​

この設定は、EMQXがクライアントのネームスペース識別子（client_attrs.tns）を導出するために使用するVariform式を指定します。

式は、When to Resolve Namespace 設定で決まる接続ライフサイクルのタイミングで評価されます。

  • Before Authentication モードでは、username、clientid、cert_common_name などの標準接続メタデータと認証前属性のみが利用可能です。
  • After Authentication モードでは、認証結果からマージされた属性を含む client_attrs.* も利用可能です。

TIP

Take Namespace From の式はVariform構文を使用します。利用可能な関数の詳細は Variform Expressions を参照してください。

この設定は以下の機能の前提条件です。

  • 自動ネームスペース作成
  • ネームスペースベースのトピック分離
  • ネームスペースベースのClient ID分離
  • ネームスペースレベルのセッション制限およびレート制限

Take Namespace From が設定されていない場合、tns 属性は生成されません。この場合、クライアントはどのネームスペースにも関連付けられず、ネームスペース関連の分離および制御機能はすべて無効のままになります。

例 ​

認証前 ​

ユーザー名からネームスペースを抽出する例：

text
nth(1, tokens(username, '-'))

この設定では、ユーザー名が tenantA-user1 のクライアントは認証前に tenantA がネームスペース識別子として割り当てられます。

認証後 ​

HTTP認証バックエンドから返された tag 属性を使用する例：

text
client_attrs.tag

認証バックエンドがタグを返さない場合のフォールバック：

text
coalesce(client_attrs.tag, username)

この設定では、EMQXは認証チェーンの完了を待ち、マージされた client_attrs から tag 値を読み取り、それをネームスペース識別子として割り当てます。

TIP

式の評価結果が空文字列の場合は既存の tns 値（存在すれば）を保持します。式の評価でエラーが発生した場合は警告がログに記録され、クライアントはネームスペースなしとして扱われます。

Client ID分離 ​

Client ID分離は、異なるネームスペースのクライアントが同じClient IDを使用した場合の競合を防止します。

有効にすると、EMQXは内部的にクライアントのClient IDにネームスペースをプレフィックスとして付加しますが、クライアントから提供された元のClient IDは変更されません。

Client ID分離が有効な場合、ダッシュボードは推奨されるデフォルト式を自動で入力します。

concat([client_attrs.tns, '-', clientid])

この設定により：

  • 異なるネームスペースのクライアントが同じClient IDを安全に使用できます。
  • 内部的に使用されるClient IDは常にネームスペースのプレフィックスを含みます。

この式は例示であり、ビジネス要件に応じてカスタマイズ可能ですが、結果として得られるClient IDはグローバルに一意である必要があります。

動作例 ​

ユーザー名からネームスペースを抽出するソースが設定されていると仮定します：

nth(1, tokens(username, '-'))

Client ID分離はデフォルト式で有効化されています：

concat([client_attrs.tns, '-', clientid])

クライアント接続情報 ​

クライアントユーザー名Client ID
AtenantA-user1client1
BtenantB-user2client1

内部的に使用されるClient ID ​

ネームスペース元のClient ID実際のClient ID
tenantAclient1tenantA-client1
tenantBclient1tenantB-client1

ネームスペースをマウントポイントとして使用 ​

有効にすると、EMQXはネームスペースが正常に解決された後にクライアントのネームスペースをトピックのマウントポイントとして使用します。これによりネームスペース単位のトピック分離が可能になります。

リスナーにすでに mountpoint が設定されている場合、この設定は無視され、リスナー単位の設定が優先されます。

動作 ​

Namespace as Mountpoint が有効になると、EMQXは以下のようにトピックを分離します。

  • PUBLISH、SUBSCRIBE、UNSUBSCRIBE、およびWillメッセージ処理時：
    • EMQXは内部的にトピックの先頭に {namespace}/ を自動的に付加します。
  • クライアントへのメッセージ配信時：
    • ネームスペースのプレフィックスは自動的に除去されます。
  • クライアントから見た場合：
    • パブリッシュおよびサブスクライブするトピック名は変更されません。
    • クライアントはネームスペースのプレフィックスを認識しません。

例 ​

クライアントがネームスペース n1 に属し、Namespace as Mountpoint が有効な場合。

クライアント側の動作 ​

  • クライアントは sensors/# をサブスクライブ
  • クライアントは sensors/data にパブリッシュ

EMQX内部の処理 ​

  • ブローカーはサブスクリプションを n1/sensors/# として登録
  • ブローカーはメッセージを n1/sensors/data でルーティング
  • メッセージはクライアントに sensors/data として配信

結果として：

  • ネームスペースのプレフィックスは内部でのみ使用されます。
  • クライアントは常に元のトピック名で操作します。
  • 異なるネームスペースのクライアントが同じトピックを使用してもメッセージは相互に届きません。

認可のためのマウントプレフィックス ​

この設定は、認可（ACL）チェックの前にトピックのマウントポイントプレフィックスを対象トピックやトピックフィルターに追加するかどうかを制御します。

マウントポイントプレフィックスは通常、Namespace as Mountpoint が有効な場合のネームスペースから取得され、以下の形式になります。

{namespace}/

動作 ​

Mount Prefix for Authorization が有効な場合：

  • EMQXはACLルールや認可バックエンドのマッチング前にトピックのマウントポイントを先頭に付加します。
  • 認可チェックはプレフィックス付きトピックに対して行われます。

この動作は以下の操作に適用されます。

  • PUBLISH
  • SUBSCRIBE
  • UNSUBSCRIBE
  • Willメッセージ

例 ​

以下の設定が有効とします。

  • Namespace as Mountpoint
  • Mount Prefix for Authorization
  • クライアントのネームスペース：n1

クライアントの操作 ​

クライアントは以下をサブスクライブしようとします。

sensors/#

認可で使用されるトピック ​

認可時にEMQXは n1/sensors/# を評価します。したがって、対応するACLルールは sensors/# ではなく n1/sensors/# として定義する必要があります。

推奨 ​

トピック分離のために Namespace as Mountpoint を有効にしている場合は、Mount Prefix for Authorization も有効にすることを推奨します。これにより、認可チェックがブローカー内部で使用されるトピック名と一致し、認可結果と実際のメッセージルーティングの不整合を防止できます。