For replication, have randomly generated password for each master slave

[Iccha Sethi]

We currently hard code replication passwords in config files. It will be advisable for security reasons to have different password for each master slave. This could be randomly generated throw away passwords. Because new user and password can always be geenrated for a replication user.

[Denis M. (dmakogon)]

Any clue how to fix it?

[Greg Lucas (glucas-q)]

The solution Iccha has proposed seems reasonable:

 - Generate a unique password when enabling the master for replication.
 - Include that in the snapshot info passed to the slave

We could generate one unique slave password per master, or we could generate a new one for every slave as part of getting the snapshot.

[Denis M. (dmakogon)]

Also i'd like to see this fix implemented taking into accout future barbican integration.
I'd like to propose next things:
1. Implement SecurityWorkflow interface with next methods:
1.1 Method that gets repliation password (symmetric key).
1.2 Method that gets backup password (symmetric key).
2. Implement class(see #1) that is needed by given use cases (replication and backup encryption).

File structure:
trove/
..........security/
.........................base.py
.........................proprietary.py (proprietary because we're doing our own KDF function, so it may be cryptographycally weak; contains #2)
..........................barbican.py (will be added in the future)

[Vipul Sabhaya (vipuls)]

Although having Barbican do this would be cool, i don't think it's necessary to over-engineer this specific fix. I would like to see something simple that doesn't require a massive refactor and addresses the bug.

[Amrith Kumar (amrith)]

Considering that the password has to be stored in some mechanism that supports reversible encryption, I see no reason why we can't just store it in the database. It doesn't seem therefore a good investment now to build an edifice now ...

[Timothy Given (tim-given)]

This issue looks to already be under way to a fix, but I just wanted to add something that may increase the importance of the original single user / password issue and the security risk it creates especially in a shared environment.

The replication user that is currently being created is not only being created with the same user and password, but is also being created using a wildcard '%' as the host field of the user. Due to this host field, any mysql client that can reach the database this replicant user is created on has enough privileges to connect to that database. MySQL stores the replication user and password as clear text in either a master.info file within the filesystem (Default - /var/lib/mysql/master.info) or to a table (mysql.slave_master_info).

Putting it all together. In a shared environment, I would have the ability to set up a master-slave build long enough to capture the user/password being used, then using a mysql client to test the network for what servers I can connect to. Finally once I have a list of viable databases, I simply set up a replication slave and pull the content from the binary logs of the databases I discovered. I may not capture an entire database, but I will still acquire sensitive information that I'm sure the unsuspecting master database owner wishes I would not have. With enough information in my relay logs, I could eventually rebuild their table structure and listen for as long as they have not noticed I am attached.

[Greg Lucas (glucas-q)]

Following up on my earlier proposal: if we generate a unique user/password per slave we also need to be sure to remove that user/password from the master when the slave is removed.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/120874

[Amrith Kumar (amrith)]

this is a replication bug fix that was targeted for Juno during the mid-cycle.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/120874
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=e5c757f3ee9e2642f26139f3a344f9dcc1ab6fb9
Submitter: Jenkins
Branch: master

commit e5c757f3ee9e2642f26139f3a344f9dcc1ab6fb9
Author: Morgan Jones <email address hidden>
Date: Wed Sep 3 12:20:53 2014 -0700

    Use unique passwords for replication user

    Generates a unique user with a random password for each slave.
    The replication user and password is passed to each slave during
    the snapshot attach process. Replication user is deleted from
    both the master and the slave during the detach process.

    Co-Authored-By: Nikhil Manchanda <email address hidden>
    Co-Authored-By: Denis Makogon <email address hidden>

    Change-Id: I9cb158a161714bfff90225227f5c652120393ba7
    Closes-bug: 1357065