[openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone
Ryan Brown
rybrown at redhat.com
Wed Aug 27 17:15:52 UTC 2014
On 08/27/2014 12:15 PM, Kurt Griffiths wrote:
> On 8/25/14, 9:50 AM, "Ryan Brown" <rybrown at 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" <zbitter at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
More information about the OpenStack-dev
mailing list