Open Stack

On 12/04/2012 06:04 AM, David Chadwick wrote:
> Hi Gabriel
>
> you make some good points
>
> On 03/12/2012 22:41, Gabriel Hurley wrote:
>> Good to know re: the ports. Still curious if there's any thought to
>> capabilities that might be allowed via expanded RBAC permissions for
>> an "administrative user"...
>
> This should certainly be allowed, and could be via an admin port 
> rather than a user port.
>
>  specifically when it comes to the
>> sections about the trustor ID always being the user making the POST
>
> this also needs refining when recursive delegation is implemented, 
> since the original trustee becomes the trustor in the second delegation.
>
>> and that "Only the trustor or trustee will be able to access this
>> URL. Any other user will get a 403 (Forbidden)." A few possible
>> things an administrator might think to do are to "clean up" trusts if
>> they get out-of-whack somehow, or to try and audit/understand the
>> trusts in the system.
>
> there needs to be a housekeeping routine which regulary disposes of 
> expired (and unrevoked) trusts. This might run periodically or also be 
> kicked off by an administrator.

Agreed, although we have to be aware of audit requirements.  I think we 
need to start and audit blueprint, to track this and related topics.

>
> David
>
>  Maybe these aren't the kinds of use cases we
>> want to allow, but if not I think we need to be more explicit about
>> it and offer reasons why not.
>>
>> - Gabriel
>>
>>> -----Original Message----- From: heckj [mailto:heckj at mac.com] Sent:
>>> Monday, December 03, 2012 1:26 PM To: OpenStack Development Mailing
>>> List Subject: Re: [openstack-dev] [Keystone] Trust Specification
>>> Updated
>>>
>>> Trusts are getting built on the V3 API, which will run equally on
>>> both ports using RBAC as it's means to control access, as opposed
>>> to the V2 mechanism that required the separate ports for
>>> administrative vs. expected-user-access controls.
>>>
>>> We'll be keeping both ports active in the codebase until we've
>>> fully deprecated the V2 APIs, but with the V3 APIs, only a single
>>> port will be needed (pretty much like all the other OpenStack
>>> projects)
>>>
>>> -joe
>>>
>>> On Dec 3, 2012, at 12:40 PM, Gabriel Hurley
>>> <gabriel.hurley at nebula.com> wrote:
>>>> Generally looks really good... one question though, sparked by
>>>> the
>>> sentence "The trustor ID is implied from the creating users ID."
>>> Nowhere in that document does it describe the breakdown between the
>>> standard interface (port 5000) vs. the administrative interface
>>> (port 35357). What capabilities (or lack thereof) does a user with
>>> administrative access have in this system, and can we make that
>>> more explicit?
>>>>
>>>> Thanks,
>>>>
>>>> - Gabriel
>>>>
>>>>> -----Original Message----- From: Adam Young
>>>>> [mailto:ayoung at redhat.com] Sent: Monday, December 03, 2012 8:35
>>>>> AM To: OpenStack Development Mailing List Subject:
>>>>> [openstack-dev] [Keystone] Trust Specification Updated
>>>>>
>>>>> I realize we have had a little bit of disagreement on what to
>>>>> call this.  I am going to continue to call it "Trusts" as it is
>>>>> a subset of the set of mechanisms for delegation.
>>>>>
>>>>> I've wikified the Specification.  Big thanks to David Chatwick
>>>>> for making this a much better spec.
>>>>>
>>>>> http://wiki.openstack.org/Keystone/Trusts
>>>>>
>>>>> Blueprint is still at
>>>>>
>>>>> https://blueprints.launchpad.net/keystone/+spec/trusts
>>>>>
>>>>>
>>>>> I will continue to work on this, to include, for example, how
>>>>> to specifiy duration and start times, but there should be
>>>>> enough here for people to understand.
>>>>>
>>>>> My initial write up:
>>>>>
>>>>> http://adam.younglogic.com/2012/10/preauthorization-in-keystone/
>>>>>
>>>>>
>>>>>
> _______________________________________________
>>>>> 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