Open Stack

I left a comment for you on the blueprint.  I would love to see a more
explicit definition on the tokens we're proposing do we have a blueprint
for that?

On Tue, Dec 11, 2012 at 11:52 AM, Adam Young <ayoung at redhat.com> wrote:

>  On 12/11/2012 01:53 PM, Matt Joyce wrote:
>
> I think there is a question as to the nature of what is a fully qualified
> cloud instance.
>
> In physical hosting land it was easy enough.  Right IP, right DNS forwards
> and reverse, and occasionally some form of signing on top of that.
>
> With cloud there is a fundamentally different environment that promotes
> new needs.
>
> Basically, from my perspective this ties into a basic need.  How can a
> service token or user token know that it is executing from the instance or
> tenant it was intended to fire from.  Right now it's simple, we don't care
> if it is or isn't.  But, we won't survive long before we need to address
> this.
>
> The question becomes, how are we going to sign the tokens that we create
> so as to exist as part of a tenant?  or specific to an instance?  and how
> will we be sure that those tokens are not going beyond those boundaries.
>
> Tickets are going to be signed by Keystone.  The user needs to be able to
> authenticate to Keystone to get the ticket. We can limit access to
> keystone.  But the requests come through via HTTP and we don't have
> SPNEGO/GSSAPI.  If we want to limit access to a host, it would have to be
> based on the ipaddress of the requestor, which is in the HTTP payload.  I
> think that would need the full ABAC implementation to enforce.
>
>
>
> This I think is important to at least think about before moving forward.
> We're talking about things such as service ticket equivalents, and those
> have traditionally required FQDNs for a reason.  But in this modern age, an
> FQDN is no longer going to service our needs.  More to the point, how will
> we be able to export service tickets then outside of our cloud
> environment?
>
> THe delegation Blueprint starts to address this. I would appreciate
> getting a review of it, and hearing your feedback:
>
> http://wiki.openstack.org/keystone/Delegation
>
>
>
>
>
> -Matt
>
> On Tue, Dec 11, 2012 at 7:01 AM, Adam Young <ayoung at redhat.com> wrote:
>
>> On 12/11/2012 08:06 AM, David Chadwick wrote:
>>
>>> 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?
>>>
>>
>>  David, if I understand what he is asking, he only wants Nova to be able
>> to upload the images; a user can't upload any old image, just the ones
>> somehow gated by Nova.   But the image should still be owned by the user
>> that triggered the upload.Its an interesting use case, but not something we
>> would be able to support in the Grizzly time frame, and not something that
>> I would put under explicit impersonation, but rather something of the
>> nature of policy enforcement.  They might be able to do it built on trusts
>> if they had a policy that requires the token have the additional value of
>> "trustee=nova"
>>
>>
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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 listOpenStack-dev at lists.openstack.orghttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121211/d8a2268b/attachment.html>