On 09/20/2011 08:00 AM, Zane Bitter wrote:
On 19/09/11 20:26, Russell Bryant wrote:
>> 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.)
Ok, makes sense.
>> 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.
No problem. I think we should aim to have the MH_SSL checks in the code
removed for 0.5.0.
>> 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.)
Ok, great.
So I suppose we need to define a desired setup, figure out how to set it
up, and then document it. How about ...
- Local brokers on each Linux host configured only to allow
connections from the local QMF agents and also to federate to a central
broker.
- central broker configured with a user or users that can connect as a
QMF console
- all using SSL ideally
Thoughts?
>> 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.
ACK. :-)
>>
>> 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