Conditionally expose resources based on roles
Use actual user roles to filter out from `resource-type-list` those resources that current user can not create due to RBAC restrictions. Specifies blueprint conditional-resource-exposure Change-Id: Ic13c51ef04e8d6d740a46d9554267ada9d9c78d2
This commit is contained in:
parent
36d3ec22a9
commit
ad611ee6f2
94
specs/liberty/conditional-resource-exposure-roles.rst
Normal file
94
specs/liberty/conditional-resource-exposure-roles.rst
Normal file
@ -0,0 +1,94 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=====================================================
|
||||
Conditional exposure of resources based on user roles
|
||||
=====================================================
|
||||
|
||||
Include the URL of your launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/heat/+spec/conditional-resource-exposure
|
||||
|
||||
Expose resources as available based on actual user roles.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Currently we unconditionally register and present to the user all resource
|
||||
plugins that we have in-tree.
|
||||
As we will move in-tree some contrib/ resources that require special roles
|
||||
for instantiation (e.g. Keystone resources) all users will see them
|
||||
as available despite that the user might not actually be able to use them
|
||||
due to RBAC restrictions.
|
||||
This would be confusing to users and facilitate later stack failure
|
||||
at creation instead of failing early at validation.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Add optional settings in ``heat.conf``
|
||||
(in ``[clients]`` section to be used for every client or in ``[client_*]``
|
||||
section for a specific client) specifying the list of required "special"
|
||||
roles to instantiate restricted resources of this service.
|
||||
|
||||
Use these values during validation to compare the roles with the roles from
|
||||
the context to check for resource availability for the specific user who has
|
||||
made the request.
|
||||
|
||||
Default value (empty list) of the new config option will mean
|
||||
show the resource as available to any user.
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Keep the things as they are continuing to confuse users and fail later than
|
||||
earlier for templates with resources that current user can not create without
|
||||
having special roles.
|
||||
|
||||
Long term alternative / improvement would be to wait until Keystone implements
|
||||
fine grained policy control and querying as part of API.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Pavlo Shchelokovskyy <pshchelo>
|
||||
|
||||
Milestones
|
||||
----------
|
||||
|
||||
Target Milestone for completion:
|
||||
liberty-1
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
- add config options for client plugins describing the required special
|
||||
roles list
|
||||
- add an attribute to resources requiring special roles that marks them as such
|
||||
- add an extra parameter to SupportStatus hinting that this resource will
|
||||
likely require a special role a common user would not generally have
|
||||
|
||||
- modify docs generation to flag such resources
|
||||
|
||||
- add validation step comparing the options from config with roles from context
|
||||
- unit tests
|
||||
- functional tests
|
||||
|
||||
- modify DevStack to automatically configure Heat with DevStack's default
|
||||
policies in respect to special roles for new Keystone client options
|
||||
- check if Keystone resources are listed if called from non-admin users
|
||||
- check that template containing Keystone resources is failing validation
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
- blueprint keystone-based-resource-availability is implemented
|
||||
- admin-requiring resources are moved in-tree from contrib/
|
Loading…
Reference in New Issue
Block a user