Open Stack

On 27/08/14 12:15, 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
> 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.

The terminology is somewhat confusing, because roles are entirely 
different things in OpenStack. In AWS a Role is a type of account that 
is locked to a single EC2 server that is automatically supplied with 
rotating tokens. In Keystone, a role is a group membership within a project.

What you're hitting on is that Keystone has been primarily an Identity 
service concerned only with Authentication and not Authorisation. The 
limited Authorisation that does exist is concerned with checking roles 
assigned by the operator against the policy.json file also provided by 
the operator. In practice, it's mostly at the granularity of locking 
down individual URL endpoints to be admin-only (where admin means the 
cloud operator).

What will be increasingly needed is what you describe below; a way for 
users to assign roles or something similar to accounts, along with 
fine-grained permissions for operations on individual resources. Right 
now afaik the best you can do is to roll your own within each OpenStack 
project, which is unfortunate - but much worse is that there's no way to 
communicate to other project APIs that particular accounts should be 
locked down.

cheers,
Zane.

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