EdJoPaTo / mqttui

Subscribe to a MQTT Topic or publish something quickly from the terminal
GNU General Public License v3.0
409 stars 21 forks source link

How to use MQTT5 enhanced auth for connecting? #176

Open veyalla opened 2 months ago

veyalla commented 2 months ago

mosquitto client tools have a mechanism to connect to the an MQTT 5 broker like so:

mosquitto_sub --host $broker--port $port --topic "/#" -v --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method $method -D CONNECT authentication-data $authdata

Is this possible using mqttui?

EdJoPaTo commented 2 months ago

Currently, there is no MQTT 5 logic specifically used. Until now there didn't seem to be a need for any MQTT 5 specific logic, but maybe this might be one?

What would be the benefit of supporting this? What does it enable? Is it the only way to connect to your broker for you?

veyalla commented 2 months ago

Thanks for the reply. I'm part of the IoT Operations team at Microsoft, and the product has an MQTT Broker built-in. The preferred way to connect to our broker is via MQTT 5 enhanced auth as I outlined above.

EdJoPaTo commented 2 months ago

Is there an article somewhere about why it's the preferred way? What's its benefits are?

Also, hey there over there. Noticed an Microsoft Article mentioning mqttui some time ago which was nice to see in the wild :innocent:

veyalla commented 2 months ago

Noticed an Microsoft Article mentioning mqttui some time ago which was nice to see in the wild 😇

Happy to showcase such a nifty tool, great work!

Is there an article somewhere about why it's the preferred way? What's its benefits are?

The broker in IoT Operations is a Kubernetes-native service. Ideally we'd like to suggest using mqttui to observe message activity on broker without exposing the mqtt endpoint outside of the cluster. For cluster internal clients, the broker has integration with Kubernetes service account tokens for authentication, and this leverages the MQTT5 enhanced auth features. For example an internal client could be spawned using a pod definition:

apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  # The namespace must match the IoT MQ BrokerListener's namespace
  # Otherwise use the long hostname: aio-broker.azure-iot-operations.svc.cluster.local
  namespace: azure-iot-operations
spec:
  # Use the "mqtt-client" service account which comes with default deployment
  # Otherwise create it with `kubectl create serviceaccount mqtt-client -n azure-iot-operations`
  serviceAccountName: mqtt-client
  containers:
    # Install mosquitto and mqttui utilities on Alpine linux
  - image: alpine
    name: mqtt-client
    command: ["sh", "-c"]
    args: ["apk add mosquitto-clients mqttui && sleep infinity"]
    resources:
      limits:
        cpu: 500m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 100Mi
    volumeMounts:
    - name: broker-sat
      mountPath: /var/run/secrets/tokens
    - name: trust-bundle
      mountPath: /var/run/certs
  volumes:
  - name: broker-sat
    projected:
      sources:
      - serviceAccountToken:
          path: broker-sat
          audience: aio-internal # Must match audience in BrokerAuthentication
          expirationSeconds: 86400
  - name: trust-bundle
    configMap:
      name: azure-iot-operations-aio-ca-trust-bundle

... and connect like so, after shelling into the container:

mosquitto_sub --host aio-broker --port 18883 --topic "#" -v --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/broker-sat)