[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