VerneMQ-MySQL -> acl-topic authorizations

[gitnwana]

Environment

• VerneMQ Version:1.12.3
• OS: Kubernetes
• Erlang/OTP version (if building from source):
• Cluster size/standalone: 2 nodes

Hi. We have created a VerneMQ cluster on Kubernetes, running with MySQL database as authorizing entity. We have followed all the steps written in the documentation.

Some of the problems that we are repeatedly running into are:-

1. When we create a new database entry into MySQL, sometimes the newly created client/user connects, sometimes they throw a connection error.
2. When creating a client with topic in subscribe ACL as "#" .. the client doesn't connect.
3. If the Kubernetes cluster is stopped, the previously disconnects (expected) and when it is restarted, the previously connected client does not reconnect. ( This has been observed 2 times).
4. If the subscribe ACL does not have "#" subscription, it still subscribes, but does not receive messages sent to other topic. ( Since it is # it should get all messages sent irrespective of the publish topic).

[ioolkos]

Make sure to turn off other auth plugins.

allow_anonymous = off
plugins.vmq_passwd = off
plugins.vmq_acl = off

Be aware that ACLs are cached in the session and the cache is only evicted when the client disconnects.

---

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq :point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

[gitnwana]

@ioolkos , Yes. All other plugins are off. We have followed the instruction given in the docs. The problem still persists.

[LukasVondracek]

Hi, I have these settings which are working:

name: DOCKER_VERNEMQ_ALLOW_ANONYMOUS value: 'off' name: DOCKER_VERNEMQ_ACCEPT_EULA value: 'yes' name: DOCKER_VERNEMQ_LISTENER__TCP__ALLOWED_PROTOCOL_VERSIONS value: '3,4,5' name: DOCKER_VERNEMQ_LISTENER__TCP__DEFAULT value: '0.0.0.0:1883' name: DOCKER_VERNEMQ_PLUGINS__VMQ_DIVERSITY value: 'on' name: DOCKER_VERNEMQ_LISTENER__SSL__CAFILE value: '/etc/ssl/ca.crt' name: DOCKER_VERNEMQ_LISTENER__SSL__CERTFILE value: '/etc/ssl/server.crt' name: DOCKER_VERNEMQ_LISTENER__SSL__KEYFILE value: '/etc/ssl/server.key' name: DOCKER_VERNEMQ_LISTENER__SSL__USE_IDENTITY_AS_USERNAME value: 'off' name: DOCKER_VERNEMQ_LISTENER__SSL__REQUIRE_CERTIFICATE value: 'off' name: DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT value: '0.0.0.0:8883' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__AUTH_POSTGRES__ENABLED value: 'on' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__POSTGRES__HOST value: 'myurl' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__POSTGRES__PORT value: 'myport' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__POSTGRES__USER value: 'myusername' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__POSTGRES__PASSWORD value: 'mypassword' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__POSTGRES__DATABASE value: 'mydbname' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__POSTGRES__PASSWORD_HASH_METHOD value: 'crypt' name: DOCKER_VERNEMQ_PLUGINS__VMQ_PASSWD value: 'off' name: DOCKER_VERNEMQ_PLUGINS__VMQ_ACL value: 'off' name: DOCKER_VERNEMQ_VMQ_DIVERSITY__POSTGRES__SSL value: 'on'

[gitnwana]

@LukasVondracek My configuration is largely the same except I am using MySQL DB. Please see..

 ```
- name: DOCKER_VERNEMQ_ACCEPT_EULA
      value: "yes"
    - name: DOCKER_VERNEMQ_ALLOW_ANONYMOUS  
      value: "off"
    - name: DOCKER_VERNEMQ_DISCOVERY_KUBERNETES
      value: "1"
    - name: DOCKER_VERNEMQ_LISTENER__VMQ__CLUSTERING
      value: "0.0.0.0:44053"
    - name: DOCKER_VERNEMQ_LISTENER__TCP__DEFAULT
      value: "0.0.0.0:1883"
    - name: DOCKER_VERNEMQ_LISTENER__WS__DEFAULT
      value: "0.0.0.0:8080" 
    - name: DOCKER_VERNEMQ_LISTENER__HTTP__DEFAULT
      value: "0.0.0.0:8888"
    - name: DOCKER_VERNEMQ_PLUGINS__vmq_diversity
      value: "on"
    - name: DOCKER_VERNEMQ_PLUGINS__vmq_passwd
      value: "off"
    - name: DOCKER_VERNEMQ_PLUGINS__vmq_acl
      value: "off"
    - name: DOCKER_VERNEMQ_VMQ_DIVERSITY__auth_mysql__enabled
      value: "on"
    - name: DOCKER_VERNEMQ_VMQ_DIVERSITY__mysql__host 
      value: "host-ip"
    - name: DOCKER_VERNEMQ_VMQ_DIVERSITY__mysql__port
      value: "port"
    - name: DOCKER_VERNEMQ_VMQ_DIVERSITY__mysql__user 
      value: "myusername"
    - name: DOCKER_VERNEMQ_VMQ_DIVERSITY__mysql__password 
      value: "mypassword"
    - name: DOCKER_VERNEMQ_VMQ_DIVERSITY__mysql__database 
      value: "database name"
    - name: DOCKER_VERNEMQ_VMQ_DIVERSITY__mysql__password_hash_method 
      value: "sha256"

@ioolkos 

[ioolkos]

@gitnwana this config seems to be ok. Keep us posted on your findings.

---

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq :point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

[gitnwana]

Hi @ioolkos ,

Based on our experiment, we have created the following 3 clients .

CLIENT - C1

INSERT INTO vmq_auth_acl
    (mountpoint, client_id, username,
     password, publish_acl, subscribe_acl)
VALUES
    ('', 'c1', 'u1', SHA2('123456789', 256),
     '[{"pattern":"a/order"},{"pattern":"a/status"}]',
     '[{"pattern":"a/%u"}]');


CLIENT- CPR

INSERT INTO vmq_auth_acl
    (mountpoint, client_id, username,
     password, publish_acl, subscribe_acl)
VALUES
    ('', 'cpr', 'upr', SHA2('123456789', 256),
     '[{"pattern":"a/ping"}]',
     '[{"pattern":"a/order"}]');

CLIENT- CLG

INSERT INTO vmq_auth_acl
    (mountpoint, client_id, username,
     password, publish_acl, subscribe_acl)
VALUES
    ('', 'clg', 'ulg', SHA2('123456789', 256),
     '[{"pattern":"a/ping"}]',
     '[{"pattern":"a/status"}, {"pattern":"a/order"}]');

The above is pasted in the form of MySQL Query statements. When we are connecting using MQTTBox, the clients are getting connected without any issues, but the problem is being observed while receiving and publishing messages in the topics.

• When published from the client 'c1' , to the topic 'a/order' , the same is received in client 'clg'. However, in the client 'cpr', the message is not received. Both of them subscribed to the same topic added in the subscribe_acl.

Also, any way to add global wildcard "#" to any subscribe_acl for a particular client?

[ioolkos]

@gitnwana Hm, okay. Can you try this on a newly spawned cluster? (my bet is not on DB but on messed up subscription state. Have you (or, well.. Kubernetes) made nodes leave the cluster, and then re-join with existing state from an attached volume claim? is it possible this might have happened?

---

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq :point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription

[gitnwana]

Hi @ioolkos , we have tried this on a newly spawned cluster as well but issues still persists.

Just to reiterate the problem, when we are disconnecting and reconnecting the client, we are able to receive the message. But nothing when the session is still on. Our use case needs both hardware and software clients of MQTT. Is there anyway, we can bypass the ACLs, keeping the client_id, username and password auth intact ?

[ioolkos]

@gitnwana please be aware that you cannot update an ACL in the DB and expect this to populate to an online session. The ACLs cached for the session will only be evicted when the client disconnects. A reconnect will get the fresh ACLs from the DB.

Can you exclude this is what causes the behaviour you're seeing?

---

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq :point_right: Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription

[gitnwana]

@ioolkos , Thanks for the clarification.

Our problem is that, when we have "n" clients following the same ACL pattern all the clients which are subscribed to the topic are receiving messages. When we are adding a new client ( n + 1) , following the same ACL pattern, the client which is subscribed to the topic previously aren't receiving messages from the newly created client.

Is there anyway, we can bypass this ACL, keeping the client_id, username and password auth intact ?

[gitnwana]

@ioolkos , any suggestions on this?