On 08/27/2014 12:15 PM, Kurt Griffiths wrote: > On 8/25/14, 9:50 AM, "Ryan Brown" <rybr...@redhat.com> wrote: > >> I'm actually quite partial to roles because, in my experience, service >> accounts rarely have their credentials rotated more than once per eon. >> Having the ability to let instances grab tokens would certainly help >> Heat, especially if we start using Zaqar (the artist formerly known as >> marconi). >> > > According to AWS docs, IAM Roles allow you to "Define which API actions > and resources the application can use after assuming the role.” What would
Optimally, you'd be able to (as a user) generate tokens with subsets of your permissions (e.g. if you're admin, you can create non-admin tokens/tempurls). It seems like implementing this seems (from where I'm sitting) like it would take lots of help from the Keystone team. > it take to implement this in OpenStack? Currently, Keystone roles seem to > be more oriented toward cloud operators, not end users. This quote from > the Keystone docs[1] is telling: > > If you wish to restrict users from performing operations in, say, > the Compute service, you need to create a role in the Identity > Service and then modify /etc/nova/policy.json so that this role is > required for Compute operations. I wasn't aware that this was how role permissions worked. Thank you for including that info. > > On 8/25/14, 9:49 AM, "Zane Bitter" <zbit...@redhat.com> wrote: > >> In particular, even if a service like Zaqar or Heat implements their own >> authorisation (e.g. the user creating a Zaqar queue supplies lists of >> the accounts that are allowed to read or write to it, respectively), how >> does the user ensure that the service accounts they create will not have >> access to other OpenStack APIs? IIRC the default policy.json files >> supplied by the various projects allow non-admin operations from any >> account with a role in the project. >> > > It seems like end users need to be able to define custom roles and > policies. > > Some example use cases for the sake of discussion: > > 1. App developer sends a request to Zaqar to create a queue named > “customer-orders" > 2. Zaqar creates a queue named "customer-orders" > 3. App developer sends a request to Keystone to create a role, "role-x", > for App Component X > 4. Keystone creates role-x > 5. App developer sends requests to Keystone to create a service user, > “user-x” and associate it with role-x > 6. Keystone creates user-x and gives it role-x > 7. App developer sends a request to Zaqar to create a policy, > “customer-orders-observer”, and associate that policy with role-x. The > policy only allows GETing (listing) messages from the customer-orders > queue > 8. Zaqar creates customer-orders-observer and notes that it is associated > with role-x > > Later on... > > 1. App Component X sends a request to Zaqar, including an auth token > 2. Zaqar sends a request to Keystone asking for roles associated with the > given token > 3. Keystone returns one or more roles, including role-x > 4. Zaqar checks for any user-defined policies associated with the roles, > including role-x, and finds customer-orders-observer > 5. Zaqar verifies that the requested operation is allowed according to > customer-orders-observer > > We should also compare and contrast this with signed URLs ala Swift’s > tempurl. For example, service accounts do not have to be created or > managed in the case of tempurl. Perhaps there would be a way to have a more generic (Keystone-wide) version of similar functionality. Even if there wasn't any scoping support it would still be exceptionally useful. This is starting to sound like it's worth drafting a blueprint for, or at least looking through existing BP's to see if there's something that fits. > > --Kurt > > [1]: http://goo.gl/5UBMwR [http://docs.openstack.org] > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev