Open Stack

Hi Malini,

That is an interesting use case. It is sort of like Trusts, in that the
customer rep has a diminished form of the users privileges (can't see
credit card details), but has some additional privileges the user wouldn't
have. Since the customer rep use case involves a third person interacting
with the system, it seems like the right way to provide this feature would
be to define a role for the privileges you want (can see line items, can't
see financial info, can give refund) and give that role to the customer
representative for the user's tenant.

However, in the explicit impersonation case, I'm hesitant to just give Nova
a role on every tenant that allows it to download and upload images. If a
bug in Nova somehow allowed a user in tenant1 to trigger these actions for
tenant2, that would represent a means of attack. Ideally, Glance would
authenticate a request and authorize an action based on both the identity
of the proximate user (Nova) and the ultimate user (a customer who triggers
a nova build/snapshot). That would provide more protection.

-Mark


On Sat, Dec 8, 2012 at 12:51 AM, Bhandaru, Malini K <
malini.k.bhandaru at intel.com> wrote:

>  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****
>
> ** **
>
> ** **
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121208/007fe989/attachment.html>