Salt management stack in Qubes

With Release 3.1, we are introducing a management stack. Its main purpose is to
provide an easy and automated way to setup even the most complex configurations within Qubes.
For example, installing and configuring Whonix on Qubes requires installation of
two templates, creating at least two VMs, setting some properties. Generally a
lot of manual work - documented well, but still not very
user friendly. The same goes for some other use cases like USB VM, Split GPG
and many more.

We have decided to base Qubes management stack on an existing solution. The
reason for that is quite simple: to not reinvent the wheel. There are already
multiple mature projects implementing system management, so we have decided to
source from their experience. The most important feature we sought in existing
solutions was declarative configurations: being able to describe desired system
This is a huge gain over imperative approaches (like custom scripts), which would
need to handle all corner cases, all possible interactions, and would soon get
really hard to maintain.

From all the available projects, we have chosen Salt Stack, because
of its wide adoption, ability to run without any network service (“local” mode),
clean and easy to read configuration, and ease of extensibility (python API for modules).
In addition, it has the ability to manage (possibly remote) system which doesn’t
have Salt stack agent (“minion”), a mechanism known as salt-ssh
(which in fact isn’t that unique to Salt Stack). With Salt Stack, we have implemented a
module to handle Qubes configuration, specifically managing VMs.

The current implementation released in Qubes 3.1 (rc1) is limited to only
manage VMs at dom0 level (create, set properties etc). Managing configuration
inside VMs (like installing additional packages there) is not yet available.
Also the current release doesn’t allow setting global properties like default
template or default netvm. Those features are planned, and to some degree
already implemented, but not mature enough yet to be included in Qubes 3.1
release.

Then, based on this functionality, we will be able to create a Management VM,
which will allow secure, centralized management of Qubes OS installations
in an organization or company. But to do it securely, we need to first finish
some major rework of Qubes core management code (“core3”), which is planned
for Qubes 4.0. Then it will be possible to implement Management VM in a way so that it
will have no access to user data, only ability to manage configuration of
(selected) VMs.

Going back to the present time - if you want to read more about technical
details of the current implementation and configuration, take a look at the
documentation.

And finally, some example configurations, taken from default set -
configuration of Whonix-Gateway: