openstack/trove-specs
Code Issues Proposed changes
09b0eaace5
trove-specs/specs/mitaka/cassandra-root-enable.rst
Petr Malik 71dfa25456 Add support for 'root' actions to Cassandra 
Implement root enable (with password)/disable and show calls in the
Cassandra guest agent.
Also include datastore-agnostic scenario tests for the root actions.

Change-Id: I87d2467ef062d8395bbdb291779a5db549205461
Implements: blueprint cassandra-root-enable
2016-01-08 15:46:24 -05:00

4.4 KiB
Raw Blame History

Support for 'root' actions to Cassandra

Implement root enable (with password)/disable and show calls in the Cassandra guest agent. Also include datastore-agnostic scenario tests for the root actions.

Launchpad Blueprint: https://blueprints.launchpad.net/trove/+spec/cassandra-root-enable

Problem Description

Continuing the work on add user/database support for Cassandra guests1 we should also enable the Trove users to create superuser accounts.

Proposed Change

The Cassandra's superuser is called 'cassandra'. It comes with any new Cassandra installation, but it can be deleted.

In Cassandra only SUPERUSERS can create other users and grant permissions to database resources. Trove uses the 'os_admin' superuser to perform its administrative tasks.2 The users it creates are all 'normal' (NOSUPERUSER) accounts.

The built-in 'cassandra' superuser is proactively removed on prepare as it is not needed.

During normal operation (no 'root' enabled), there should be only one superuser in the system (os_admin). The 'root' is therefore not enabled.

Configuration

None

Database

None

Public API

None

Public API Security

None

Python API

None

CLI (python-troveclient)

None

Internal API

None

Guest Agent

The 'enable' action will be implemented by creating a new superuser ('cassandra') and granting it full access to all keyspaces. The username ('cassandra') and password (user-supplied or random otherwise) will be returned back to the client.

Now on, there will be more than one superuser accounts in the system and the 'root' will hence be reported as 'enabled'.

The 'disable' action will merely reset the user's password to a new random string without exposing it to the end-user. The account itself will not be removed so the root-show will keep reporting root as 'enabled' as it should.

When a backup is restored the presence of superusers other than 'os_admin' will be checked and the root-status of the new instance will be reported as 'enabled' if there are any.

Note that a superuser cannot remove its super privileges or delete itself. It should therefore not be possible to bypass the root check by creating a new superuser, deleting the old one and restoring the state into a new instance.

Once having the superuser access to the database the end-user could of course alter/drop the 'os_admin', but doing that would render the instance unmanageable from Trove.

Alternatives

None

Dashboard Impact (UX)

None

Implementation

Assignee(s)

Primary assignee:

Petr Malik <pmalik@tesora.com>

Milestones

Mitaka

Work Items

  • Implement root-related calls in the Cassandra manager.
  • Add datastore-agnostic scenario tests to exercise the new functionality.

Upgrade Implications

None

Dependencies

This implementation largely depends on work done as a part of blueprint cassandra-database-user-functions3

Testing

  • Manager unittests will be added where appropriate.
  • Datastore-agnostic scenario tests to exercise the related functionality will be implemented.

Documentation Impact

Document the newly enabled functionality for the Cassandra datastore.

References

Appendix

None

  1. Cassandra user/database implementation review: https://review.openstack.org/#/c/206739/↩︎

  2. Cassandra user/database implementation review: https://review.openstack.org/#/c/206739/↩︎

  3. Cassandra user/database implementation review: https://review.openstack.org/#/c/206739/↩︎