Users / ACL per listener #14605

Saddamus · 2025-01-23T18:19:16Z

Saddamus
Jan 23, 2025

Can anybody help me to achieve the following ? Lets say i have users A, B, C, D. Users A,B,C are used inside of bigger env, where TCP port is exposed and they should be allowed to all pub and sub - no restrictions on that TCP listener, but user D is connected over TLS listener which is exposed to the world and my goal is that ONLY this user can be authorised on TLS listener and should only be allowed to publish, no subscribe. I tried plenty of approaches with ACL, but no success :(
In other words - do not allow any other user than D on TLS listener & allow D only PUB operations.

Answered by Saddamus

Jan 23, 2025

Looks like following approach does the job:

# SSL listener in external zone
listeners.ssl.external {
  bind = "0.0.0.0:8883"
  zone = "external"
  ssl_options {
    keyfile = "/opt/emqx/certs/key.pem"
    certfile = "/opt/emqx/certs/cert.pem"
    cacertfile = "/opt/emqx/certs/cacert.pem"
  }
}

# TCP listener in internal zone
listeners.tcp.default {
  bind = "0.0.0.0:1883"
  zone = "internal"
}

listeners.ssl.default.enable = false

# Configure MQTT settings including client attributes
mqtt {
  client_attrs_init = [{
    expression = "iif(str_eq(zone,'internal'),'#','')"
    set_as_attr = "internal_topic"
  }, {
    expression = "iif(str_eq(zone,'external'),'#','')"
    set_as_attr = "ext…

View full answer

thalesmg · 2025-01-23T19:11:30Z

thalesmg
Jan 23, 2025
Collaborator

Hi.

Sounds like clients A, B and C have unrestricted access on the cluster. If that's so, wouldn't it work for you to register all A-D clients in a authenticator (for example, built-in database), and set up an authorizer (for example, file or built-in database) with lax rules for A-C and pub-only for D? i.e., no need to forbid A-C from connecting to the TLS listener, if they are allowed anything.

5 replies

Saddamus Jan 23, 2025
Author

There is a need to restrict any other user against using TLS listener. What if A-C credentials leak and somebody big, bad and angry starts using them on TLS listener ? I need TLS to be allowed only for D and D should be allowed only for pub. I hoped to achieve this by zonenes, having TLS listener on separate zone, but then i found that ACL is above zones level. Then there is something like: ${zone}: It will be replaced with the client's Zone at runtime. "The ${zone} placeholder can be used directly in authentication templates. For details about the Zone configuration, see Zone Override.", but not sure what exactly it does and if can help to achieve what i need.

zmstone Jan 23, 2025
Maintainer

mTLS is the best solution.
You don't want bad and angry ones to get accepted on to MQTT layer. :D
For ACL, see my reply in the other thread.

Saddamus Jan 23, 2025
Author

mTLS will be used, but the more security in security, then solution is more secure :) One can ask what if ssl keys leak :)

zmstone Jan 23, 2025
Maintainer

If your client D is only one client (but not a type of clients), then you can create one ACL rule for it matching its username or clientid.
e.g.

{allow, "D", publish, ["#"]}.
{deny, all, all}.

Saddamus Jan 23, 2025
Author

This just allows D to publish, but does not restrict A-C from using TLS listener. I will try the approach you have described with attribute, but in reverse way ["${client_attrs.external_topic}"]} and acl to pub only. This will still allow A-C to pub on TLS, but at least will not let anybody to sub from tls as far as i understood this properly.

zmstone · 2025-01-23T20:05:35Z

zmstone
Jan 23, 2025
Maintainer

Authentication

You can set enable_authn = false for the TCP listener. So clients connecting to TCP listener will never need any authentication.
ref: https://docs.emqx.com/en/enterprise/v5.8.4/hocon/#V-listeners-S-listeners-tcp-S-mqtt_tcp_listener-enable_authn

For TLS listener, there are a few ways to allow only desired clients to connect:

Transport layer: mTLS
MQTT layer: Authentication

Authorization

To allow clients connected from TCP listener publish/subscribe any topic they want, it's a bit more complex.
There are two alternatives

Superuser

Configure authentication for TCP listener and grant clients is_superuser = true in authentication result.

Use ACL template

Create a new zone in emqx.conf: zones.trustedzone.mqtt.max_packet_size = 1M (this is for step 2)
Put TCP listener in the zone: listener.tcp.name.zone = trustedzone (next steps will know from which listener the client was connected)
Extract a client attribute (client attributes support conditional extraction, and can be used in ACL).

mqtt {
  client_attrs_init = [{
    expression = "iif(str_eq(zone,'trustedzone'),'#','')"
    set_as_attr = trusted_topic
  }]
}

Add ACL rule {allow, all, all, ["${client_attrs.trusted_topic}"]}.

Notes:

Step 3 only extracts the client attribute when the zone is trustedzone, otherwise no attribute is added (not with empty string)
Step 4 only takes effect when this attribute reference exists${client_attrs.trusted_topic} (will not render empty topic)

1 reply

zmstone Jan 23, 2025
Maintainer

Similar approach to allow clients connected from TLS listener to publish (but not subscribe) any topic

Saddamus · 2025-01-23T22:36:09Z

Saddamus
Jan 23, 2025
Author

Looks like following approach does the job:

# SSL listener in external zone
listeners.ssl.external {
  bind = "0.0.0.0:8883"
  zone = "external"
  ssl_options {
    keyfile = "/opt/emqx/certs/key.pem"
    certfile = "/opt/emqx/certs/cert.pem"
    cacertfile = "/opt/emqx/certs/cacert.pem"
  }
}

# TCP listener in internal zone
listeners.tcp.default {
  bind = "0.0.0.0:1883"
  zone = "internal"
}

listeners.ssl.default.enable = false

# Configure MQTT settings including client attributes
mqtt {
  client_attrs_init = [{
    expression = "iif(str_eq(zone,'internal'),'#','')"
    set_as_attr = "internal_topic"
  }, {
    expression = "iif(str_eq(zone,'external'),'#','')"
    set_as_attr = "external_topic"
  }]
}

# Basic zone configurations
zones.internal.mqtt.strict_mode = false
zones.external.mqtt.strict_mode = false

% Allow clients to publish to $SYS topics about their own connection state
{allow, all, publish, ["$SYS/broker/connection/${clientid}/#"]}.

% Allow zone-based access as before
{allow, all, publish, ["${client_attrs.external_topic}"]}.
{allow, all, all, ["${client_attrs.internal_topic}"]}.

Thank you

1 reply

zmstone Jan 24, 2025
Maintainer

Great.
I edited quotes in your answer (from ` to ```).

BTW, allowing clients to publish to $SYS topic isn't the best practice.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Users / ACL per listener #14605

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 3 comments 7 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Users / ACL per listener #14605

Saddamus Jan 23, 2025

Replies: 3 comments · 7 replies

thalesmg Jan 23, 2025 Collaborator

Saddamus Jan 23, 2025 Author

zmstone Jan 23, 2025 Maintainer

Saddamus Jan 23, 2025 Author

zmstone Jan 23, 2025 Maintainer

Saddamus Jan 23, 2025 Author

zmstone Jan 23, 2025 Maintainer

Authentication

Authorization

Superuser

Use ACL template

zmstone Jan 23, 2025 Maintainer

Saddamus Jan 23, 2025 Author

zmstone Jan 24, 2025 Maintainer

Saddamus
Jan 23, 2025

Replies: 3 comments 7 replies

thalesmg
Jan 23, 2025
Collaborator

Saddamus Jan 23, 2025
Author

zmstone Jan 23, 2025
Maintainer

Saddamus Jan 23, 2025
Author

zmstone Jan 23, 2025
Maintainer

Saddamus Jan 23, 2025
Author

zmstone
Jan 23, 2025
Maintainer

zmstone Jan 23, 2025
Maintainer

Saddamus
Jan 23, 2025
Author

zmstone Jan 24, 2025
Maintainer