Skip to content

ACLファイルの使用 ​

EMQXは、ACLファイルに格納された事前定義されたルールに基づく認可チェックをサポートしています。ファイル内に複数の認可チェックルールを設定できます。クライアントの操作要求を受け取ると、EMQXはACLファイル内の認可ルールを上から順に照合します。ルールにマッチした場合、その設定に従って現在の要求を許可または拒否し、その後のルールの照合を停止します。

ファイルベースのACLはシンプルで軽量です。一般的なルールの設定に適しています。クライアントごとに数百件以上のルールがある場合は、他の認可ソースの利用を推奨します。ファイルベースのACLは認可チェーンの最後の安全装置として機能させることができます。

前提条件

バージョン5.0以降、ファイルベースのACLルールはEMQXダッシュボードUIから編集およびリロードが可能です。

認可の基本概念に慣れておいてください。

ACLファイル形式 ​

ACLファイルに基づく認可チェックを行う前に、認可ルールをErlangタプルのデータリスト形式でファイルに保存する必要があります。

ACL設定ファイルは、ピリオドで終わるErlangタプルのリストです。タプルはカンマ区切りの式のリストで、全体は中括弧で囲まれています。

%%で始まる行はコメントとして認識され、解析時に無視されます。

例:

erlang
%% ユーザー名 "dashboard" のMQTTクライアントに "$SYS/#" トピックのサブスクライブを許可
{allow, {user, "dashboard"}, subscribe, ["$SYS/#"]}.

%% IPアドレス "127.0.0.1" のユーザーに "$SYS/#", "#" トピックのパブリッシュ/サブスクライブを許可
{allow, {ipaddr, "127.0.0.1"}, all, ["$SYS/#", "#"]}.

%% "すべてのユーザー" に `$SYS/#`, `#`, `+/#` のサブスクライブを拒否
{deny, all, subscribe, ["$SYS/#", {eq, "#"}, {eq, "+/#"}]}.

%% その他すべてのパブリッシュ/サブスクライブ操作を許可
%% 注意:本番環境では最後のルールを `{deny, all}` に変更し、設定 `authorization.no_match = deny` を推奨
{allow, all}.

ルールは上から順に照合されます。ルールにマッチすると、その許可設定が適用され、残りのルールは無視されます。

  • タプルの第1要素は、ルールがヒットした場合に適用される許可を示します。可能な値は以下の通りです:

    • allow
    • deny
  • タプルの第2要素は、そのルールが適用されるクライアントを表します。以下の用語と組み合わせでクライアントを指定できます:

    • {username, "dashboard"}:ユーザー名が dashboard のクライアント。{user, "dashboard"} も可。
    • {username, {re, "^dash"}}:ユーザー名が正規表現 ^dash にマッチするクライアント。
    • {clientid, "dashboard"}:クライアントIDが dashboard のクライアント。{client, "dashboard"} も可。
    • {clientid, {re, "^dash"}}:クライアントIDが正規表現 ^dash にマッチするクライアント。
    • {client_attr, "name", "dashboard"}:クライアント属性 name が dashboard と等しいクライアント。
    • {client_attr, "name", {re, "^dash"}}:クライアント属性 name が正規表現 ^dash にマッチするクライアント。
    • {ipaddr, "127.0.0.1"}:IPアドレス 127.0.0.1 から接続するクライアント。ネットマスクも使用可能です。EMQXがロードバランサーの背後にある場合、クライアントのMQTTリスナーで proxy_protocol を有効にする必要があります。
    • {ipaddrs, ["127.0.0.1", ..., ]}:指定した複数のIPアドレスのいずれかから接続するクライアント。ネットマスクも使用可能です。
    • all:すべてのクライアント。
    • {'and', [Spec1, Spec2, ...]}:リスト内のすべての条件を満たすクライアント。
    • {'or', [Spec1, Spec2, ...]}:リスト内のいずれかの条件を満たすクライアント。
  • タプルの第3要素は、ルールが適用される操作を示します。

    • publish:パブリッシュ操作に適用されるルール。
    • subscribe:サブスクライブ操作に適用されるルール。
    • all:パブリッシュおよびサブスクライブの両方に適用されるルール。
    • EMQX v5.1.1以降では、パブリッシュおよびサブスクライブ操作でQoSや保持メッセージフラグのチェックが可能です。第3要素に qos や retain を追加して指定できます。例:
      • {publish, [{qos, 1}, {retain, false}]}:QoS 1で保持メッセージでないパブリッシュを拒否。
      • {publish, {retain, true}}:保持メッセージのパブリッシュを拒否。
      • {subscribe, {qos, 2}}:QoS 2のトピックへのサブスクライブを拒否。
  • タプルの第4要素は、ルールが適用されるトピックを指定します。トピックはパターンのリストで指定します。トピックプレースホルダーも使用可能です。利用可能なパターンは以下の通りです:

    • 文字列値(例:"t/${clientid}"):トピックプレースホルダーを使用しています。クライアントIDが emqx_c の場合、トピック t/emqx_c に正確にマッチします。
    • 文字列値(例:"$SYS/#"):ワイルドカードを許可する標準的なトピックフィルターです。トピックフィルターはMQTT仕様に従ってトピックにマッチします。例として、$SYS/# はパブリッシュでは $SYS/foo、$SYS/foo/bar に、サブスクライブでは $SYS/foo、$SYS/foo/#、$SYS/# にマッチします。トピックプレースホルダーも利用可能です。
    • eqタプル(例:{eq, "foo/#"}):トピック文字列の完全一致を示します。このパターンはすべての操作に対して正確に foo/# トピックにマッチします。ワイルドカードやプレースホルダーは考慮されません。つまり、トピック foo/bar はマッチしません。

さらに、設定の最後に通常デフォルトとして使われる2つの特別なルールがあります。

  • {allow, all}:すべての操作を許可。
  • {deny, all}:すべての操作を拒否。

ダッシュボードでの設定 ​

EMQXはデフォルトでファイルベースの認可機能を設定しています。Actions列のSettingsをクリックすると設定内容の閲覧や編集が可能です。別のファイルベース認可を作成するには、Createをクリックし、BackendでFileを選択してNextを押します。以下はConfigurationステップの画面例です。

ダッシュボードでACLファイル編集

Configurationステップでは:

  • Precondition:任意のVariform式を入力します。この式がtrueと評価された場合のみ、この認可機能が呼び出されます。詳細はAuthorizer Preconditionsを参照してください。
  • ACL File:認可ルールを入力します。ファイル形式やフィールドの詳細はACLファイル形式を参照してください。

設定ファイルでの設定 ​

ファイルベースの認可機能は、fileタイプで識別されます。

設定例:

bash
authorization {
  deny_action = ignore
  no_match = deny
  sources = [
    {
      type = file
      enable = true
      path = "etc/acl.conf"
    }
  ]
}

各項目の説明:

  • type:認可機能のデータソースタイプ。ここではfile。
  • enable:認可機能を有効にするかどうか。値はtrueまたはfalse。
  • precondition:任意のVariform式。この式がtrueのときのみ認可機能が呼び出されます。省略または空の場合はプリコンディションなし。詳細はAuthorizer Preconditionsを参照してください。
  • path:設定ファイルのパス。デフォルトはetc/acl.conf。ダッシュボードやREST APIでファイルベース認可を編集すると、新しいファイルはdata/authz/acl.confに保存され、元のファイルの設定は読み込まれなくなります。

TIP

pathで指定された初期ファイルはEMQXによって変更されません。
ダッシュボードUIや管理APIからルールを更新すると、新しいルールはdata/authz/acl.confに保存され、元の設定ファイルは読み込まれなくなります。