Open Stack

Tiwari,

Could you elaborate how to solve the issue by using unique role names ?
With domain model, services like nova have to be aware of domain admin user
and cloud admin user by roles.  domain admin
manage IAM resources and non-IAM resources by inheriting  roles to
projects, cloud admin have additional privilege to enable/disable
OpenStack services. But the "admin" role can be granted by a domain user to
its own  user. How nova api identity a user is real admin
 user that in admin domain?


2014-05-10 2:23 GMT+08:00 Tiwari, Arvind <arvind.tiwari at hp.com>:

>  Hi All,
>
>
>
> Thanks for looking in to my proposal. Below are my comments and answers to
> questions which is based on “my personal opinion”.
>
>
>
> *Why domain hierarchy, why not project hierarchy? *Because project
> hierarchy is more impactful and need cross project changes.
>
>
>
> As per my understanding we all are trying to solve one business use
> problem, which is “how to support VPC or Reseller” model on OS based cloud
> deployment.  As per problem described in different proposals, it is purely
> a IAM use case, where different identities (users, admins, reseller ….) has
> different perception about the system/resources (IAM and non IAM) and they
> want ability to manage them.
>
>
>
> Keystone (OS IAM service) abstracts all the IAM complexity  from lower
> level services (Nova, Swift, cinder …) by providing unified integration
> model (auth token and verification by auth middleware). Lover level
> services trusts Keystone and allow access (for particular requests) to
> actual resource based on subject’s roles provided by keystone.
>
>
>
> Each service supports multi tenancy and tenancy mapping is establish by
> keystone through projects.  If hierarchy enforced at project level then we
> need to propagate the hierarchy info to all lower level services, where the
> hierarchy  info is not serving any good purpose but just used to map one
> tenant. Enforcing the hierarchy at project level is more impactful because
> all services have to change their implementation to consume the notion of
> hierarchy. Propagating project hierarchy to services would make sense if
> end resources (VMs, cinder volumes , swift resource ….) does obey the
> hierarchy based on projects, I think that is not the case.
>
>
>
> As per definition domains are container for projects, users and groups and
> maps well with a business entities (ProductionIT, SuperDevShop,
> WidgetMaster, SPI, reseller .....). Using domain to establish hierarchy (as
> per my design) will abstract the complexity from lower level services.
> Services don’t have to worry about the domain hierarchy and we can retain
> the current integration (Keystone project <-> service Tenant ) model and no
> need to make big change in different service. Mostly one place change which
> is Keystone.
>
>
>
> *Services has to be domain aware*
>
>
>
> IMO services (Nova, Swift …) don’t have to be domain aware (Unless I am
> missing something) as they manage resources for keystone projects. Domain
> is IAM concept which used to scope IAM resources and not very useful for
> end services. I think what we are lacking is unique role (role name) per
> service, having unique role names for each service (IAM, Nova, Swift ….)
>  will resolve the problem mentioned below by  Yaguang Tang.
>
>
>
> Please let me know why services have to be domain aware?
>
>
>
> Thoughts?
>
>
>
> Thanks,
>
> Arvind
>
>
>
> Note:
>
> IAM Resources – Users, groups, projects …
>
> Non IAM resources – VMs, Swift objects, …….
>
>
>
> *From:* Yaguang Tang [mailto:yaguang.tang at canonical.com]
> *Sent:* Friday, May 09, 2014 4:33 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] Hierarchical administrative boundary
> [keystone]
>
>
>
> *Frittoli,*
>
>
>
> I think for other services we could achieve that by  modifying  the
> policy.json( add domain admin role and control what the cloud admin can do
> ) so that domain admin user is able to manage resources belong to
>
> users and projects in that domain.
>
>
>
> 2014-05-09 15:24 GMT+08:00 Frittoli, Andrea (HP Cloud) <frittoli at hp.com>:
>
> *From:* Adam Young [mailto:ayoung at redhat.com]
> *Sent:* 09 May 2014 04:19
> *To:* openstack-dev at lists.openstack.org
> *Subject:* Re: [openstack-dev] Hierarchical administrative boundary
> [keystone]
>
>
>
> On 05/08/2014 07:55 PM, Tiwari, Arvind wrote:
>
>  Hi All,
>
>
>
> Below is my proposal to address VPC use case using hierarchical
> administrative boundary. This topic is scheduled in Hierarchical
> Multitenancy<http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9>session of Atlanta design summit.
>
>
>
> https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary
>
>
>
> Please take a look.
>
>
>
> Thanks,
>
> Arvind
>
>
>
>
>
>  _______________________________________________
>
> OpenStack-dev mailing list
>
>
>
> OpenStack-dev at lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>  Looks very good.  One question:  Why hierarchical domains and not
> Projects.  I'm not disagreeing, mind you, just that I think the Nova team
> is going for hierarchical Projects.
>
>
>  * ------------------------------ *
>
> Looks good, thank you!
>
>
>
> But for this to be even more interesting nova (and other services) should
> be domain aware – e.g. so that a domain admin could have control on all
> resources which belong to users and projects in that domain.
>
>
>
> andrea
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Tang Yaguang
>
>
>
> Canonical Ltd. | www.ubuntu.com | www.canonical.com
>
> Mobile:  +86 152 1094 6968
>
> gpg key: 0x187F664F
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Tang Yaguang

Canonical Ltd. | www.ubuntu.com | www.canonical.com
Mobile:  +86 152 1094 6968
gpg key: 0x187F664F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140513/44dff822/attachment.html>