[openstack-dev] Trusts and Explicit Impersonation

Bhandaru, Malini K malini.k.bhandaru at intel.com
Sat Dec 8 08:51:14 UTC 2012


Mark, this notion of impersonation with different levels of privileges (higher, lower, different functions)  is also encountered in customer service.
For example, you can view your credit card details and line items, but your credit card customer rep (phone or online chat/email)
Can see only your line items, to help with a dispute and grant a refund (in this case privileges and an additional privilege).

If we have more such use cases, I can see a tenant seeking assistance with the cloud provider for issues with their VMs and charges, and not
Needing to build an additional authentication/support infrastructure for the same.

Regards
Malini

From: Mark Washenberger [mailto:mark.washenberger at markwash.net]
Sent: Friday, December 07, 2012 8:53 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Trusts and Explicit Impersonation

Hi auth guys!

As we continue to make progress towards large service providers exposing their Glance deployments as public services, one critical feature we need to support is the ability to limit certain actions (mostly image uploads, also possibly image downloads) to use by Nova or other trusted services, and restrict users from taking those actions directly. Of course, this feature would only be turned on by configuration, and not likely by default.

I had figured we could do this using some features piggy-backed on keystone pki, and documented the use case in this blueprint: https://blueprints.launchpad.net/keystone/+spec/keystone-explicit-impersonation

I've been following the discussion of Keystone Trusts with interest, and some questions have presented themselves. Is there some way we could manipulate the Trust mechanism to provide the auth feature Glance needs? Another (scarier for me) question: does the Trusts proposal conflict with my feature request?

Thanks!
Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121208/2951483c/attachment-0001.html>


More information about the OpenStack-dev mailing list