Thank you for putting these notes together.
On 09/19/2011 11:21 AM, Zane Bitter wrote:
(Note: technically you should read "TLS" everywhere I've written "SSL".)
OK, I finally have SSL working. Some investigation into the background of it reveals that in the forthcoming version 1.0 of AMQP, there is a STARTTLS-style feature for the client and server to negotiate whether to use SSL for a connection. See Book 5 of this document: http://www.amqp.org/confluence/download/attachments/7340084/amqp-1.0.0+%2820...
This is very much my preferred way of doing things. However, this is not part of the current AMQP version 0.10 :( The spec also notes a reason you may need a separate SSL port: a packet-inspecting firewall might see the AMQP handshake and regard it as not being an SSL connection. (I can think of another: you may want to configure blocking of non-secure connections from a portion of the network using your firewall, rather than through the application.)
Qpid does not support a way of running both SSL and non-SSL connections on the same port. So it looks like we will indeed have to request a separate SSL port from the IANA.
That's what I figured. Would you mind putting in the request?
As for broker configuration, I suggest we add a MATAHARI_SSL_PORT environment variable rather than require a ssl-port entry in the config file. We would handle it the same way as the MATAHARI_PORT variable, so that it defaults to our assigned port number (presumably 49001) rather than 5671.
For the port in particular, I think that makes sense since we need to set a default that is different than how qpidd would normally behave.
In general though, I think we should avoid getting in the habit of adding custom environment variables for every qpidd option that we find interesting. How about a single env var for a string of additional qpidd options to pass through? From there it's a documentation issue to show how to enable each particular thing that we care about.
Client configuration will be trickier. At the moment it requires a bunch of environment variables that the Qpid client library reads, but there is no nice way of passing those. There was a request that we be able to set the config file for the Qpid client library so that we could use /etc/matahari-broker.conf to configure it, but that support is not yet available. I am inclined to add CLI options to configure it.
CLI options to our agents for these options? Don't we already have these options in the code (but commented out for whatever reason)? If not, what else is needed?
That answers my basic SSL questions, but there is a whole other layer of questions about our security model in general that I am unclear on:
Yes, this is where things get complicated, yet it's absolutely critical that we answer these questions and provide solid documentation on the security model of this whole solution. Otherwise, Matahari is unusable for any real production usage IMO.
Does the SSL support include client certificate support?
Which users is Matahari targeted at? a) Public cloud providers b) Public cloud users c) Private cloud users d) All of the above
d, and more (bare metal systems management, too, not just cloud)
Where does the broker run? a) On the same host as the agents b) On the physical host with the agents in VMs c) Some centralised location d) All of the above
Primarily a and c, but potentially b as well.
The architecture we set up with the way our packages work today says that we propose a local broker on every Linux host running Matahari agents. From there, you federate to some administrator defined locations. We should provide some examples and best practices here.
For the purposes of documentation, I think it makes sense to demonstrate having a centralized broker that all of the local brokers federate with. We could even show how the centralized broker could be set up as an active-active cluster.
Which parts of the communication run on trusted networks (or locally) and which on untrusted networks?
I think it's fair to assume for the sake of our security architecture and documentation that all traffic may be running over an untrusted network.
Who should be authorised to access the Matahari agents?
This is tricky and shouldn't be defined by us. Before we go much further on this, what I really want to understand is what _authorization_ capabilities does qpid provide (not just _authentication_, but that's important too obviously)?
Are there any good qpid docs on security that we can reference here? This is complicated stuff, it has got to be documented well ...
How do we set up the initial keys to enforce the access policies?
Well ... certificate management is certainly outside of the scope of our project. We can provide a helper script to generate some self signed certs for testing purposes, though.
It would be good to document, say, the two or three most common scenarios that we envision, so that we can optimise for simple configuration in those cases. I think that would also be valuable in communicating to potential users whether Matahari is for them.
Absolutely agreed.