From 71dfa254560394f6ec8ae6da17329420a13e36a1 Mon Sep 17 00:00:00 2001 From: Petr Malik Date: Fri, 8 Jan 2016 15:46:24 -0500 Subject: [PATCH] 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 --- specs/mitaka/cassandra-root-enable.rst | 193 +++++++++++++++++++++++++ 1 file changed, 193 insertions(+) create mode 100644 specs/mitaka/cassandra-root-enable.rst diff --git a/specs/mitaka/cassandra-root-enable.rst b/specs/mitaka/cassandra-root-enable.rst new file mode 100644 index 0000000..be23fe6 --- /dev/null +++ b/specs/mitaka/cassandra-root-enable.rst @@ -0,0 +1,193 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + + Sections of this template were taken directly from the Nova spec + template at: + https://github.com/openstack/nova-specs/blob/master/specs/juno-template.rst + +.. + This template should be in ReSTructured text. The filename in the git + repository should match the launchpad URL, for example a URL of + https://blueprints.launchpad.net/trove/+spec/awesome-thing should be named + awesome-thing.rst. + + Please do not delete any of the sections in this template. If you + have nothing to say for a whole section, just write: None + + Note: This comment may be removed if desired, however the license notice + above should remain. + + +======================================= +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 +guests [1]_ 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. [1]_ +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 + +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-functions [1]_ + + +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 +========== + +.. [1] Cassandra user/database implementation review: https://review.openstack.org/#/c/206739/ + +Appendix +======== + +None