Improving Security¶
Moving Secrets Out of Config¶
Example use of environment variables, e.g. for secrets:
Running as non-root¶
It is good practice not to run Docker containers as root, and updates2mqtt will work with any user so long as it has Docker permissions, usually as a result of being a member of the docker group.
To create a suitable use, use the shell command below - it will create a user that can only be used for this purpose, and can’t otherwise login. It assumes there is already a group called docker with access to the Docker Daemon, if you dont have one, follow the Docker Post Install Steps which explain how and why to do it.
Note the uid that is reported here. If you don’t know the gid for the docker group, use grep docker /etc/group. In this example, our uid is 130 and the gid of docker group is 119.
In the docker-compose.yaml, set the user and group using user attribute:
services:
updates2mqtt:
container_name: updates2mqtt
image: ghcr.io/rhizomatics/updates2mqtt:latest
user: 130:119
If you’re using Updates2MQTT to update local git repos, then the user created above will also need rw access to those, which you can do by making it a member of the same group as owns the repos and making sure they have group rw access configured.
For more information, see the Understanding the Docker USER Instruction article from Docker.
MQTT Access Control¶
Its best to have a dedicated MQTT user for Updates2MQTT, for security and debug. For most secure installations, only use secure ports with validated certificates, although this will require more complicated setup and ongoing support, including using host names rather than IP addresses, and with LetsEncrypt to update certificates.
The two brokers most commonly used with Home Assistant, Mosquitto and EMQX, both have access control mechanisms, so you can restrict the user account for Updates2MQTT to only be able to read and write its own topics.
MQTT TLS¶
tls_mode defaults to off, and can be switched to on or to insecure for testing with mismatched hostnames.
Encrypt MQTT broker communication with TLS to wrap socket communication and optionally verify client and.or server identity.
This can be used in basic non-auth mode, (using default public certificate authorities, or local ones located at ca_certs in the mqtt config section), or using client certificates too with client_cert and client_key. cert_reqs can be used with any of the python SSL values, e.g. CERT_REQUIRED.
mqtt:
host: localhost
port: 1883
tls_mode: ON
ca_certs: ssl/ca_cert.crt
client_cert: ssl/client_cert.pem
client_key: ssl/client_key.pem
cert_reqs: CERT_OPTIONAL
See the Paho MQTT tls_set API documentation for more on the underlying config, which is based on Python’s ssl module.