Bug 753214

ovirt-node 2.1 includes in fedora-pkgs.ks:
...
libvirt-qmf
# install selected Matahari agents and the broker
matahari-broker
matahari-host
...
but we don't configure anything at the moment.

Which agents should be included, and how should QMF setup be secured by default?

Adding rbryant from the matahari team to assist with design/details here.

The simplest configuration would be to include the agents and the matahari-brokerd and not open any ports for allowing incoming connections.  This would mean that the Node broker would need to connect outward to connect to another broker (using federation)

With this default setup, the node is secured since nothing by default can access the QMF bus inside the node.

Then we can provide the following configuration options for users:
1. Config/kernel cmdline param to open port 49000 so external QMF Consoles can connect to the broker on the node, along with some sort of auth credentials for the Consoles to use.  Starting with basic user/pass seems reasonable as a starting point

2. Config/kernel cmdline/DNS SRV lookup to allow the Node broker to connect out to an external broker.  This can be done by default in an unsecured (no user/pass) as the external broker can be configured to restrict unsecured connections to only be QMF Agents and not Consoles/qpid native applications

The logic for using DNS SRV to have the Node broker connect out to an external broker is present already in the core matahari-brokerd package, so we should get this behavior by default.  So hopefully we only need to add #1 above for scenarios where we want users to connect directly to the Node using a QMF Console or the up and coming matahari-shell

In general, even if you don't open up port 49000, there are still some security concerns.  By default, a local user would still be able to connect to the local broker and exercise any of the methods served up by the agents.

The additional step that I would take to lock things down is to set up a default security policy for the matahari broker that only allows connections to the broker from agents, and not consoles (clients).

This page has some information about setting up QMF access control using qpid ACL:

    https://github.com/matahari/matahari/wiki/QMF-Access-Control-Policy

We should start with the rules defined in "Policy for Authenticated Consoles and Anonymous Agents".  This is almost exactly what we would use, we just wouldn't have any users in the "consoles" group by default.

Once an ACL file is created, it needs to be enabled for the matahari broker.  To do so, find this line in /etc/sysconfig/matahari-broker:

    QPIDD_OPTIONS="--config /etc/matahari-broker.conf"

The following will need to be added:

    --acl-file /path/to/acl/file

I don't know where it should go ... /etc/sysconfig/matahari-broker-acl perhaps.

(In reply to comment #3)
> In general, even if you don't open up port 49000, there are still some security
> concerns.  By default, a local user would still be able to connect to the local
> broker and exercise any of the methods served up by the agents.

If you're logged in as root, this is a moot point.  But I can see where you would want to prevent this for users logged in as a non-root user like 'admin'
 
> The additional step that I would take to lock things down is to set up a
> default security policy for the matahari broker that only allows connections to
> the broker from agents, and not consoles (clients).

Ok.  So:

0. Automatic DNS SRV Federation
   * keep 49000 disabled
   * make broker only accept agent connections by default
   * broker can use normal DNS SRV methods for connecting outward to an external broker

This makes it easy to set up for environments that have federated brokers already set up and proper DNS SRV records

For the other use cases, we need to provide via the TUI/kernel cmd line the ability to:

1. Matahari Direct Console Access: 
   * open port 49000
   * allow consoles to connect to the local broker with a specific set of credentials.  
Note, we still would let the local Agents connect to the local broker without a user/pass under the 'Agent Only' role)

2. Matahari Manual Federation Setup
   * provide manual config (ip address, port, user/pass) for upstream broker

Doing 0 by default means: locked down, but still functional for the right environment.  And then providing 1 and 2 via TUI/kcmd line allows for people to deploy for other environments usages

Make sense?

ACK.  Makes sense to me.

I would be happy to continue to provide backup on the details as needed once someone is working on this.

We're providing libvirt-cim and sblim-sfcb for monitoring now.  With plugins, a libvirt-qmf/matahari plugin could be created, but not something we're going to tackle at the moment.