Open Stack

Hi Mark

I am finding it difficult to understand your use case. Can you help me 
please. If Nova is the compute service, then surely it is able to upload 
any images that it wants to, otherwise how can they run? Isnt it the 
case that Nova is the service provider, which has a policy that says who 
is entitled to upload images to it? Someone, say the deployer, sets this 
policy. So say the policy is "role X can upload images", then any user 
who can authenticate to Keystone and be assigned role X is able to 
upload images. Doesnt this provide the functionality you need?

regards

David


On 10/12/2012 21:12, Mark Washenberger wrote:
>>> I must be missing something. Thanks in advance for correcting me!
>>
>> Why would the user not have the role?
>
> The idea behind this feature is that the user is not authorized to
> upload an image, but Nova is authorized to upload an image on the
> user's behalf. This feature would not be turned on by default, but it
> should be available at a deployer's discretion.
>
> On Mon, Dec 10, 2012 at 12:14 PM, Adam Young <ayoung at redhat.com> wrote:
>> On 12/10/2012 02:41 PM, Mark Washenberger wrote:
>>>
>>> So, in the case of this feature, the trustor (end user) is going to
>>> delegate to the trustee (Glance) a role that the trustor himself does
>>> not have? (Namely, some role that allows image uploads.) That seems to
>>> violate the spirit of the the spec.
>>
>> Nope.  The user needs to have the role in the first place.
>>
>>> I must be missing something. Thanks in advance for correcting me!
>>
>> Why would the user not have the role?
>>
>>>
>>> markwash
>>>
>>> On Mon, Dec 10, 2012 at 10:56 AM, Yee, Guang <guang.yee at hp.com> wrote:
>>>>
>>>> I think the current trust BP should cover your use case.
>>>>
>>>> http://wiki.openstack.org/Keystone/Trusts
>>>>
>>>> In your case, the trustee would be Image Service or endpoint.
>>>>
>>>>
>>>> Guang
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Mark Washenberger [mailto:mark.washenberger at markwash.net]
>>>> Sent: Monday, December 10, 2012 10:36 AM
>>>> To: OpenStack Development Mailing List
>>>> Subject: Re: [openstack-dev] [Keystone] Trusts and Explicit Impersonation
>>>>
>>>> David, Adam, (other Trusts/Auth folks. . .),
>>>>
>>>> Any thoughts on this?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>>> 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-impersonat
>>>> ion
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>