Adds Nova discoverable policy CLI spec
https://blueprints.launchpad.net/nova/+spec/discoverable-policy-cli Not all users have the same set of privileges. Not all API endpoints are enabled. Because of this, adding an nova-manage CLI subcommand that lists the operations an user is allowed to use can be helpful. This spec describes phase one of a two phased implementation. The first phase will prove out the idea using a raw representation that will be improved in the second phase. Co-Authored-By: Chris Dent <cdent@anticdent.org> Implements: blueprint discoverable-policy-cli Change-Id: I973f1e0545c73d66ef17bed77c6dda5de007cb1e
This commit is contained in:
Claudiu Belu
255
specs/newton/approved/discoverable-policy-cli.rst
Normal file
255
specs/newton/approved/discoverable-policy-cli.rst
Normal file
@@ -0,0 +1,255 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
============================
|
||||||
|
Nova discoverable policy CLI
|
||||||
|
============================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/nova/+spec/get-policy-settings-cli
|
||||||
|
|
||||||
|
Not all users have the same set of privileges. Because of this, adding a way
|
||||||
|
to list the policy rules the user passes can be helpful.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Currently, users have no direct way of knowing which APIs they are allowed to
|
||||||
|
use or which APIs are enabled by policy. This spec will add a new CLI command
|
||||||
|
that will return a list of available operations usable by the user.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
---------
|
||||||
|
|
||||||
|
As an user, I want to know what policies I am passing, so I can know what
|
||||||
|
actions are available to me.
|
||||||
|
|
||||||
|
As an user, I want to know what policies I am passing for a certain target (
|
||||||
|
e.g.: instance), so I can know what actions I can take.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
The proposed change takes two phases. The first phase, detailed in this spec,
|
||||||
|
implements the necessary plumbing to prove out the concept providing raw data
|
||||||
|
though a nova CLI command.
|
||||||
|
The second phase, described in brief below, will transform the raw data
|
||||||
|
into a long-term viable form presented in a new microversion of the
|
||||||
|
API.
|
||||||
|
|
||||||
|
Phase one
|
||||||
|
---------
|
||||||
|
|
||||||
|
The discoverable policy will be exposed through the ``nova-policy-check``
|
||||||
|
nova CLI command.
|
||||||
|
|
||||||
|
This command will require user authentication. The authentication options will
|
||||||
|
be the same as python-novaclient, they can be passed in as arguments, or they
|
||||||
|
will be loaded from the environment.
|
||||||
|
|
||||||
|
The command will return a list of policy rule names to the requesting user.
|
||||||
|
It will not return the authorization conditions required to pass the policy
|
||||||
|
rules. It cannot be used to determine the list of policy rules passed by
|
||||||
|
other users.
|
||||||
|
|
||||||
|
The returned operations will have to fulfill the following criteria:
|
||||||
|
|
||||||
|
* The requesting user will pass the operation's policy rule. For example, if
|
||||||
|
the policy states that the operation ``foo-bar`` is only usable by an admin,
|
||||||
|
the operation will be returned only if the requesting user is an admin.
|
||||||
|
|
||||||
|
* The API endpoint will have to be marked as discoverable. By default, all
|
||||||
|
APIs are discoverable [1]. For example, having the following policy rule:
|
||||||
|
``os_compute_api:servers:discoverable": "is_admin:True`` means that the
|
||||||
|
``servers`` API and its operations is discoverable only by an admin and will
|
||||||
|
not be returned to any other users.
|
||||||
|
|
||||||
|
This will allow testing of all the moving parts, notably user permissions.
|
||||||
|
|
||||||
|
Phase two
|
||||||
|
---------
|
||||||
|
|
||||||
|
Once phase one has been released, phase two can begin. In phase two
|
||||||
|
the raw data will be transformed into a format that does not expose
|
||||||
|
the internal details of the server's implementation of policy. For
|
||||||
|
example, clients don't want to know the name of actions, they want
|
||||||
|
to know the URI.
|
||||||
|
|
||||||
|
Once this long term format has been decided and implemented, the
|
||||||
|
API can then be documented, exposed by default (by changing the
|
||||||
|
default of the above configuration item) and associated with a
|
||||||
|
microversion bump.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
An alternative would be to combine phases one and two into one unit
|
||||||
|
of work. There are two issues with this idea:
|
||||||
|
|
||||||
|
* Without the break into two phases, the learning from the concrete
|
||||||
|
experience of phase one could not be effectively incorporated into
|
||||||
|
the work.
|
||||||
|
* Doing all the work in one push will be challenging to complete in
|
||||||
|
a reasonable amount of time, lengthening the time before concrete
|
||||||
|
learning can be had from real deployments.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
The nova ``nova-policy-check`` CLI command will require authentication. The
|
||||||
|
authentication options will be the same as python-novaclient and they can be
|
||||||
|
passed in as arguments or loaded from the environment. An exception will be
|
||||||
|
raised if there are no credentials present or they are wrong.
|
||||||
|
|
||||||
|
The command will return as follows, depending on the arguments given:
|
||||||
|
|
||||||
|
* No args. The command will check the default policy rules and will return all
|
||||||
|
passing policy rule names.
|
||||||
|
* ``config-file``. The command loads the given ``nova.conf`` configuration
|
||||||
|
file and its associated policy file, if any, overriding the default policy
|
||||||
|
rules. The command will return all passing policy rule names. For example::
|
||||||
|
|
||||||
|
nova policy-check --config-file /path/to/nova.conf
|
||||||
|
|
||||||
|
If the file was not found, couldn't be read, or couldn't be parsed, an error
|
||||||
|
will be raised.
|
||||||
|
|
||||||
|
* ``api-name`` argument given. The command will only list passing policy rules
|
||||||
|
containing the given API name. For example::
|
||||||
|
|
||||||
|
nova-policy-check --api-name os-keypairs
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
nova-policy-check --api-name os-keyp
|
||||||
|
|
||||||
|
This command will only list the passing policies for ``os-keypairs``::
|
||||||
|
|
||||||
|
"os_compute_api:os-keypairs:discoverable": "@"
|
||||||
|
"os_compute_api:os-keypairs": "rule:admin_or_owner"
|
||||||
|
"os_compute_api:os-keypairs:index": "rule:admin_api or user_id:%(user_id)s"
|
||||||
|
"os_compute_api:os-keypairs:show": "rule:admin_api or user_id:%(user_id)s"
|
||||||
|
"os_compute_api:os-keypairs:create": "rule:admin_api or user_id:%(user_id)s"
|
||||||
|
"os_compute_api:os-keypairs:delete": "rule:admin_api or user_id:%(user_id)s"
|
||||||
|
|
||||||
|
* ``target`` arguments given. The command will only list passing policies for
|
||||||
|
the given targets. For example::
|
||||||
|
|
||||||
|
nova-policy-check --target instance:<instance_uuid>
|
||||||
|
|
||||||
|
This command will list the passing policies for the given target::
|
||||||
|
|
||||||
|
"os_compute_api:servers:create"
|
||||||
|
"os_compute_api:servers:create:attach_network"
|
||||||
|
...
|
||||||
|
"os_compute_api:os-admin-actions"
|
||||||
|
"os_compute_api:os-admin-actions:reset_network"
|
||||||
|
|
||||||
|
If there is no instance with the given ``instance_uuid``, the command will
|
||||||
|
raise an error.
|
||||||
|
|
||||||
|
Multiple ``target`` arguments can be used::
|
||||||
|
|
||||||
|
nova-policy-check --target project_id:<project_id> --target user_id:<uid>
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignees:
|
||||||
|
Claudiu Belu <cbelu@cloudbasesolutions.com>
|
||||||
|
Andrew Laski <andrew@lascii.com>
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* ``nova-policy-check`` CLI command.
|
||||||
|
|
||||||
|
Phase two will be specified in a separate spec that will be created
|
||||||
|
in response to what is learned from implementation phase one.
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
Embed policy defaults in code:
|
||||||
|
https://review.openstack.org/#/c/290155/
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
* Unit & functional tests.
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
New nova CLI command will have to be documented.
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
[1] Default "discoverable" policies to "@"
|
||||||
|
https://review.openstack.org/#/c/281911/1
|
||||||
|
|
||||||
|
[2] Nova API meeting
|
||||||
|
http://eavesdrop.openstack.org/meetings/nova_api/2016/nova_api.2016-04-13-13.00.log.html
|
||||||
|
|
||||||
|
[3] Newton Design Summit
|
||||||
|
https://etherpad.openstack.org/p/newton-nova-api
|
||||||
|
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
.. list-table:: Revisions
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* - Release Name
|
||||||
|
- Description
|
||||||
|
* - Newton
|
||||||
|
- Introduced
|
||||||
Reference in New Issue
Block a user