Open Stack

Thanks Henry and Dolph - I think I understand how it could all
fit together now.

Regards,

Chris


On Tue, Oct 1, 2013 at 4:17 PM, Henry Nash <henryn at linux.vnet.ibm.com>wrote:

> I think an obvious first step of domain support outside keystone is for
> images.  Today, I believe, an image can be global or project based.  There
> is definitely a use case for a third state of being domain based - and
> hence available to all projects in that domain, but not to those in other
> domains.
>
> From a Nova perspective, where domains might be relevant is in how a cloud
> provider divides up their infrastructure, for example, I think there are
> use cases for when a cloud provider might want to specify on a domain-basis:
> - availability zones and/or host aggregates
> - quotas
> - IP ranges (ok, maybe a quantum discussion)
>
> Henry
> On 1 Oct 2013, at 06:45, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>
>
> On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh <cbkyeoh at gmail.com>wrote:
>
>> Hi,
>>
>> I've been looking into how Nova might support Keystone V3 domains and I'm
>> having a bit of trouble getting my head around exactly how we'd use domain
>> scoped tokens.
>>
>> With the V3 Nova API we no longer specify the tenant id in the url as it
>> is implicit in the token used to authorize with. This is true for Keystone
>> V3  tenant scoped tokens, but not for domain scoped tokens.  If we're going
>> to use domain scoped tokens with the Nova API is the idea that a client
>> would pass the tenant id in a header as well as the domain scoped token and
>> Nova would check that the tenant passed belongs to the domain that is
>> implicit with the token?
>>
>
> Without a specific use case to support domain-based operations, I'd be
> opposed to handling this scenario "implicitly." I have yet to hear a use
> case for domain awareness in nova, so I'd expect nova to return a 401 for
> any domain-based token.
>
>
>>
>> Also, should we be updating the Nova policy code to be able to handle
>> domains?
>>
>
> Keystone supports domain-based authorization on two levels:
> domain-specific role assignments and domain-specific role assignments that
> are inherited to all projects/tenants owned by that domain.
>
> With inheritance, a domain administrator can request authorization on any
> project in the domain (from keystone, per usual) and nova's policy doesn't
> have to handle anything special (it'll just be a regular project/tenant
> scoped token).
>
>
>>
>>
>
>> Regards,
>>
>> Chris
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> -Dolph
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131002/52e19e6b/attachment.html>