Utilizing RedHat Ansible for Qube configuration

Skip to first unread message

Nicklaus McClendon

unread,
Dec 18, 2016, 7:14:08 PM12/18/16
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I really like what has been done with Salt to extend configuration
management to each Qube, however, I prefer Ansible RedHat to Salt and
use it to manage every other machine in my fleet. It seems
would be more efficient in the long run for me to utilize Ansible
instead of Salt, to cut down on duplication of tasks. I was
hoping to get some feedback on the following model before I started
working, as to cut down on any mistakes.

Ansible would run in dom0 or a trusted management Qube. Dom0 would be
preferable, as it could then create and destroy VMs, however this
could likely be done through a custom Qubes RPC within the management
Qube. Ansible supports a variety of "connection" types and I was
considering writing a connection type utilizing qrexec. In
this model, configuration commands would be pushed to each Qube from
dom0 (or the trusted management VM) using qrexec, and Ansible would
function more or less unaware of the change.

My primary question is how Qubes Salt avoids any possible attack back
from each individual Qube while still relaying state information.

- --
kulinacs <nick...@kulinacs.com>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEPL+ie5e8l/3OecVUuXLc0JPgMlYFAlhXJjMACgkQuXLc0JPg
MlbmBA//V4eYuQQ3mDxo4cUFFMWYAmjZWNppsrNkRjlzTEsLmstWc/mzdWJRjj5+
/FOTT18elcVcH48W5T9fLRTQLP/marQuXgYS2VK1JQY4VY0C4p4TlzW+OUHM5ygf
RhSXSjcM70yP1IktjduzkUfxz1utjIHVwckN3mYQ9QQd6kxvD1XDG2eTvcnNlvoe
2C0wqqcJdRQmvqpZ48F/6JiKGVmgOq+8ksYoj/PhhA+t7llOJRttCZK++O2p0yRU
VlJZahyulIlJfTf+TjuMez2npwAwYid4dlWilMNSLnAehPIGsCcObFwwR5nMZSJ5
7jPyViltmJp+7XOApHhkDlxXJxySM6ceHwLPQHrBbhWppM+GCKZxfSObhvsU+V8F
CJzdAFOjvhKtlj55k9yAV+t1GKkR6ItsaWA5Y55ONZDu9AX4R6TWHEZrue6jM82b
ZhGM79SUpuCDQ6SjpHbCxHhbP8rZthtj2822vYhCZHeMT4nd4fbpymH8mUd2Jrrc
1ycyQIEs1FFZte3EtEYrfGb0LU2kD4+jGQTZLNTkLnfESG6blWmIXehI0ibgwIbN
6gXsLl5/9LSHfeZvz2eBBI5mN177KuZMZizmJZD275+IVaxIK9B6BbuloPJ++/vF
RDFeISLLNX/tOVrXOndubSrU438xiGVlIYNcqMpA86DrX001jD0=
=BghQ
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki

unread,
Dec 18, 2016, 8:05:40 PM12/18/16
to Nicklaus McClendon, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Dec 18, 2016 at 07:13:44PM -0500, Nicklaus McClendon wrote:
> I really like what has been done with Salt to extend configuration
> management to each Qube, however, I prefer Ansible RedHat to Salt and
> use it to manage every other machine in my fleet. It seems
> would be more efficient in the long run for me to utilize Ansible
> instead of Salt, to cut down on duplication of tasks. I was
> hoping to get some feedback on the following model before I started
> working, as to cut down on any mistakes.
>
> Ansible would run in dom0 or a trusted management Qube. Dom0 would be
> preferable, as it could then create and destroy VMs, however this
> could likely be done through a custom Qubes RPC within the management
> Qube. Ansible supports a variety of "connection" types and I was
> considering writing a connection type utilizing qrexec. In
> this model, configuration commands would be pushed to each Qube from
> dom0 (or the trusted management VM) using qrexec, and Ansible would
> function more or less unaware of the change.

Take a look at https://github.com/Rudd-O/ansible-qubes

> My primary question is how Qubes Salt avoids any possible attack back
> from each individual Qube while still relaying state information.

This is done by not parsing anything coming from VM. We use intermediate
DispVM for that. The actual design is here:
https://github.com/QubesOS/qubes-issues/issues/1541#issuecomment-187482786

In short, configuring a (single) VM looks like this:
1. Start DispVM, send Salt configuration there (pretty much all of it,
with exception that only "pillars" related to this particular VM are
sent).
2. Let Salt in that DispVM figure out what really needs to
configured in target VM - it use salt-ssh over qrexec (instead of ssh)
to communicate with target VM. And configure it there.
3. Return final message (just text to be logged) back to dom0.

For every VM, new DispVM is used.

If anything will exploit Salt while parsing anything coming from VM, it
will only manage to take over that DispVM. Which have access only to
this particular target VM. The only real think that may happen, is to
learn about configuration targeted to other VMs. But can't modify this
configuration.

This intermediate DispVM is implemented only for Salt. The above linked
Ansible module do not have this property.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYVzJfAAoJENuP0xzK19cseioH/0qgs/auBYj8Z4lwwQHJaHyY
FOor78FvJfEdIBjq8/e/MEMFOBxM09ShLqlKw0wtjV1PD/wEhQK2hDfXGgNO9unp
/uMa1/YLgP3cVuTezj1Evz1oTwQR/JoIRCWTwmshjjWfs9lPIJg4JzzS2Drc250M
DoqD3CShFConkhSQBAJk5smYpcge5g61VbTLCw4KCJlmaTaS6scb3KjqLvHQn38Y
ShOL+uC3lrzB77jKGBjW45++T8388KhrfSp5P3TGfqGoHEeTfyGXhj3aiVXWjROK
7c3qt3+HJPfZc0ngp/q1F0z4HM4uUlFK4svMM1rJWjLOQjJhxxurLXJFC/CXjXY=
=AmmD
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages