On 19/09/11 20:26, Russell Bryant wrote:
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?
Will do.
> 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.
We have a QPIDD_OPTIONS variable in/etc/sysconfig/matahari-broker for
the broker already. The client is just a library though so there's
nowhere for us to pass options through to. We can only read them
ourselves in the agent or pass them through the environment. (The latter
is easy with systemd, but not so much with SysVInit.)
> 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?
Er, yes. I keep forgetting that we have a bunch of code that is not
compiled in.
>
> 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?
I believe so, yes.
> 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 ...
Evidently you can define ACLs to control access:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/2.0/html/Messagi...
(Authentication is provided through SASL; I think that part is
_comparatively_ well understood.)
> 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.
Is it, though? We're adding agents for things like puppet... isn't part
of the idea to be able to spin up a generic image and configure it for a
particular role? Unless we are on a closed, trusted network, what's the
point if that part is not going to be secured? Sure, we can easily put
this in the SEP basket, but that doesn't actually solve anyone's
problem. I think at a minimum we want to satisfy ourselves in principle
that there's a way to do this sensibly in the common scenarios that we
are optimising for.
>
> 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.