Using the RAUC hawkbit Updater ============================== .. _authentication-section: Authentication -------------- Target token ^^^^^^^^^^^^ As described on the `hawkBit Authentication page `_ in the "DDI API Authentication Modes" section, a device can be authenticated with a security token. A security token can be either a "Target" token or a "Gateway" token. The "Target" security token is specific to a single target defined in hawkBit. In the RAUC hawkBit updater's configuration file it's referred to as ``auth_token``. Gateway token ^^^^^^^^^^^^^ Targets can also be connected through a gateway which manages the targets directly and as a result these targets are indirectly connected to the hawkBit update server. The "Gateway" token is used to authenticate this gateway and allow it to manage all the targets under its tenant. With RAUC hawkBit updater such token can be used to authenticate all targets on the server. I.e. same gateway token can be used in a configuration file replicated on many targets. In the RAUC hawkBit updater's configuration file it's called ``gateway_token``. Although gateway token is very handy during development or testing, it's recommended to use this token with care because it can be used to authenticate any device. Mutual TLS with client key/certificate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hawkBit also offers a certificate-based authentication mechanism, also known as mutual TLS (mTLS), which eliminates the need to share a security token with the server. This is the preferred authentication mode for targets connecting to bosch-iot-suite.com. The target needs to send a complete (self-contained) certificate chain along with the request which is then validated by a trusted reverse proxy. The certificate chain can contain multiple certificates, e.g. a target-specific client certificate, an intermediate certificate, and a root certificate. A full certificate chain is required because the reverse proxy only keeps fingerprints of issuer(s) certificates. In RAUC hawkBit updater's configuration file the options are called ``ssl_key`` and ``ssl_cert``. They need to be set to the target's private key and a full certificate chain. If a file is supplied it needs to be in PEM format. Optionally, the ``ssl_engine`` option can be set if an OpenSSL engine needs to be loaded to access the private key. In that case the format of the value supplied to ``ssl_key`` depends on the engine configured. Streaming Support ----------------- By default, rauc-hawkbit-updater downloads the bundle to a temporary storage location and then invokes RAUC to install the bundle. In order to save bundle storage and also potentially download bandwidth (when combined with adaptive updates), rauc-hawkbit-updater can also leverage `RAUC's built-in HTTP streaming support `_. To enable it, set ``stream_bundle=true`` in the :ref:`sec_ref_config_file`. .. note:: rauc-hawkbit-updater will add required authentication headers and options to its RAUC D-Bus `InstallBundle API call `_. Plain Bundle Support -------------------- RAUC takes ownership of `plain format bundles `_ during installation. Thus rauc-hawkbit-updater can remove these bundles after installation only if it they are located in a directory belonging to the user executing rauc-hawkbit-updater. systemd Example ^^^^^^^^^^^^^^^ To store the bundle in such a directory, a configuration file for systemd-tmpfiles can be created and placed in ``/usr/lib/tmpfiles.d/rauc-hawkbit-updater.conf``. This tells systemd-tmpfiles to create a directory in ``/tmp`` with proper ownership: .. code-block:: cfg d /tmp/rauc-hawkbit-updater - rauc-hawkbit rauc-hawkbit - - The bundle location needs to be set in rauc-hawkbit-updater's config: .. code-block:: cfg bundle_download_location = /tmp/rauc-hawkbit-updater/bundle.raucb