Excerpts from Adrian Turjak's message of 2017-05-18 13:34:56 +1200: > Fully agree that expecting users of a particular cloud to understand how > the policy stuff works is pointless, but it does fall on the cloud > provider to educate and document their roles and the permissions of > those roles. I think step 1 plus some basic role permissions for the
Doesn't basing the API key permissions directly on roles also imply that the cloud provider has to anticipate all of the possible ways API keys might be used so they can then set up those roles? > Keys with the expectation of operators to document their roles/policy is > a safe enough place to start, and for us to document and set some > sensible default roles and policy. I don't think we currently have good This seems like an area where we want to encourage interoperability. Policy doesn't do that today, because deployers can use arbitrary names for roles and set permissions in those roles in any way they want. That's fine for human users, but doesn't work for enabling automation. If the sets of roles and permissions are different in every cloud, how would anyone write a key allocation script that could provision a key for their application on more than one cloud? Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev