On 27/08/14 12:15, 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
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" <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.
--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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
