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+%2...
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.
--
Russell Bryant