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 <[email protected]> wrote: > > On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > -Dolph > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
