Open Stack

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.

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]