I've been coming across a number of organisations who are blocked from
installing Metron by the MySQL auth database.

The main problems with our MySQL default are:

* What? Un-ecrypted passwords?!? - which frankly is embarrassing in a
security platform and usually where the deployment conversation ends for me
* MySQL install varies from platform to platform
* An additional database to manage, backup, etc. so now I have to talk to a
* Harder to maintain HA for this without externalising and fighting against
our defaults
* There are a lot of dependencies for just storing a table of users
(Eclipse Link, JPA, the MySQL server and the need to get clients installed
and pushed separately because of licence requirements)
* Organisations don't want to have to manage yet another user source of
truth since this leads to operational complexity.

In short, managing our own user store makes very little sense to operations

Some of these (licence and inconsistency for example) could be solved by
changing our default DB to something like Postgres, which has easier terms
to deal with. We could start encrypting passwords, but there would still be
a lot of dependencies to store users, which is a problem much better solved
by LDAP.

Now that we have the option to use LDAP for user storage, I would suggest
that we deprecate and ultimately remove all the RDBMS and ORM dependencies,
which significantly reduces our dependencies and simplifies deployment and
long term management of Metron clusters.

So I propose that we deprecate the RDBMS use in the next Apache release,
and then strip out the RDBMS stuff in the following. We would continue to
use LDAP for users and HBase for non-LDAPy user settings (as we currently
do). We should also provide a small demo LDAP for full dev. Since we are
looking at adding Knox into the stack, that project provides a convenient
mini-LDAP demo service which would do this job without the need to add
additional components.

Thoughts? Anyone relying on MySQL for users (if so, are you aware that your
passwords are all plaintext? How do you currently handle the shortcomings
and admin overhead?) Any objections?


Reply via email to