AMQP UK, Monday, 20th September 2010
John’s question was:‐
I am wondering how AMQP applications are being managed, monitored, secured and controlled. For example:
What software, what security mechanisms for control and authentication (LDAP?), what user interface, what technology (SNMP, JMX, ???), what distribution mechanism (AMQP itself, sockets, ???), what data is being collected, distribution of new versions of the software, ???
Using RestMS to manage things seems like something worth looking into – has someone done this in earnest yet?
Sorry for the long list!
Well, that’s a long list of questions… so here’s a long reply for stormmq covering:‐
We made the decision that we should be secure by default – and that insecure ways of doing things should be impossible to do. For example, you can’t use us without using SSL (and as things change, we’ll be locking down the choice of ciphers and secure hashes used, too). Internally, we only use IPSec – with IKE v2 the only choice – for all local network traffic. We use whole‐disk encryption, too.
We only allow a subset of SASL mechanisms, but, more importantly, enforce our password policy on our users. That way, we can ensure passwords are as secure as possible. The automated systems that use messaging don’t need memorable passwords for admins! We haven’t seen clients use LDAP with our solution – primarily as most production systems have a very small set of ‘robot’ users, and the complexity involved vs using Posix file permissions
We’ve taken this further, and use the virtual hosts of AMQP to provide isolated environments for systems, so configuration managers can partition knowledge of passwords for production and development – and prevent data ‘accidents’.
We provide a rich RESTful API, with language bindings, to give users the management information they need, eg queue depth. Of course, how they use it is up to them. One of our customers integrated it with Nagios with a couple of lines of bash. Another uses AMQP’s message timestamps to calculate ‘how stale is my data’ and warn appropriately.
Internally, we monitor our own systems using AMQP. SNMP is too painful (and riddled with security holes),
syslog too insecure, and JMX is just… complex, heavy and without a standard transport layer. Our message formats are simple JSON – it’s easy to parse, easy to create and open to every language. One of the beauties of using AMQP for monitoring is adding resource (which happens regularly as a cloud service) requires no changes – there’s just a new publisher.