Conditional exposure of resources based on user roles¶
Include the URL of your launchpad blueprint:
Expose resources as available based on actual user roles.
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.
Add optional settings in
[clients] section to be used for every client or in
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.
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.
- Primary assignee:
Pavlo Shchelokovskyy <pshchelo>
- Target Milestone for completion:
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
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
blueprint keystone-based-resource-availability is implemented
admin-requiring resources are moved in-tree from contrib/