Open Stack

At present, all the information that allows cells to communicate to each
other—including the Rabbit username and password—is stored in the
database, in clear text; while not really a security issue (if someone
can read your database, you're already on quicksand, security wise),
this is somewhat undesirable.  I would like to try to address this
issue, but I can really only come up with two basic approaches, both of
which will cause some migration issues, so I'm hoping to kick off a
discussion as to which will be the more acceptable solution.

The first potential solution is to simply encrypt the password in the
database.  (Actually, I intend to first merge all of the RPC information
into a single database field, then encrypt that; that will make it
easier to allow for alternate communication mechanisms in the future.)
The problem with this approach is the key management problem: we either
have to encrypt the data during the migration, or provide a mechanism
whereby the data may be lazily encrypted at runtime; and we must also
allow for rekeying later on.

The second potential solution is to drop the cells table from the
database and place all the data regarding cells (including the
connection information) into a configuration file.  (Not the master
configuration file; my vision here is to add a single option that says
to load cells data from an auxiliary JSON file, a la policies.)  The
problem with this approach, of course, is that the data has to be
migrated out of the database and into that JSON file in some fashion;
this can't really be adequately handled via database migrations.  We
also necessarily lose the ability to add and remove cells via the API.

I have thought of one way to at least partially mitigate the downsides
of the second solution: allow the cell data to come from the database OR
the file.  We could then create a simple tool that could allow you to
extract the data from the database and store it in a file later on,
after the migration.  In this scenario, the "cells" table remains for
the Havana release, then a later migration would remove it for Icehouse.
We would still need to ensure that the pending deprecation is carefully
documented, along with the migration strategy, so that existing users
aren't caught by surprise…

Thoughts?
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>