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 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.
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.