Latest revision as of 22:26, 13 June 2013

Eliminate Clear-Text Passwords from the "cells" Table of the Database

At present, passwords for rabbit queues are stored in clear text in the database. This blueprint is for the elimination of these clear-text passwords, either by encrypting them in the database or deprecating the use of the database for storing cells information.

Introduction

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.

First Potential 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.

Second Potential Solution

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.

Partial problem mitigation

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…