On Tue, Oct 1, 2013 at 1:17 AM, Henry Nash <hen...@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 > /me facepalm I can't believe I forgot about these. I take back the "yet to hear"! > - IP ranges (ok, maybe a quantum discussion) > > Henry > On 1 Oct 2013, at 06:45, Dolph Mathews <dolph.math...@gmail.com> wrote: > > > On Mon, Sep 30, 2013 at 11:42 PM, Christopher Yeoh <cbky...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > > -Dolph > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev