Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Hi Huang, Thanks for looking in to my proposal. Yes, Alliance is will be utilizing/retain all Northbound service APIs, in addition it will expose APIs for inter Alliance (inter cloud) communication. Alliance will be running at topmost layer on each individual OpenStack Cloud of multi-site distributed cloud setup. Additionally Alliance will provide loosely coupled integration among multiple clouds or cloudyfied data center. In case of multi regions setup “regional Alliance” (RA) will orchestrate the resource (project, VMs, volumes, network ….) provisioning and state synchronization through its peers RA. In case cross enterprise integration (Enterprise/VPC/bursting like scenario) - multi site public cloud) “global Alliance” (GA) will be interface for external integration point and communicating with individual RAs. I will update the wiki to make it more clear. I will love to coordinate with your team and solve this issue together, I will be reaching there in Paris on 1 Nov and we can site f2f before session. Let’s plan a time to meet, Monday will be easy for me. Thanks, Arvind From: joehuang [mailto:joehu...@huawei.com] Sent: Wednesday, October 01, 2014 5:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi, Tiwari, Great to know you are also trying to address similar issues. For sure we are happy to work out a common solution for these issues. I just go through the wiki page, the question for me is will the Alliance provide/retain current north bound OpenStack API ?. It's very important for the cloud still expose OpenStack API so that the OpenStack API ecosystem will not be lost. And currently OpenStack cascading has not covered the hybrid cloud (private cloud and public cloud federation), so your project will be a good supplement. May we have a f2f workshop before the formal Paris design summit, so that we can exchange ideas completely. 40 minutes design summit session is not enough for deep diving. PoC team will stay at Paris from Oct.29 to Nov.8. Best Regards Chaoyi Huang ( joehuang ) From: Tiwari, Arvind [arvind.tiw...@hp.com] Sent: 02 October 2014 0:42 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi Chaoyi, Thanks for sharing these information. Sometime back I have stared a project called “Alliance” which trying to address the same concerns (see the link below). Alliance service is designed to provide Inter-Cloud Resource Federation which will enable resource sharing across cloud in distributed multi-site OpenStack clouds deployments. This service will run on top of OpenStack Cloud and fabricate different cloud (or data centers) instances in distributed cloud setup. This service will work closely with OpenStack components (Keystone, Nova, Cinder) to manage and provision different resources (token, VM, images, network .). Alliance service will provide abstraction to hide interoperability and integration complexities from underpinning cloud instance and enable following business use cases. - Multi Region Capability - Virtual Private Cloud - Cloud Bursting This service will provide true plug play model for region expansion, VPC like use case, conceptual design can be found at https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation. We are working on POC using this concept which is in WIP. I will be happy to coordinate with you on this and try to come up with common solution, seems we both are trying to address same issues. Thoughts? Thanks, Arvind From: joehuang [mailto:joehu...@huawei.com] Sent: Wednesday, October 01, 2014 6:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hello, Alex, Thank you very much for your mail about remote cluster hypervisor. One of the inspiration for OpenStack cascading is from the remote clustered hypervisor like vCenter. The difference between the remote clustered hypervisor and OpenStack cascading is that not only Nova involved in the cascading, but also Cinder, Neutron, Ceilometer, and even Glance(optional). Please refer to https://wiki.openstack.org/wiki/OpenStack_cascading_solution#Inspiration, https://wiki.openstack.org/wiki/OpenStack_cascading_solution#Architecture for more detail information. Best Regards Chaoyi Huang ( joehuang ) From: Alex Glikson [glik...@il.ibm.com] Sent: 01 October 2014 12:51 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This sounds related to the discussion on the 'Nova clustered hypervisor driver' which started at Juno design summit [1
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Hi Chaoyi, Thanks for sharing these information. Sometime back I have stared a project called “Alliance” which trying to address the same concerns (see the link below). Alliance service is designed to provide Inter-Cloud Resource Federation which will enable resource sharing across cloud in distributed multi-site OpenStack clouds deployments. This service will run on top of OpenStack Cloud and fabricate different cloud (or data centers) instances in distributed cloud setup. This service will work closely with OpenStack components (Keystone, Nova, Cinder) to manage and provision different resources (token, VM, images, network .). Alliance service will provide abstraction to hide interoperability and integration complexities from underpinning cloud instance and enable following business use cases. - Multi Region Capability - Virtual Private Cloud - Cloud Bursting This service will provide true plug play model for region expansion, VPC like use case, conceptual design can be found at https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation. We are working on POC using this concept which is in WIP. I will be happy to coordinate with you on this and try to come up with common solution, seems we both are trying to address same issues. Thoughts? Thanks, Arvind From: joehuang [mailto:joehu...@huawei.com] Sent: Wednesday, October 01, 2014 6:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hello, Alex, Thank you very much for your mail about remote cluster hypervisor. One of the inspiration for OpenStack cascading is from the remote clustered hypervisor like vCenter. The difference between the remote clustered hypervisor and OpenStack cascading is that not only Nova involved in the cascading, but also Cinder, Neutron, Ceilometer, and even Glance(optional). Please refer to https://wiki.openstack.org/wiki/OpenStack_cascading_solution#Inspiration, https://wiki.openstack.org/wiki/OpenStack_cascading_solution#Architecture for more detail information. Best Regards Chaoyi Huang ( joehuang ) From: Alex Glikson [glik...@il.ibm.com] Sent: 01 October 2014 12:51 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This sounds related to the discussion on the 'Nova clustered hypervisor driver' which started at Juno design summit [1]. Talking to another OpenStack should be similar to talking to vCenter. The idea was that the Cells support could be refactored around this notion as well. Not sure whether there have been any active progress with this in Juno, though. Regards, Alex [1] http://junodesignsummit.sched.org/event/a0d38e1278182eb09f06e22457d94c0c#http://junodesignsummit.sched.org/event/a0d38e1278182eb09f06e22457d94c0c [2] https://etherpad.openstack.org/p/juno-nova-clustered-hypervisor-support From:joehuang joehu...@huawei.commailto:joehu...@huawei.com To:OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date:30/09/2014 04:08 PM Subject:[openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hello, Dear TC and all, Large cloud operators prefer to deploy multiple OpenStack instances(as different zones), rather than a single monolithic OpenStack instance because of these reasons: 1) Multiple data centers distributed geographically; 2) Multi-vendor business policy; 3) Server nodes scale up modularized from 00's up to million; 4) Fault and maintenance isolation between zones (only REST interface); At the same time, they also want to integrate these OpenStack instances into one cloud. Instead of proprietary orchestration layer, they want to use standard OpenStack framework for Northbound API compatibility with HEAT/Horizon or other 3rd ecosystem apps. We call this pattern as OpenStack Cascading, with proposal described by [1][2]. PoC live demo video can be found[3][4]. Nova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in the OpenStack cascading. Kindly ask for cross program design summit session to discuss OpenStack cascading and the contribution to Kilo. Kindly invite those who are interested in the OpenStack cascading to work together and contribute it to OpenStack. (I applied for “other projects” track [5], but it would be better to have a discussion as a formal cross program session, because many core programs are involved ) [1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution [2] PoC source code: https://github.com/stackforge/tricircle [3] Live demo video at YouTube: https://www.youtube.com/watch?v=OSU6PYRz5qY [4] Live demo video at Youku (low quality, for those who can't access
[openstack-dev] [barbican] Need opinion on bug 1347101
I have logged below bug to enforce 'content-type' check before RBAC enforcement on POST requests, but seems we have difference in opinion. https://bugs.launchpad.net/barbican/+bug/1347101 Please look at the above bug and share your thoughts. IMO - content-type enforcement is concern of REST subsystem (Pecan in this case) and RBAC is the applications concern. Application resides a level below REST subsystem, so these checks and response should also follow this notion. RBAC enforcement should be done only after all the necessary checks related REST aspect has been performed. This way we can save costly RBAC validation, at the same time returning a legitimate unauthorized response for a request with bad content type does not makes sense. Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Inter cloud resource federation [Alliance]
Hi Raildo, Yes, I am trying to separate out the resource federation concerns through Alliance, Identity federation will be intact with Keystone. At the same time Alliance will play as delegate for keystone wherever resource federation across clouds concern need to be addressed. I would love to work with you on this and anyone who is interested. I am putting together a POC and will keep you and community informed on the same. Thanks, Arvind From: Raildo Mascena [mailto:rail...@gmail.com] Sent: Wednesday, July 09, 2014 1:16 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Inter cloud resource federation [Alliance] Hi Arvind, First, I quite liked the idea and I am very interested in helping you with that. Second, I have some doubts. What is the similarity (and differences) with Keystone to Keystone blueprint? https://review.openstack.org/#/c/100023/https://blueprints.launchpad.net/keystone/+spec/keystone-to-keystone-federation The federation will be migrated to this new service? Regards, 2014-07-09 14:33 GMT-03:00 Tiwari, Arvind arvind.tiw...@hp.commailto:arvind.tiw...@hp.com: Hi All, I am investigating on inter cloud resource federation across OS based cloud deployments, this is needed to support multi regions, cloud bursting, VPC and more use cases. I came up with a design (link below) which advocate a new service (a.k.a. Alliance), this service sits close to Keystone and help abstracting all the inter cloud concerns from Keystone. This service will be abstracted from end users and there won’t be any direct interactions between user and Alliance service. Keystone will be delegating all inter cloud concerns to Alliance. https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation Apart from basic resource federation use cases, Alliance service will add following features 1. UUID token support across cloud 2. PKI Token support 3. Inter Cloud Token Validation 4. Inter Cloud Communication to allow •Region/endpoint Discovery •Service Discovery •Remote Resource Provisioning 5. Resource Access Across Clouds 6. SSO Across Cloud 7. SSOut Across Cloud (or Inter Cloud Token Revocation) 8. Notification to propagate meter info, resource de-provisioning …. I would appreciate if you guys take a look and share your perspective. I am open to any questions, suggestions, discussions on the same. Thanks for your time, Arvind Please excuse any typographical error. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Raildo Mascena Bachelor of Computer Science. Software Engineer at Laboratory of Distributed Systems - UFCG ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Inter cloud resource federation [Alliance]
Hi Matt, It is not about identity federation (which is handled in Keystone), this is about resource federation across clouds, Nova resources are one of them. I don't know much about Nova cells right now, I will try to understand it soon. Thanks, Arvind -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Wednesday, July 09, 2014 2:30 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Inter cloud resource federation [Alliance] On 7/9/2014 12:33 PM, Tiwari, Arvind wrote: Hi All, I am investigating on inter cloud resource federation across OS based cloud deployments, this is needed to support multi regions, cloud bursting, VPC and more use cases. I came up with a design (link below) which advocate a new service (a.k.a. Alliance), this service sits close to Keystone and help abstracting all the inter cloud concerns from Keystone. This service will be abstracted from end users and there won't be any direct interactions between user and Alliance service. Keystone will be delegating all inter cloud concerns to Alliance. https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation Apart from basic resource federation use cases, Alliance service will add following features 1.UUID token support across cloud 2.PKI Token support 3.Inter Cloud Token Validation 4.Inter Cloud Communication to allow *Region/endpoint Discovery *Service Discovery *Remote Resource Provisioning 5.Resource Access Across Clouds 6.SSO Across Cloud 7.SSOut Across Cloud (or Inter Cloud Token Revocation) 8.Notification to propagate meter info, resource de-provisioning I would appreciate if you guys take a look and share your perspective. I am open to any questions, suggestions, discussions on the same. Thanks for your time, Arvind *Please excuse any typographical error.*** ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Is this only identity (keystone) are other things like booting instances in nova from public/private clouds which are abstracted from the client, and if so have you heard of nova-cells? -- Thanks, Matt Riedemann ___ 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
[openstack-dev] Inter cloud resource federation [Alliance]
Hi All, I am investigating on inter cloud resource federation across OS based cloud deployments, this is needed to support multi regions, cloud bursting, VPC and more use cases. I came up with a design (link below) which advocate a new service (a.k.a. Alliance), this service sits close to Keystone and help abstracting all the inter cloud concerns from Keystone. This service will be abstracted from end users and there won't be any direct interactions between user and Alliance service. Keystone will be delegating all inter cloud concerns to Alliance. https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation Apart from basic resource federation use cases, Alliance service will add following features 1. UUID token support across cloud 2. PKI Token support 3. Inter Cloud Token Validation 4. Inter Cloud Communication to allow *Region/endpoint Discovery *Service Discovery *Remote Resource Provisioning 5. Resource Access Across Clouds 6. SSO Across Cloud 7. SSOut Across Cloud (or Inter Cloud Token Revocation) 8. Notification to propagate meter info, resource de-provisioning I would appreciate if you guys take a look and share your perspective. I am open to any questions, suggestions, discussions on the same. Thanks for your time, Arvind Please excuse any typographical error. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Inter Cloud Resource Federation (Alliance)
All, I am working on a new service to address the problems of Inter Cloud Resource Federation use cases (e.g. multi region, cloud bursting, resource sharing across clouds, etc . ). The new service will integrate multiple OpenStack cloud to work in alliance to provide resource federation and resource sharing across clouds. Please take a look at link below which explains use cases for resource federation and solution. This link also explains high level components of the new service. https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation Please share your thoughts and comments. Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Message level security plans. [barbican]
Some thoughts out of the context of this email thread. As per my understanding of Kite, it is a subset of Barbican or there might be minor gaps. If that is the true statement then what is the point of having a services with duplicate feature set? Why not port all the Kite feature to Barbican and use Barbican for message level security needs? Thoughts? Arvind -Original Message- From: Nathan Kinder [mailto:nkin...@redhat.com] Sent: Thursday, June 12, 2014 3:32 PM To: openstack-dev@lists.openstack.org Cc: Jamie Lennox Subject: Re: [openstack-dev] Message level security plans. Hi Tim, Jamie Lennox (cc'd) has been the main developer working on Kite. I'm sure he would appreciate you getting involved in reviews [1] and any other development help you're willing to contribute. Patches have slowly been landing in the kite repo. [2] For others not familiar with Kite, there is the blueprint mentioned elsewhere in this thread as well as this write-up of mine: https://blog-nkinder.rhcloud.com/?p=62 Thanks, -NGK [1] https://review.openstack.org/#/q/status:open+project:stackforge/kite,n,z [2] https://github.com/stackforge/kite On 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote: Hello OpenStack folks, First please allow me to introduce myself, my name is Tim Kelsey and I'm a security developer working at HP. I am very interested in projects like Kite and the work that's being undertaken to introduce message level security into OpenStack and would love to help out on that front. In an effort to ascertain the current state of development it would be great to hear from the people who are involved in this and find out what's being worked on or planned in blueprints. Many Thanks, -- Tim Kelsey Cloud Security Engineer HP Helion ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Message level security plans. [barbican]
Thanks Nathan for your response. Still not very convinced for two separate service. Keystone authentication is not a mandatory requirement for Barbican, as per design it can work without Keystone authentication. Rest (temporary session key generation, long-term keys ...) are feature gap which can be easily developed in barbican. If Barbican has to store long term keys on behalf of Kite users than IMO it is good to merge these two services. We can develop separate plug-in to achieve KDC (or Kite plug-in). One can have two separate barbican deployments one of KDC another for KMS (or may be only one with enhanced barbican API). Thoughts? Arvind -Original Message- From: Nathan Kinder [mailto:nkin...@redhat.com] Sent: Thursday, June 12, 2014 4:41 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Message level security plans. [barbican] On 06/12/2014 03:16 PM, Tiwari, Arvind wrote: Some thoughts out of the context of this email thread. As per my understanding of Kite, it is a subset of Barbican or there might be minor gaps. If that is the true statement then what is the point of having a services with duplicate feature set? Why not port all the Kite feature to Barbican and use Barbican for message level security needs? That's not a true statement. This was also something that was discussed at the Atlanta Summit in the Kite session with the Barbican development team, and agreement was reached that they are different use-cases and feature sets that should remain separate. To (over) simplify, Barbican allows OpenStack users (or services) identified by Keystone tokens to archive and later retrieve keys. In contrast, Kite is generating and issuing temporary session keys to communicating parties that are using the message queue in the underlying OpenStack infrastructure. These parties are not identified by Keystone. These session keys are also not archived by a service. Kite generates them, issues them in the form of a ticket, and forgets them immediately. You never want to be able to retrieve a key after a ticket is issued. In addition, the key generation is not purely random as I've outlined in my blog post (see the details around how HKDF is used if you're interested). There are areas for integration between Kite and Barbican. The most obvious would be to utilize Baribican to store the long-term keys used to authenticate the communicating party. Thanks, -NGK Thoughts? Arvind -Original Message- From: Nathan Kinder [mailto:nkin...@redhat.com] Sent: Thursday, June 12, 2014 3:32 PM To: openstack-dev@lists.openstack.org Cc: Jamie Lennox Subject: Re: [openstack-dev] Message level security plans. Hi Tim, Jamie Lennox (cc'd) has been the main developer working on Kite. I'm sure he would appreciate you getting involved in reviews [1] and any other development help you're willing to contribute. Patches have slowly been landing in the kite repo. [2] For others not familiar with Kite, there is the blueprint mentioned elsewhere in this thread as well as this write-up of mine: https://blog-nkinder.rhcloud.com/?p=62 Thanks, -NGK [1] https://review.openstack.org/#/q/status:open+project:stackforge/kite,n ,z [2] https://github.com/stackforge/kite On 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote: Hello OpenStack folks, First please allow me to introduce myself, my name is Tim Kelsey and I'm a security developer working at HP. I am very interested in projects like Kite and the work that's being undertaken to introduce message level security into OpenStack and would love to help out on that front. In an effort to ascertain the current state of development it would be great to hear from the people who are involved in this and find out what's being worked on or planned in blueprints. Many Thanks, -- Tim Kelsey Cloud Security Engineer HP Helion ___ 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 ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
As per current implementation, containers are immutable. Do we have any use case to make it mutable? Can we live with new container instead of updating an existing container? Arvind -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Monday, June 09, 2014 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10:16 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas Hey everyone, Per our IRC discussion yesterday I'd like to continue the discussion on how Barbican and Neutron LBaaS will interact. There are currently two ideas in play and both will work. If you have another idea please free to add it so that we may evaluate all the options relative to each other. Here are the two current ideas: 1. Create an eventing system for Barbican that Neutron LBaaS (and other services) consumes to identify when to update/delete updated secrets from Barbican. For those that aren't up to date with the Neutron LBaaS API Revision, the project/tenant/user provides a secret (container?) id when enabling SSL/TLS functionality. * Example: If a user makes a change to a secret/container in Barbican then Neutron LBaaS will see an event and take the appropriate action. PROS: - Barbican is going to create an eventing system regardless so it will be supported. - Decisions are made on behalf of the user which lessens the amount of calls the user has to make. CONS: - An eventing framework can become complex especially since we need to ensure delivery of an event. - Implementing an eventing system will take more time than option #2ŠI think. 2. Push orchestration decisions to API users. This idea comes with two assumptions. The first assumption is that most providers' customers use the cloud via a GUI, which in turn can handle any orchestration decisions that need to be made. The second assumption is that power API users are savvy and can handle their decisions as well. Using this method requires services, such as LBaaS, to register in the form of metadata to a barbican container. * Example: If a user makes a change to a secret the GUI can see which services are registered and opt to warn the user of consequences. Power users can look at the registered services and make decisions how they see fit. PROS: - Very simple to implement. The only code needed to make this a reality is at the control plane (API) level. - This option is more loosely coupled that option #1. CONS: - Potential for services to not register/unregister. What happens in this case? - Pushes complexity of decision making on to GUI engineers and power API users. I would like to get a consensus on which option to move forward with ASAP since the hackathon is coming up and delivering Barbican to Neutron LBaaS integration is essential to exposing SSL/TLS functionality, which almost everyone has stated is a #1/#2 priority. I'll start the decision making process by advocating for option #2. My reason for choosing option #2 has to deal mostly with the simplicity of implementing such a mechanism. Simplicity also means we can implement the necessary code and get it approved much faster which seems to be a concern for everyone. What option does everyone else want to move forward with? Cheers, --Jorge ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] [barbican] Protecting user specific secrets in Barbican
Barbcan will be used as secret store (or Key Manager) in Open Stack deployments. That means users can store any kind for secrets (ssh keys , access keys, password .) in Barbican these secrets are not shared secrets. In below scenario it seems secrets are not well protected in Barbican 1. Barbican in integrated a OS based cloud deployment. 2. In particular domain there is one (or multiple) project. 3. Users are associated with the project through role (two coworker can have same role e.g. creator) or a admin user have higher role. 4. Users have their secrets (ssh keys , access keys, password .) for services (VMs per users, resources) saved in Barbican. Problem 1. Users with the same role or Admin on project can see each other secrets which are not a shared secrets. 2. Multiple projects (or project hierarchy) per user just to store secrets is not going to help as it will lead to project exposition and confusing. At the same time projects are not meant to go 1 to 1 with user. 3. Project hierarchy is also not a good solution as user on top of the hierarchy (reseller admin) can inherits role and able to steal the secrets. Note, Barbican is designed for secret storage and protection, we need better management on secrets in Barbican. We also need better solution to address this problem. Keystone and Barbican (or interested party) team, can we have a meeting today to brainstorm this issue and come up with better solution? Thanks Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hierarchical administrative boundary [keystone]
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.t...@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) fritt...@hp.commailto:fritt...@hp.com: From: Adam Young [mailto:ayo...@redhat.commailto:ayo...@redhat.com] Sent: 09 May 2014 04:19 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@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 Multitenancyhttp://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@lists.openstack.orgmailto:OpenStack-dev@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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[openstack-dev] Hierarchical administrative boundary [keystone]
Hi All, Below is my proposal to address VPC use case using hierarchical administrative boundary. This topic is scheduled in Hierarchical Multitenancyhttp://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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review
Hi Chad, We are working on following topics and expecting some time to discuss in the summit. Can we accommodate them in the summit? https://blueprints.launchpad.net/barbican/+spec/secret-isolation-at-user-level (We are working on POC + API change proposal) https://blueprints.launchpad.net/barbican/+spec/api-remove-uri-tenant-id (API change proposal) https://blueprints.launchpad.net/barbican/+spec/ability-to-hard-delete-barbican-entities (API change proposal) Thanks, Arvind From: Chad Lung [mailto:chad.l...@gmail.com] Sent: Monday, May 05, 2014 10:06 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review The Barbican team has placed a few etherpads on our wiki for the community to review. We plan to work on these at the Atlanta summit next week in our sessions and throughout the week. https://wiki.openstack.org/wiki/Barbican#Discussions_.2F_Etherpads Thanks, Chad Lung http://giantflyingsaucer.com/blog/ @chadlung ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review
Chad, Please let me know if you want me to start etherpads for them? Regards, Arvind From: Tiwari, Arvind Sent: Monday, May 05, 2014 10:22 AM To: openstack-dev@lists.openstack.org Subject: RE: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review Hi Chad, We are working on following topics and expecting some time to discuss in the summit. Can we accommodate them in the summit? https://blueprints.launchpad.net/barbican/+spec/secret-isolation-at-user-level (We are working on POC + API change proposal) https://blueprints.launchpad.net/barbican/+spec/api-remove-uri-tenant-id (API change proposal) https://blueprints.launchpad.net/barbican/+spec/ability-to-hard-delete-barbican-entities (API change proposal) Thanks, Arvind From: Chad Lung [mailto:chad.l...@gmail.com] Sent: Monday, May 05, 2014 10:06 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review The Barbican team has placed a few etherpads on our wiki for the community to review. We plan to work on these at the Atlanta summit next week in our sessions and throughout the week. https://wiki.openstack.org/wiki/Barbican#Discussions_.2F_Etherpads Thanks, Chad Lung http://giantflyingsaucer.com/blog/ @chadlung ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] [Barbican] HTTPS Connection Question
Just to confirm which “barbican-api-paste.ini” you are making the below change? Arvind From: Miller, Mark M (EB SW Cloud - RD - Corvallis) Sent: Friday, March 07, 2014 10:38 AM To: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hello Doug, I have been able to configure Barbican with Apache2 via WSGI thereby removing the middle “HTTPS - uWSGI - Barbican” step. By removing the middle “uWSGI” step, the insecure uwsgi connection is also removed. How do I contribute to the wiki page? I have also installed Keystone and attempted to configure Barbican to use Keystone for authentication but have been unsuccessful. Barbican performs the requested API without checking the token. What am I missing? Mark File barbican-api-paste.ini: # Use this pipeline for Barbican API - DEFAULT no authentication [pipeline:main] #pipeline = unauthenticated-context apiapp pipeline = keystone_v3_authtoken context apiapp pipeline = simple apiapp #Use this pipeline to activate a repoze.profile middleware and HTTP port, # to provide profiling information for the REST API processing. [pipeline:barbican-profile] pipeline = unauthenticated-context egg:Paste#cgitb egg:Paste#httpexceptions profile apiapp #Use this pipeline for keystone auth [pipeline:barbican-api-keystone] pipeline = keystone_authtoken context apiapp [app:apiapp] paste.app_factory = barbican.api.app:create_main_app [filter:simple] paste.filter_factory = barbican.api.middleware.simple:SimpleFilter.factory [filter:unauthenticated-context] paste.filter_factory = barbican.api.middleware.context:UnauthenticatedContextMiddleware.factory [filter:context] paste.filter_factory = barbican.api.middleware.context:ContextMiddleware.factory [filter:keystone_authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory signing_dir = /tmp/barbican/cache auth_host = localhost #need ability to re-auth a token, thus admin url auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = barbican admin_password = secret #admin_password = orange auth_version = v2.0 #delay failing perhaps to log the unauthorized request in barbican .. #delay_auth_decision = true [filter:keystone_v3_authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory signing_dir = /tmp/barbican/cache auth_host = localhost #need ability to re-auth a token, thus admin url auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = barbican admin_password = secret #admin_password = orange auth_version = v3.0 #delay failing perhaps to log the unauthorized request in barbican .. #delay_auth_decision = true [filter:profile] use = egg:repoze.profile log_filename = myapp.profile cachegrind_filename = cachegrind.out.myapp discard_first_request = true path = /__profile__ flush_at_shutdown = true unwind = false From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] Sent: Tuesday, March 04, 2014 2:47 PM To: Miller, Mark M (EB SW Cloud - RD - Corvallis); Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hi Mark, I hope I can answer your questions: 1. HTTP support should be provided by the web server used to host barbican, not by barbican itself. The files where you noticed the “protocol = http” settings are uwsgi configuration files the Barbican team uses to run Barbican using uwsgi during development. The settings are just default development settings, and should be tuned to your particular situation. You can find more information about uwsgi config options on their official documentation. [1] In particular, you may be interested in enabling HTTPS support documentation. [2] 2. As I mentioned above, the dev team uses uwsgi to run Barbican, however there are no dependencies on uwsgi built into barbican. This means that, in theory, you should be able to run Barbican using Apache + mod_uwsgi, or Nginx + gunicorn, or any other web server capable of hosting a WSGI app. That said, we have not actually built environments with alternative web servers, so we don’t currently have any documentation on how to set that up. If you decide to deploy Barbican using Apache, we’d love to hear about your experience and help out in any way we can (join us at #openstack-barbican on Freenode). I would encourage you to contribute to our documentation wiki if you are successful. Regards, -Doug Mendizabal [1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html [2] http://uwsgi-docs.readthedocs.org/en/latest/HTTPS.html?highlight=ssl#https-support-from-1-3 From: Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.commailto:mark.m.mil...@hp.com Date: Tuesday, March 4, 2014 at 12:44 PM To: Ferreira, Rafael r...@io.commailto:r...@io.com, Remo Mattei
Re: [Openstack] [Barbican] HTTPS Connection Question
Comment in line. Arvind From: Miller, Mark M (EB SW Cloud - RD - Corvallis) Sent: Friday, March 07, 2014 10:53 AM To: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hello, I want to ask the following question of the Barbican community: “How does Barbican store secrets today? Does it rely on special hardware to assure encryption of secrets is done. Does it also have an option to use SW encryption before storing secrets.” 1. It encrypt the secret before storing to DB, using a Key encryption key which is generated per tenant. 2. It is not mandatory to use special hardware for key encryption keys but can utilize a HSM for this purpose. 3. By default it generated the Key encryption keys by itself. Thanks, Mark From: Miller, Mark M (EB SW Cloud - RD - Corvallis) Sent: Friday, March 07, 2014 9:38 AM To: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hello Doug, I have been able to configure Barbican with Apache2 via WSGI thereby removing the middle “HTTPS - uWSGI - Barbican” step. By removing the middle “uWSGI” step, the insecure uwsgi connection is also removed. How do I contribute to the wiki page? I have also installed Keystone and attempted to configure Barbican to use Keystone for authentication but have been unsuccessful. Barbican performs the requested API without checking the token. What am I missing? Mark File barbican-api-paste.ini: # Use this pipeline for Barbican API - DEFAULT no authentication [pipeline:main] #pipeline = unauthenticated-context apiapp pipeline = keystone_v3_authtoken context apiapp pipeline = simple apiapp #Use this pipeline to activate a repoze.profile middleware and HTTP port, # to provide profiling information for the REST API processing. [pipeline:barbican-profile] pipeline = unauthenticated-context egg:Paste#cgitb egg:Paste#httpexceptions profile apiapp #Use this pipeline for keystone auth [pipeline:barbican-api-keystone] pipeline = keystone_authtoken context apiapp [app:apiapp] paste.app_factory = barbican.api.app:create_main_app [filter:simple] paste.filter_factory = barbican.api.middleware.simple:SimpleFilter.factory [filter:unauthenticated-context] paste.filter_factory = barbican.api.middleware.context:UnauthenticatedContextMiddleware.factory [filter:context] paste.filter_factory = barbican.api.middleware.context:ContextMiddleware.factory [filter:keystone_authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory signing_dir = /tmp/barbican/cache auth_host = localhost #need ability to re-auth a token, thus admin url auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = barbican admin_password = secret #admin_password = orange auth_version = v2.0 #delay failing perhaps to log the unauthorized request in barbican .. #delay_auth_decision = true [filter:keystone_v3_authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory signing_dir = /tmp/barbican/cache auth_host = localhost #need ability to re-auth a token, thus admin url auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = barbican admin_password = secret #admin_password = orange auth_version = v3.0 #delay failing perhaps to log the unauthorized request in barbican .. #delay_auth_decision = true [filter:profile] use = egg:repoze.profile log_filename = myapp.profile cachegrind_filename = cachegrind.out.myapp discard_first_request = true path = /__profile__ flush_at_shutdown = true unwind = false From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] Sent: Tuesday, March 04, 2014 2:47 PM To: Miller, Mark M (EB SW Cloud - RD - Corvallis); Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hi Mark, I hope I can answer your questions: 1. HTTP support should be provided by the web server used to host barbican, not by barbican itself. The files where you noticed the “protocol = http” settings are uwsgi configuration files the Barbican team uses to run Barbican using uwsgi during development. The settings are just default development settings, and should be tuned to your particular situation. You can find more information about uwsgi config options on their official documentation. [1] In particular, you may be interested in enabling HTTPS support documentation. [2] 2. As I mentioned above, the dev team uses uwsgi to run Barbican, however there are no dependencies on uwsgi built into barbican. This means that, in theory, you should be able to run Barbican using Apache + mod_uwsgi, or Nginx + gunicorn, or any other web server capable of hosting a
Re: [Openstack] [Barbican] HTTPS Connection Question
Hi Mark, Barbican does not support SSL , I have added BP for the same. https://blueprints.launchpad.net/barbican/+spec/transport-layer-security-is-needed-in-barbican I have added this page which uses NginX (I like better than APache) to provide SSL support https://github.com/cloudkeep/barbican/wiki/Deploy-OpenStack-Barbican-with-Nginx-web-server Hope this will help. Thanks, Arvind From: Miller, Mark M (EB SW Cloud - RD - Corvallis) Sent: Tuesday, March 04, 2014 4:34 PM To: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hello Doug, Thank you for the information. I will keep you informed if we decide to use Apache2 as a front end. Regards, Mark From: Douglas Mendizabal [mailto:douglas.mendiza...@rackspace.com] Sent: Tuesday, March 04, 2014 2:47 PM To: Miller, Mark M (EB SW Cloud - RD - Corvallis); Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hi Mark, I hope I can answer your questions: 1. HTTP support should be provided by the web server used to host barbican, not by barbican itself. The files where you noticed the “protocol = http” settings are uwsgi configuration files the Barbican team uses to run Barbican using uwsgi during development. The settings are just default development settings, and should be tuned to your particular situation. You can find more information about uwsgi config options on their official documentation. [1] In particular, you may be interested in enabling HTTPS support documentation. [2] 2. As I mentioned above, the dev team uses uwsgi to run Barbican, however there are no dependencies on uwsgi built into barbican. This means that, in theory, you should be able to run Barbican using Apache + mod_uwsgi, or Nginx + gunicorn, or any other web server capable of hosting a WSGI app. That said, we have not actually built environments with alternative web servers, so we don’t currently have any documentation on how to set that up. If you decide to deploy Barbican using Apache, we’d love to hear about your experience and help out in any way we can (join us at #openstack-barbican on Freenode). I would encourage you to contribute to our documentation wiki if you are successful. Regards, -Doug Mendizabal [1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html [2] http://uwsgi-docs.readthedocs.org/en/latest/HTTPS.html?highlight=ssl#https-support-from-1-3 From: Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.commailto:mark.m.mil...@hp.com Date: Tuesday, March 4, 2014 at 12:44 PM To: Ferreira, Rafael r...@io.commailto:r...@io.com, Remo Mattei r...@italy1.commailto:r...@italy1.com, Wyllys Ingersoll wyllys.ingers...@evault.commailto:wyllys.ingers...@evault.com, openstack@lists.openstack.orgmailto:openstack@lists.openstack.org openstack@lists.openstack.orgmailto:openstack@lists.openstack.org Subject: Re: [Openstack] [Barbican] HTTPS Connection Question Hello, I’ve been digging and digging and I have not been able to locate the following information: 1. Does Barbican provide support for HTTPS connections to it? I noticed “protocol=http” in several .ini files and a .conf file, but no information on how to configure Barbican to use it. 2. The quickstart wiki shows how to install Barbican behind the uwsgi server. Is it possible to install Barbican behind Apache2? Is there any documentation or example configuration guides? Thanks, Mark ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Nova] Including Domains in Nova
Hi Henrique, I agree with your thoughts and in my opinion every OpenStack service has to be Domain aware. Specially it will be more helpful in large scale OpenStack deployments where IAM resources are scoped to a domain but other services (e.g. Nova) are just not aware of domains. Thanks, Arvind From: Henrique Truta [mailto:henriquecostatr...@gmail.com] Sent: Wednesday, February 19, 2014 5:21 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Nova] Including Domains in Nova Hi everyone. It is necessary to make Nova support the Domain quotas and create a new administrative perspective. Here are some reasons why Nova should support domains: 1 - It's interesting to keep the main Openstack components sharing the same concept, once it has already been made in Keystone. In Keystone, the domain defines more administrative boundaries and makes management of its entities easier. 2 - Nova shouldn't be so tied in to projects. Keystone was created to abstract concepts like these to other modules, like Nova. In addition, Nova needs to be flexible enough to work with the new functionalities that Keystone will provide. If we keep the Nova tied in to projects (or domains), we will be far from the Nova focus which is providing compute services. 3 - There is also the Domain Quota Driver BP (https://blueprints.launchpad.net/nova/+spec/domain-quota-driver), which implementation has already began. This Blueprint allows the user to handle quotas at domain level. Nova requires domains to make this feature work properly, right above the project level. There is also an implementation that includes the domain information on the token context. This implementation have to be included as well: https://review.openstack.org/#/c/55870/ . 4 - The Nova API must be extended in order to enable domain-level operations, that only work at project-level such as: - Listing, viewing and deleting images; - Deleting and listing servers; - Perform server actions like changing passwords, reboot, rebuild and resize; - CRUD and listing on server metadata; In addition to provide quota management through the API and establishment of a new administrative scope. In order to accomplish these features, the token must contain the domain informations, which will be included as mentioned in item 3. Then, the Nova API calls will be changed to consider the domain information and when a call referent to a project is made (e.g. servers). What do you think about it? Any additional suggestions? AT: Keystone also has to enforce the domain scoping more strongly, as in the current model Keystone resources are not required to be scoped a domain. Thanks. Henrique Truta ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VPC Proposal
Hi JC, I have proposed BP to address VPC using domain hierarchy and hierarchical administrative boundary. https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary Thanks, Arvind -Original Message- From: Martin, JC [mailto:jch.mar...@gmail.com] Sent: Friday, February 14, 2014 12:09 PM To: OpenStack Development Mailing List Subject: [openstack-dev] VPC Proposal There is a Blueprint targeted for Icehouse-3 that is aiming to implement the AWS VPC api. I don't think that this blueprint is providing the necessary constructs to really implement a VPC, and it is not taking into account the domains, or proposed multi tenant hierarchy. In addition, I could not find a discussion about this topic leading to the approval. For this reason, I wrote an 'umbrella' blueprint to hopefully start the discussion on how to really implement VPC, and eventually split it into multiple real blueprints for each area. Please, provide feedback on the following document, and on the best way to move this forward. https://wiki.openstack.org/wiki/Blueprint-VPC Thanks, JC. ___ 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
Re: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion
Hi Chris, Looking at your requirements, seems my solution (see attached email) is pretty much aligned. What I am trying to propose is 1. One root domain as owner of virtual cloud. Logically linked to n leaf domains. 2. All leaf domains falls under admin boundary of virtual cloud owner. 3. No sharing of resources at project level, that will keep the authorization model simple. 4. No sharing of resources at domain level either. 5. Hierarchy or admin boundary will be totally governed by roles. This way we can setup a true virtual cloud/Reseller/wholesale model. Thoughts? Thanks, Arvind -Original Message- From: Chris Behrens [mailto:cbehr...@codestud.com] Sent: Wednesday, February 05, 2014 1:27 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion Hi Vish, I'm jumping in slightly late on this, but I also have an interest in this. I'm going to preface this by saying that I have not read this whole thread yet, so I apologize if I repeat things, say anything that is addressed by previous posts, or doesn't jive with what you're looking for. :) But what you describe below sounds like exactly a use case I'd come up with. Essentially I want another level above project_id. Depending on the exact use case, you could name it 'wholesale_id' or 'reseller_id'...and yeah, 'org_id' fits in with your example. :) I think that I had decided I'd call it 'domain' to be more generic, especially after seeing keystone had a domain concept. Your idea below (prefixing the project_id) is exactly one way I thought of doing this to be least intrusive. I, however, thought that this would not be efficient. So, I was thinking about proposing that we add 'domain' to all of our models. But that limits your hierarchy and I don't necessarily like that. :) So I think that if the queries are truly indexed as you say below, you have a pretty good approach. The one issue that comes into mind is that if there's any chance of collision. For example, if project ids (or orgs) could contain a '.', then '.' as a delimiter won't work. My requirements could be summed up pretty well by thinking of this as 'virtual clouds within a cloud'. Deploy a single cloud infrastructure that could look like many multiple clouds. 'domain' would be the key into each different virtual cloud. Accessing one virtual cloud doesn't reveal any details about another virtual cloud. What this means is: 1) domain 'a' cannot see instances (or resources in general) in domain 'b'. It doesn't matter if domain 'a' and domain 'b' share the same tenant ID. If you act with the API on behalf of domain 'a', you cannot see your instances in domain 'b'. 2) Flavors per domain. domain 'a' can have different flavors than domain 'b'. 3) Images per domain. domain 'a' could see different images than domain 'b'. 4) Quotas and quota limits per domain. your instances in domain 'a' don't count against quotas in domain 'b'. 5) Go as far as using different config values depending on what domain you're using. This one is fun. :) etc. I'm not sure if you were looking to go that far or not. :) But I think that our ideas are close enough, if not exact, that we can achieve both of our goals with the same implementation. I'd love to be involved with this. I am not sure that I currently have the time to help with implementation, however. - Chris On Feb 3, 2014, at 1:58 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Again! At the meeting last week we discussed some options around getting true multitenancy in nova. The use case that we are trying to support can be described as follows: Martha, the owner of ProductionIT provides it services to multiple Enterprise clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and Development teams with many users. Joe needs the ability create users, projects, and quotas, as well as the ability to list and delete resources across WidgetMaster. Martha needs to be able to set the quotas for both WidgetMaster and SuperDevShop; manage users, projects, and objects across the entire system; and set quotas for the client companies as a whole. She also needs to ensure that Joe can't see or mess with anything owned by Sam. As per the plan I outlined in the meeting I have implemented a Proof-of-Concept that would allow me to see what changes were required in nova to get scoped tenancy working. I used a simple approach of faking out heirarchy by prepending the id of the larger scope to the id of the smaller scope. Keystone uses uuids internally, but for ease of explanation I will pretend like it is using the name. I think we can all agree that 'orga.projecta' is more readable than 'b04f9ea01a9944ac903526885a2666dec45674c5c2c6463dad3c0cb9d7b8a6d8'. The
Re: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion
Hi Vish, I am sorry as I am proposing just a solution approach below but no code so far. ### Problem and Requirement ### As per the problem description it seems to me that Martha, the owner of ProductionIT is not a cloud provider (correct me if wrong) and she uses someone else cloud infrastructure (like public cloud) to provide services to multiple Enterprise clients. After reading further it seems to me that we want different administrative boundaries and isolation among them, so that Joe can manage/mess-up resource for WidgetMaster and Sam for SuperDevShop but not each other at the same time Martha should be allowed to manage resources from both. ### Requirements based on my understanding ### 1. Joe can manage/mess-up resource for WidgetMaster and Sam for SuperDevShop but not each other. 2. Martha should be able to manage resources from both. ### Solution ### (*This solution is backed-up by production working implementation*) In a nutshell, We need ability to setup hierarchicical administrative boundaries within a cloud deployment, so that multiple service providers (like Martha) can be created and have administrative privilege across multiple domains which falls under their administrative boundary. Note: There will be only one level of hierarchy as multi level hierarchy is complex to implement and does not perform well. Give that, Martha/ProductionIT will be at root of hierarchy, Joe and Sam will stand at leaf of the hierarchy. (Solution for Req#1) Keystone has concept of domains which is nothing but a notion of an administrative boundary where admin of one domain is allowed to manage resources within a specific domain but not across domains, provided correct policy is in place. This is already in place so there will be no change needed to support Req #1. (Solution for Req#2) We can extend the notion of domains further to define a root (parent/super) domain and leaf (child/sub) domains, one set of root and leaf domains will define a hierarchicical administrative boundary. Glue between root and leafs will be different roles, that way Matha can become NovaAdmin (or any other role) in WidgetMaster or SuperDevShop. ### Pros ### Complete IAM based solution. More logically fits in hierarchicical model. Absolutely no (or minimal) changes to services (Nova, Swift ) ### Cons ### Most of the changes is needed in Keystone and its data model (Domain, Roles). Some change required in OSLO policy engine for policy evaluation. Service (Nova, Swift ) may have define new roles. Let me know if I am not making sense here or have any questions. Arvind -Original Message- From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: Monday, February 03, 2014 2:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion Hello Again! At the meeting last week we discussed some options around getting true multitenancy in nova. The use case that we are trying to support can be described as follows: Martha, the owner of ProductionIT provides it services to multiple Enterprise clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and Development teams with many users. Joe needs the ability create users, projects, and quotas, as well as the ability to list and delete resources across WidgetMaster. Martha needs to be able to set the quotas for both WidgetMaster and SuperDevShop; manage users, projects, and objects across the entire system; and set quotas for the client companies as a whole. She also needs to ensure that Joe can't see or mess with anything owned by Sam. As per the plan I outlined in the meeting I have implemented a Proof-of-Concept that would allow me to see what changes were required in nova to get scoped tenancy working. I used a simple approach of faking out heirarchy by prepending the id of the larger scope to the id of the smaller scope. Keystone uses uuids internally, but for ease of explanation I will pretend like it is using the name. I think we can all agree that 'orga.projecta' is more readable than 'b04f9ea01a9944ac903526885a2666dec45674c5c2c6463dad3c0cb9d7b8a6d8'. The code basically creates the following five projects: orga orga.projecta orga.projectb orgb orgb.projecta I then modified nova to replace everywhere where it searches or limits policy by project_id to do a prefix match. This means that someone using project 'orga' should be able to list/delete instances in orga, orga.projecta, and orga.projectb. You can find the code here: https://github.com/vishvananda/devstack/commit/10f727ce39ef4275b613201ae1ec7655bd79dd5f https://github.com/vishvananda/nova/commit/ae4de19560b0a3718efaffb6c205c7a3c372412f Keeping in mind that this is a prototype, but I'm hoping to come to some kind of consensus as to whether
Re: [openstack-dev] Domain ID in Policy_dict
I think you have to define rule as below domain-admin: role:domain_admin and domain_id:%(target.domain.domain_id)s Associate this rule with APIS which you want to scope to domain admin. Try and let us know. Arvind -Original Message- From: boun...@canonical.com [mailto:boun...@canonical.com] On Behalf Of Telles Mota Vidal Nóbrega Sent: Thursday, January 16, 2014 6:30 AM To: Tiwari, Arvind Subject: Domain ID in Policy_dict Hi, i'm working on some new features for openstack and this merge that you submitted https://review.openstack.org/#/c/50488/ does most of what I need. I updated the code here but I couldn't make it work, my idea is to create a role called domain_admin, to check this we would need to check if the user is admin and is owner of the domain and for that we would need the domain_id t o be checked at the policy.json which by the examples you posted works. Unfortunetly I wasn't able to do so, can you help me out, give me some tips on how to get this working? Thanks -- This message was sent from Launchpad by =?utf-8?q?Telles_Mota_Vidal_N=C3=B3brega?= (https://launchpad.net/~tellesmvn) using the Contact this user link on your profile page (https://launchpad.net/~arvind-tiwari). For more information see https://help.launchpad.net/YourAccount/ContactingPeople ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] API spec for OS-NS-ROLES extension
Hi Adam, I would like to request you to revisit the below link and provide your opinion, so that we can move forward and try to find a common ground where everyone. https://review.openstack.org/#/c/61897 Below is my justification for service_id in role model: In a public cloud deployment model, service teams (or service deployers) defines the roles along with other artifacts (service and endpoint) and they need full control on these artifacts including roles. This way they can control the life cycle of these artifacts without depending on IAM service providers. (more details in https://blueprints.launchpad.net/keystone/+spec/name-spaced-roles) As an IAM service provider in a public cloud deployment, it is our responsibility to facilitate them so that they can control full life cycle of their service specific artifacts. To make it happen we need tight access control on these artifacts, so that a service deployer accidently or maliciously not able to mess-up with other services. To achieve that level fine granularity and to isolate service deployers from artifacts, we need to associate entity models (service, endpoints and roles) with a service. This way we can define entity ownership and define access control policy based on service. Currently, role data model does not support any association and that is why I am requesting to introduce some way to associate a role with domain, project and service. This association also helps to define a namespace for making the role name globally unique. Previously I was trying achieve tight linking of roles with service_id and that might be offending for some community members. Now after much effort and help from David Chadwick, we have generalized the role model and come up with generic design, so that it can fit in with every once use case. As I mentioned in the spec it will be backward compatible so that it won't break the existing deployments I would appreciate if you can revisit the link and provide comments and suggestions, there might be still some room for improvements and I am open for them. Dolph, I would also like you to review the specs, so that we can make some progress. Regards, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David,
I am cool with the proposal, just wanted to grad you attention on may question
which I asked in my last email (which is below)
Q. what if two (or more) endpoints want to have same role_name for a service
(nova.east.admin, nova.west.admin, nova.north.admin .)?
(Can we think of adding an optional endpoint_id attribute in role data model to
allow such role, which is also needed to envision endpoint scoped tokens for
our use case)
{
role: {
id: 76e72a,
domain_id = --id--,(optional, if present, role is named by
specific domain)
project_id = --id--,(optional, if present, role is named by
project)
service_id = --id--,(optional, if present, role is named by
service)
endpoint_id = --id--,(optional, if present, role is named by
service)
name: ---role_name---, (must be unique when combined with domain,
project and service ids)
scope: {id: ---id---, (resource_id)
type: service | file | domain etc.,
endpoint:---endpoint---
}
}
}
For Adam's question We are not linking role names to service id. (email
attached)
AT: These attributes are all optional and will not stop anyone how don't want
to included service_id or (any other attribute) for role name uniqueness. So in
particular deployment want to keep just the role name unique, this model will
not restrict you.
Thoughts?
Thanks,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Tuesday, December 10, 2013 1:30 AM
To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
How about the following which clearly separates naming and scoping
constraints
{
role: {
id: 76e72a,
domain_id = --id--,(optional, if present, role is named by
specific domain)
project_id = --id--,(optional, if present, role is named by
project)
service_id = --id--,(optional, if present, role is named by
service)
name: ---role_name---, (must be unique when combined with domain,
project and service ids)
scope: {id: ---id---, (resource_id)
type: service | file | domain etc.,
endpoint:---endpoint---
}
}
}
regards
David
---BeginMessage---
On 12/09/2013 05:31 PM, Tiwari, Arvind wrote:
I think that make sense, how does below data model looks?
{
role: {
id: 76e72a,
name: ---role_name---, (resource name spaced name e.g.
nova.east.admin)
scope: {
id: ---id---, (resource_id)
type: service | file | domain etc.,
endpoint:---endpoint---
}
domain_id = --id--,(optional)
project_id = --id--, (optional)
service_id = --id--(optional)
}
}
We are not linking role names to service id.
Q. what if two (or more) endpoints want to have same role_name for a service
(nova.east.admin, nova.west.admin, nova.north.admin .)?
Regards,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Monday, December 09, 2013 3:15 PM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
this is still mixing up two separate concepts: naming and policy
constraints. Scope is a policy constraint but in the proposal below is
also part of the unique naming of the role. The fields making up both
concepts need to be separate (e.g. what if 2 different roles from the
same domain and project applied to two different scopes but it just so
happened that the ids of the two resources were the same? They would end
up still having the same unique name.)
I would therefore add service_id = --id-- (optional)
after project_id. This can assure that (composite) role names (keys) are
unique
regards
David
On 09/12/2013 20:36, Tiwari, Arvind wrote:
Hi David,
I have updated the ether pad with below comments.
Regards,
Arvind
Another alternative is to change role name into role display name,
indicating that the string is only to be used in GUIs, is not guaranteed to
be unique, is set by the role creator, can be any string in any character
set, and is not used by the system anywhere (AT1). Only role ID is used by
the system, in policy evaluation, in user-role assignments, in
permission-role assignments etc. (AT2)
AT1 -
1. Display name proposal does not seems to work because, we cannot enforce
service (e.g. Nova, Swift) to use role_id to define their policy.
AT2 -
1. Using role_id for policy evaluation is doable but it will be an
enormous impact on token data structure, policy etc, which won't be
acceptable to community.
2. permission-role assignments goes
Re: [openstack-dev] [keystone] Service scoped role definition
Yes, it is required to address one of public cloud use case where we want
regional service admins and to support
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.
Based on our discussion I am going to start API specs and submit for review.
{
role: {
id: 76e72a,
domain_id = --id--,(optional, if present, role is named by
specific domain)
project_id = --id--,(optional, if present, role is named by
project)
service_id = --id--,(optional, if present, role is named by
service)
endpoint_id = --id--,(optional, if present, role is named by
service)
name: ---role_name---, (must be unique when combined with domain,
project and service ids)
scope: {id: ---id---, (resource_id)
type: service | file | domain etc.,
endpoint:---endpoint---
}
}
}
For Adam's Concern, You are over designing. Services and Endpoints have no
business in this design. That is enforcement, not definition or assignment of
the Roles. We need a clean namespace, and mixing services and endpoints in
there adds no benefit.
AT: To support following two BPs and these are the basic requirements for
public cloud deployment with Keystone otherwise we are locked. I am asking
for endpoint_id extension in role data model to support endpoint scoped tokens
which you mentioned in IRC around a week back.
1.
https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
2. https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.
Thanks.
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Tuesday, December 10, 2013 2:27 PM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.
regards
David
On 10/12/2013 16:42, Tiwari, Arvind wrote:
Hi David,
I am cool with the proposal, just wanted to grad you attention on may
question which I asked in my last email (which is below)
Q. what if two (or more) endpoints want to have same role_name for a
service (nova.east.admin, nova.west.admin, nova.north.admin .)?
(Can we think of adding an optional endpoint_id attribute in role
data model to allow such role, which is also needed to envision
endpoint scoped tokens for our use case)
{ role: { id: 76e72a, domain_id = --id--,(optional, if
present, role is named by specific domain) project_id = --id--,
(optional, if present, role is named by project) service_id =
--id--,(optional, if present, role is named by service)
endpoint_id = --id--,(optional, if present, role is named by
service) name: ---role_name---, (must be unique when combined
with domain, project and service ids) scope: {id: ---id---,
(resource_id) type: service | file | domain etc.,
endpoint:---endpoint--- } } }
For Adam's question We are not linking role names to service id.
(email attached) AT: These attributes are all optional and will not
stop anyone how don't want to included service_id or (any other
attribute) for role name uniqueness. So in particular deployment want
to keep just the role name unique, this model will not restrict you.
Thoughts?
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
List (not for usage questions) Cc: Henry Nash;
dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
[keystone] Service scoped role definition
How about the following which clearly separates naming and scoping
constraints
{ role: { id: 76e72a, domain_id = --id--,(optional, if
present, role is named by specific domain) project_id = --id--,
(optional, if present, role is named by project) service_id =
--id--,(optional, if present, role is named by service) name:
---role_name---, (must be unique when combined with domain,
project and service ids) scope: {id: ---id---, (resource_id)
type: service | file | domain etc., endpoint:---endpoint---
} } }
regards
David
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
My Comments in line.
Arvind
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Tuesday, December 10, 2013 2:54 PM
To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
On 12/10/2013 04:26 PM, David Chadwick wrote:
Hi Arvind
the granularity in naming can be as fine as required i.e. a naming
hierarchy can be as deep as required. So if there is a requirement for
individual endpoints to name their own roles, then the addition of
endpoint_id to the naming structure is fine.
regards
David
On 10/12/2013 16:42, Tiwari, Arvind wrote:
Hi David,
I am cool with the proposal, just wanted to grad you attention on may
question which I asked in my last email (which is below)
Q. what if two (or more) endpoints want to have same role_name for a
service (nova.east.admin, nova.west.admin, nova.north.admin .)?
(Can we think of adding an optional endpoint_id attribute in role
data model to allow such role, which is also needed to envision
endpoint scoped tokens for our use case)
{ role: { id: 76e72a, domain_id = --id--,(optional, if
present, role is named by specific domain) project_id = --id--,
(optional, if present, role is named by project) service_id =
--id--,(optional, if present, role is named by service)
endpoint_id = --id--,(optional, if present, role is named by
service) name: ---role_name---, (must be unique when combined
with domain, project and service ids) scope: {id: ---id---,
(resource_id) type: service | file | domain etc.,
endpoint:---endpoint--- } } }
For Adam's question We are not linking role names to service id.
(email attached) AT: These attributes are all optional and will not
stop anyone how don't want to included service_id or (any other
attribute) for role name uniqueness. So in particular deployment want
to keep just the role name unique, this model will not restrict you.
Unnecessary. You are basically putting in documentation about how they
are to be enforced, which does not belong there.
Just do the basic: allow for the role naming to be nested under
projects and domains, and use that to support your use case.
This discussion is taking up too much time and effort. Please stop
trying to make it more complex than necessary.
AT: We are not putting in documentation but we are trying to come up with
generic role data model so that it will support all (private and public cloud)
of our role needs as explained in BP and extensible.
If you really have a solution for all the problems listed in below BPs, please
draft it and present in detail.
So far, two high level ideas (nested role-def and name space) proposed by you
are not helping which is clear.
https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.
I will appreciate and definitely consider them if they will resolve our
problems.
Thoughts?
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December 10, 2013
1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing
List (not for usage questions) Cc: Henry Nash;
dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev]
[keystone] Service scoped role definition
How about the following which clearly separates naming and scoping
constraints
{ role: { id: 76e72a, domain_id = --id--,(optional, if
present, role is named by specific domain) project_id = --id--,
(optional, if present, role is named by project) service_id =
--id--,(optional, if present, role is named by service) name:
---role_name---, (must be unique when combined with domain,
project and service ids) scope: {id: ---id---, (resource_id)
type: service | file | domain etc., endpoint:---endpoint---
} } }
regards
David
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David,
I have updated the ether pad with below comments.
Regards,
Arvind
Another alternative is to change role name into role display name, indicating
that the string is only to be used in GUIs, is not guaranteed to be unique, is
set by the role creator, can be any string in any character set, and is not
used by the system anywhere (AT1). Only role ID is used by the system, in
policy evaluation, in user-role assignments, in permission-role assignments
etc. (AT2)
AT1 -
1. Display name proposal does not seems to work because, we cannot enforce
service (e.g. Nova, Swift) to use role_id to define their policy.
AT2 -
1. Using role_id for policy evaluation is doable but it will be an
enormous impact on token data structure, policy etc, which won't be
acceptable to community.
2. permission-role assignments goes with policy file which is again not
acceptable due to same reason as #1.
3. user-role (or group-role) assignments uses the role_id, so there won't
be any change.
I think we should consider composite key to make the role entity unique and
keep having duplicate role_names in system. Something as below
{
role: {
id: 76e72a,
name: ---role_name---, (resource name spaced name e.g.
nova.east.admin)
scope: {
id: ---id---, (resource_id)
type: service | file | domain etc.,
endpoint:---endpoint---
}
domain_id = --id--,(optional)
project_id = --id--(optional)
}
}
Fields name, scope.id, domain_id and project_id makes the composite key.
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Monday, December 09, 2013 1:28 PM
To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
On 12/09/2013 03:04 PM, David Chadwick wrote:
On 09/12/2013 19:37, Adam Young wrote:
On 12/06/2013 04:44 AM, David Chadwick wrote:
Another alternative is to change role name into role display name,
indicating that the string is only to be used in GUIs, is not guaranteed
to be unique, is set by the role creator, can be any string in any
character set, and is not used by the system anywhere. Only role ID is
used by the system, in policy evaluation, in user-role assignments, in
permission-role assignments etc.
That will make policy much harder to read. I'd recommend that the role
name continue to be the good name, for both UI and for policy
enforcement.
in which case all role names must be unique
David
Hat is my understanding, yes, and I think that your proposal covers
that. A role name for policy will be the full name, for example
domain/project/role in the 3 portion version you posted.
regards
David
On 05/12/2013 16:21, Tiwari, Arvind wrote:
Hi David,
Let me capture these details in ether pad. I will drop an email after
adding these details in etherpad.
Thanks,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Thursday, December 05, 2013 4:15 AM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List
(not for usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
we are making good progress, but what I dont like about your proposal
below is that the role name is not unique. There can be multiple roles
with the same name, but different IDs, and different scopes. I dont like
this, and I think it would be confusing to users/administrators. I think
the role names should be different as well. This is not difficult to
engineer if the names are hierarchically structured based on the name of
the role creator. The creator might be owner of the resource that is
being scoped, but it need not necessarily be. Assuming it was, then in
your examples below we might have role names of NovaEast.admin and
NovaWest.admin. Since these are strings, policies can be easily adapted
to match on NovaWest.admin instead of admin.
regards
david
On 04/12/2013 17:21, Tiwari, Arvind wrote:
Hi Adam,
I have added my comments in line.
As per my request yesterday and David's proposal, following role-def
data model is looks generic enough and seems innovative to
accommodate future extensions.
{
role: {
id: 76e72a,
name: admin, (you can give whatever name you like)
scope: {
id: ---id--, (ID should be 1 to 1 mapped with resource
in type and must be immutable value)
type: service | file | domain etc., (Type can be any type
of resource which explains the scoping context)
interface:--interface-- (We are still need working on
this field. My idea of this optional field is to indicate the
interface of the resource (endpoint for service, path for File,)
for which the role-def is created
Re: [openstack-dev] [keystone] Service scoped role definition
I think that make sense, how does below data model looks?
{
role: {
id: 76e72a,
name: ---role_name---, (resource name spaced name e.g.
nova.east.admin)
scope: {
id: ---id---, (resource_id)
type: service | file | domain etc.,
endpoint:---endpoint---
}
domain_id = --id--, (optional)
project_id = --id--, (optional)
service_id = --id-- (optional)
}
}
Q. what if two (or more) endpoints want to have same role_name for a service
(nova.east.admin, nova.west.admin, nova.north.admin .)?
Regards,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Monday, December 09, 2013 3:15 PM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
this is still mixing up two separate concepts: naming and policy
constraints. Scope is a policy constraint but in the proposal below is
also part of the unique naming of the role. The fields making up both
concepts need to be separate (e.g. what if 2 different roles from the
same domain and project applied to two different scopes but it just so
happened that the ids of the two resources were the same? They would end
up still having the same unique name.)
I would therefore add service_id = --id-- (optional)
after project_id. This can assure that (composite) role names (keys) are
unique
regards
David
On 09/12/2013 20:36, Tiwari, Arvind wrote:
Hi David,
I have updated the ether pad with below comments.
Regards,
Arvind
Another alternative is to change role name into role display name,
indicating that the string is only to be used in GUIs, is not guaranteed to
be unique, is set by the role creator, can be any string in any character
set, and is not used by the system anywhere (AT1). Only role ID is used by
the system, in policy evaluation, in user-role assignments, in
permission-role assignments etc. (AT2)
AT1 -
1.Display name proposal does not seems to work because, we cannot enforce
service (e.g. Nova, Swift) to use role_id to define their policy.
AT2 -
1.Using role_id for policy evaluation is doable but it will be an
enormous impact on token data structure, policy etc, which won't be
acceptable to community.
2.permission-role assignments goes with policy file which is again not
acceptable due to same reason as #1.
3.user-role (or group-role) assignments uses the role_id, so there won't
be any change.
I think we should consider composite key to make the role entity unique and
keep having duplicate role_names in system. Something as below
{
role: {
id: 76e72a,
name: ---role_name---, (resource name spaced name e.g.
nova.east.admin)
scope: {
id: ---id---, (resource_id)
type: service | file | domain etc.,
endpoint:---endpoint---
}
domain_id = --id--, (optional)
project_id = --id-- (optional)
}
}
Fields name, scope.id, domain_id and project_id makes the composite key.
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Monday, December 09, 2013 1:28 PM
To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not
for usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
On 12/09/2013 03:04 PM, David Chadwick wrote:
On 09/12/2013 19:37, Adam Young wrote:
On 12/06/2013 04:44 AM, David Chadwick wrote:
Another alternative is to change role name into role display name,
indicating that the string is only to be used in GUIs, is not guaranteed
to be unique, is set by the role creator, can be any string in any
character set, and is not used by the system anywhere. Only role ID is
used by the system, in policy evaluation, in user-role assignments, in
permission-role assignments etc.
That will make policy much harder to read. I'd recommend that the role
name continue to be the good name, for both UI and for policy
enforcement.
in which case all role names must be unique
David
Hat is my understanding, yes, and I think that your proposal covers
that. A role name for policy will be the full name, for example
domain/project/role in the 3 portion version you posted.
regards
David
On 05/12/2013 16:21, Tiwari, Arvind wrote:
Hi David,
Let me capture these details in ether pad. I will drop an email after
adding these details in etherpad.
Thanks,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Thursday, December 05, 2013 4:15 AM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List
(not for usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David,
Let me capture these details in ether pad. I will drop an email after adding
these details in etherpad.
Thanks,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Thursday, December 05, 2013 4:15 AM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
we are making good progress, but what I dont like about your proposal
below is that the role name is not unique. There can be multiple roles
with the same name, but different IDs, and different scopes. I dont like
this, and I think it would be confusing to users/administrators. I think
the role names should be different as well. This is not difficult to
engineer if the names are hierarchically structured based on the name of
the role creator. The creator might be owner of the resource that is
being scoped, but it need not necessarily be. Assuming it was, then in
your examples below we might have role names of NovaEast.admin and
NovaWest.admin. Since these are strings, policies can be easily adapted
to match on NovaWest.admin instead of admin.
regards
david
On 04/12/2013 17:21, Tiwari, Arvind wrote:
Hi Adam,
I have added my comments in line.
As per my request yesterday and David's proposal, following role-def data
model is looks generic enough and seems innovative to accommodate future
extensions.
{
role: {
id: 76e72a,
name: admin, (you can give whatever name you like)
scope: {
id: ---id--, (ID should be 1 to 1 mapped with resource in type and
must be immutable value)
type: service | file | domain etc., (Type can be any type of
resource which explains the scoping context)
interface:--interface-- (We are still need working on this field.
My idea of this optional field is to indicate the interface of the resource
(endpoint for service, path for File,) for which the role-def is
created and can be empty.)
}
}
}
Based on above data model two admin roles for nova for two separate region wd
be as below
{
role: {
id: 76e71a,
name: admin,
scope: {
id: 110, (suppose 110 is Nova serviceId)
interface: 1101, (suppose 1101 is Nova region East endpointId)
type: service
}
}
}
{
role: {
id: 76e72a,
name: admin,
scope: {
id: 110,
interface: 1102,(suppose 1102 is Nova region West endpointId)
type: service
}
}
}
This way we can keep role-assignments abstracted from resource on which the
assignment is created. This also open doors to have service and/or endpoint
scoped token as I mentioned in https://etherpad.openstack.org/p/1Uiwcbfpxq.
David, I have updated
https://etherpad.openstack.org/p/service-scoped-role-definition line #118
explaining the rationale behind the field.
I wd also appreciate your vision on
https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.
Thanks,
Arvind
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Tuesday, December 03, 2013 6:52 PM
To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage
questions)
Cc: Henry Nash; dolph.math...@gmail.com; David Chadwick
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
I've been thinking about your comment that nested roles are confusing
AT: Thanks for considering my comment about nested role-def.
What if we backed off and said the following:
Some role-definitions are owned by services. If a Role definition is
owned by a service, in role assignment lists in tokens, those roles we
be prefixd by the service name. / is a reserved cahracter and weill be
used as the divider between segments of the role definition
That drops arbitrary nesting, and provides a reasonable namespace. Then
a role def would look like:
glance/admin for the admin role on the glance project.
AT: It seems this approach is not going to help, service rename would impact
all the role-def for a particular service. And we are back to the same
problem.
In theory, we could add the domain to the namespace, but that seems
unwieldy. If we did, a role def would then look like this
default/glance/admin for the admin role on the glance project.
Is that clearer than the nested roles?
AT: It is defiantly clearer but it will create same problems as what we are
trying to fix.
On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
Hi Adam,
Based on our discussion over IRC, I have updated the below etherpad with
proposal for nested role definition
https://etherpad.openstack.org/p/service-scoped-role-definition
Please take a look @ Proposal (Ayoung) - Nested role
Re: [openstack-dev] [keystone] Service scoped role definition
All,
I have captured almost all the email conversation (between Arvind, David and
Adam) in the etherpad (line #54 - 126 ) and moved old conversation under line
#130.
https://etherpad.openstack.org/p/service-scoped-role-definition
In the beginning (line # 1 to 51), I have captured where we are right now and
open questions along with my thoughts.
Please take a look and share your comments/suggestion.
Regards,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Thursday, December 05, 2013 5:45 AM
To: Tiwari, Arvind; Adam Young
Cc: OpenStack Development Mailing List (not for usage questions);
dolph.math...@gmail.com
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Almost, but not quite. The role name cannot be anything you like. It
must be globally unique, and named hierarchically. There is a proposal
in another message of this thread for what this could be, based on a 4
component naming scheme with / separators.
regards
david
On 04/12/2013 19:42, Tiwari, Arvind wrote:
Thanks David,
Appended line # 119 with my reply. endpoint sounds perfect to me.
In a nutshell we are agreeing on following new data model for role-def.
{
role: {
id: 76e72a,
name: admin, (you can give whatever name you like)
scope: {
id: ---id--, (ID should be 1 to 1 mapped with resource in type and
must be immutable value)
type: service | file | domain etc., (Type can be any type of
resource which explains the scoping context)
endpoint:-- endpoint-- (An optional field to indicate the
interface of the resource (endpoint for service, path for File,) for
which the role-def is created.)
}
}
}
If other community members are cool with this, I will start drafting the API
specs?
Regards,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Wednesday, December 04, 2013 11:42 AM
To: Tiwari, Arvind; Adam Young
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
On 04/12/2013 17:28, Tiwari, Arvind wrote:
Hi David,
Thanks for your valuable comments.
I have updated
https://etherpad.openstack.org/p/service-scoped-role-definition line
#118 explaining the rationale behind the field.
#119 for my reply
I wd also appreciate your thoughts on
https://etherpad.openstack.org/p/1Uiwcbfpxq too,
I have added a comment to the original bug report -
https://bugs.launchpad.net/keystone/+bug/968696
I think you should be going for simplifying Keystone's RBAC model rather
than making it more complex. In essence this would mean that assigning
permissions to roles and users to roles are separate and independent
processes and that roles on creation do not have to have any baggage or
restrictions tied to them. Here are my suggestions:
1. Allow different entities to create roles, and use hierarchical role
naming to maintain global uniqueness and to show which entity created
(owns) the role definition. Creating a role does not imply anything
about a role's subsequent permissions unless a scope field is included
in the definition.
2. When a role is created allow the creator to optionally add a scope
field which will limit the permissions that can be assigned to the role
to the prescribed scope.
3. Permissions will be assigned to roles in policy files by resource
owners. The can assign any permissions to their resources to the role
that they want to, except that they cannot override the scope field (ie.
grant permissions to resources which are out of the role's scope).
4. Remove any linkage of roles to tenants/projects on creation. This is
unnecessary baggage and only complicates the model for no good
functional reason.
regards
David
which is support
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens
BP.
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013
2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not
for usage questions); Adam Young Subject: Re: [openstack-dev]
[keystone] Service scoped role definition
I have added comments 111 to 122
david
On 03/12/2013 23:58, Tiwari, Arvind wrote:
Hi David,
I have added my comments underneath line # 97 till line #110, it is
mostly aligned with your proposal with some modification.
https://etherpad.openstack.org/p/service-scoped-role-definition
Thanks for your time, Arvind
-Original Message- From: Tiwari, Arvind Sent: Monday,
December 02, 2013 4:22 PM To: Adam Young; OpenStack Development
Mailing List (not for usage questions); David Chadwick Subject: Re:
[openstack-dev] [keystone] Service scoped role definition
Hi Adam and David,
Thank you so much for all the great comments, seems we are making
good progress.
I have replied
Re: [openstack-dev] [keystone] Service scoped role definition
Hi Adam,
I have added my comments in line.
As per my request yesterday and David's proposal, following role-def data model
is looks generic enough and seems innovative to accommodate future extensions.
{
role: {
id: 76e72a,
name: admin, (you can give whatever name you like)
scope: {
id: ---id--, (ID should be 1 to 1 mapped with resource in type and
must be immutable value)
type: service | file | domain etc., (Type can be any type of resource
which explains the scoping context)
interface:--interface-- (We are still need working on this field. My
idea of this optional field is to indicate the interface of the resource
(endpoint for service, path for File,) for which the role-def is
created and can be empty.)
}
}
}
Based on above data model two admin roles for nova for two separate region wd
be as below
{
role: {
id: 76e71a,
name: admin,
scope: {
id: 110, (suppose 110 is Nova serviceId)
interface: 1101, (suppose 1101 is Nova region East endpointId)
type: service
}
}
}
{
role: {
id: 76e72a,
name: admin,
scope: {
id: 110,
interface: 1102,(suppose 1102 is Nova region West endpointId)
type: service
}
}
}
This way we can keep role-assignments abstracted from resource on which the
assignment is created. This also open doors to have service and/or endpoint
scoped token as I mentioned in https://etherpad.openstack.org/p/1Uiwcbfpxq.
David, I have updated
https://etherpad.openstack.org/p/service-scoped-role-definition line #118
explaining the rationale behind the field.
I wd also appreciate your vision on https://etherpad.openstack.org/p/1Uiwcbfpxq
too which is support
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.
Thanks,
Arvind
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Tuesday, December 03, 2013 6:52 PM
To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; David Chadwick
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
I've been thinking about your comment that nested roles are confusing
AT: Thanks for considering my comment about nested role-def.
What if we backed off and said the following:
Some role-definitions are owned by services. If a Role definition is
owned by a service, in role assignment lists in tokens, those roles we
be prefixd by the service name. / is a reserved cahracter and weill be
used as the divider between segments of the role definition
That drops arbitrary nesting, and provides a reasonable namespace. Then
a role def would look like:
glance/admin for the admin role on the glance project.
AT: It seems this approach is not going to help, service rename would impact
all the role-def for a particular service. And we are back to the same problem.
In theory, we could add the domain to the namespace, but that seems
unwieldy. If we did, a role def would then look like this
default/glance/admin for the admin role on the glance project.
Is that clearer than the nested roles?
AT: It is defiantly clearer but it will create same problems as what we are
trying to fix.
On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
Hi Adam,
Based on our discussion over IRC, I have updated the below etherpad with
proposal for nested role definition
https://etherpad.openstack.org/p/service-scoped-role-definition
Please take a look @ Proposal (Ayoung) - Nested role definitions, I am
sorry if I could not catch your idea.
Feel free to update the etherpad.
Regards,
Arvind
-Original Message-
From: Tiwari, Arvind
Sent: Tuesday, November 26, 2013 4:08 PM
To: David Chadwick; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi David,
Thanks for your time and valuable comments. I have replied to your comments
and try to explain why I am advocating to this BP.
Let me know your thoughts, please feel free to update below etherpad
https://etherpad.openstack.org/p/service-scoped-role-definition
Thanks again,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Monday, November 25, 2013 12:12 PM
To: Tiwari, Arvind; OpenStack Development Mailing List
Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi Arvind
I have just added some comments to your blueprint page
regards
David
On 19/11/2013 00:01, Tiwari, Arvind wrote:
Hi,
Based on our discussion in design summit , I have redone the service_id
binding with roles BP
https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition.
I have added a new BP (link below) along with detailed use case to
support this BP.
https://blueprints.launchpad.net
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David, Thanks for your valuable comments. I have updated https://etherpad.openstack.org/p/service-scoped-role-definition line #118 explaining the rationale behind the field. I wd also appreciate your thoughts on https://etherpad.openstack.org/p/1Uiwcbfpxq too, which is support https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP. Thanks, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013 2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions); Adam Young Subject: Re: [openstack-dev] [keystone] Service scoped role definition I have added comments 111 to 122 david On 03/12/2013 23:58, Tiwari, Arvind wrote: Hi David, I have added my comments underneath line # 97 till line #110, it is mostly aligned with your proposal with some modification. https://etherpad.openstack.org/p/service-scoped-role-definition Thanks for your time, Arvind -Original Message- From: Tiwari, Arvind Sent: Monday, December 02, 2013 4:22 PM To: Adam Young; OpenStack Development Mailing List (not for usage questions); David Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Adam and David, Thank you so much for all the great comments, seems we are making good progress. I have replied to your comments and also added some to support my proposal https://etherpad.openstack.org/p/service-scoped-role-definition David, I like your suggestion for role-def scoping which can fit in my Plan B and I think Adam is cool with plan B. Please let me know if David's proposal for role-def scoping is cool for everybody? Thanks, Arvind -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, November 27, 2013 8:44 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions) Cc: Henry Nash; dolph.math...@gmail.com; David Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped role definition On 11/26/2013 06:57 PM, Tiwari, Arvind wrote: Hi Adam, Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition Updated. I made my changes Green. It isn't easy being green. https://etherpad.openstack.org/p/service-scoped-role-definition Please take a look @ Proposal (Ayoung) - Nested role definitions, I am sorry if I could not catch your idea. Feel free to update the etherpad. Regards, Arvind -Original Message- From: Tiwari, Arvind Sent: Tuesday, November 26, 2013 4:08 PM To: David Chadwick; OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi David, Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP. Let me know your thoughts, please feel free to update below etherpad https://etherpad.openstack.org/p/service-scoped-role-definition Thanks again, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Arvind I have just added some comments to your blueprint page regards David On 19/11/2013 00:01, Tiwari, Arvind wrote: Hi, Based on our discussion in design summit , I have redone the service_id binding with roles BP https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition. I have added a new BP (link below) along with detailed use case to support this BP. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition Below etherpad link has some proposals for Role REST representation and pros and cons analysis https://etherpad.openstack.org/p/service-scoped-role-definition Please take look and let me know your thoughts. It would be awesome if we can discuss it in tomorrow's meeting. Thanks, Arvind ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David, The biggest problems in my opinion are, 1. We are overloading and adding extra complexities on role name to maintain the generalization for role-def data model. 2. Name spacing the role name is not going to resolve all the issues listed in BP. 3. All the namespaces are derived from mutable string (domain name, project name, service name etc...) which makes the role name fragile. I think it is time to break generic role-def data model to accommodate more specialized use cases. Thanks, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013 10:41 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions) Cc: Henry Nash; dolph.math...@gmail.com Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Adam I understand your problem: having projects and services which have the same name, then the lineage of a role containing this name is not deterministically known without some other rule or syntax that can differentiate between the two. Since domains contain projects which contain services then isnt the containment hierarchy already known and predetermined? If it is then: 4 name components mean it is a service specified role 3 name components mean it is a project specified role 2 name components mean it is a domain specified role 1 name component means it is globally named role (from the default domain) a null string means the default domain or all projects in a domain. You would never have null for a service name. admin means the global admin role /admin ditto x/admin means the admin of the X domain x/y/admin means the admin role for the y project in domain x //x/admin means admin for service x from the default domain etc. will that work? regards David On 04/12/2013 15:04, Adam Young wrote: On 12/04/2013 04:08 AM, David Chadwick wrote: I am happy with this as far as it goes. I would like to see it being made more general, where domains, services and projects can also own and name roles Domains should be OK, but services would confuse the matter. You'd have to end up with something like LDAP role= domain=default,service=glance vs role= domain=default,project=glance unless we have unambiguous implicit ordering, we'll need to make it explicit, which is messy. I'd rather do: One segment: globally defined roles. These could also be considered roles defined in the default domain. Two segments service defined roles in the default domain Three Segments, service defined roles from non-default domain To do domain scoped roles we could do something like: domX//admin But It seems confusing. Perhaps a better approach for project roles is to have the rule that the default domain can show up as an empty string. Thus, project scoped roles from the default domain would be: \glance\admin and from a non default domain domX\glance\admin regards David On 04/12/2013 01:51, Adam Young wrote: I've been thinking about your comment that nested roles are confusing What if we backed off and said the following: Some role-definitions are owned by services. If a Role definition is owned by a service, in role assignment lists in tokens, those roles we be prefixd by the service name. / is a reserved cahracter and weill be used as the divider between segments of the role definition That drops arbitrary nesting, and provides a reasonable namespace. Then a role def would look like: glance/admin for the admin role on the glance project. In theory, we could add the domain to the namespace, but that seems unwieldy. If we did, a role def would then look like this default/glance/admin for the admin role on the glance project. Is that clearer than the nested roles? On 11/26/2013 06:57 PM, Tiwari, Arvind wrote: Hi Adam, Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition https://etherpad.openstack.org/p/service-scoped-role-definition Please take a look @ Proposal (Ayoung) - Nested role definitions, I am sorry if I could not catch your idea. Feel free to update the etherpad. Regards, Arvind -Original Message- From: Tiwari, Arvind Sent: Tuesday, November 26, 2013 4:08 PM To: David Chadwick; OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi David, Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP. Let me know your thoughts, please feel free to update below etherpad https://etherpad.openstack.org/p/service-scoped-role-definition Thanks again, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List Cc: Henry Nash; ayo
Re: [openstack-dev] [keystone] Service scoped role definition
Thanks David,
Appended line # 119 with my reply. endpoint sounds perfect to me.
In a nutshell we are agreeing on following new data model for role-def.
{
role: {
id: 76e72a,
name: admin, (you can give whatever name you like)
scope: {
id: ---id--, (ID should be 1 to 1 mapped with resource in type and
must be immutable value)
type: service | file | domain etc., (Type can be any type of resource
which explains the scoping context)
endpoint:-- endpoint-- (An optional field to indicate the interface
of the resource (endpoint for service, path for File,) for which the
role-def is created.)
}
}
}
If other community members are cool with this, I will start drafting the API
specs?
Regards,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Wednesday, December 04, 2013 11:42 AM
To: Tiwari, Arvind; Adam Young
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
On 04/12/2013 17:28, Tiwari, Arvind wrote:
Hi David,
Thanks for your valuable comments.
I have updated
https://etherpad.openstack.org/p/service-scoped-role-definition line
#118 explaining the rationale behind the field.
#119 for my reply
I wd also appreciate your thoughts on
https://etherpad.openstack.org/p/1Uiwcbfpxq too,
I have added a comment to the original bug report -
https://bugs.launchpad.net/keystone/+bug/968696
I think you should be going for simplifying Keystone's RBAC model rather
than making it more complex. In essence this would mean that assigning
permissions to roles and users to roles are separate and independent
processes and that roles on creation do not have to have any baggage or
restrictions tied to them. Here are my suggestions:
1. Allow different entities to create roles, and use hierarchical role
naming to maintain global uniqueness and to show which entity created
(owns) the role definition. Creating a role does not imply anything
about a role's subsequent permissions unless a scope field is included
in the definition.
2. When a role is created allow the creator to optionally add a scope
field which will limit the permissions that can be assigned to the role
to the prescribed scope.
3. Permissions will be assigned to roles in policy files by resource
owners. The can assign any permissions to their resources to the role
that they want to, except that they cannot override the scope field (ie.
grant permissions to resources which are out of the role's scope).
4. Remove any linkage of roles to tenants/projects on creation. This is
unnecessary baggage and only complicates the model for no good
functional reason.
regards
David
which is support
https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens
BP.
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013
2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not
for usage questions); Adam Young Subject: Re: [openstack-dev]
[keystone] Service scoped role definition
I have added comments 111 to 122
david
On 03/12/2013 23:58, Tiwari, Arvind wrote:
Hi David,
I have added my comments underneath line # 97 till line #110, it is
mostly aligned with your proposal with some modification.
https://etherpad.openstack.org/p/service-scoped-role-definition
Thanks for your time, Arvind
-Original Message- From: Tiwari, Arvind Sent: Monday,
December 02, 2013 4:22 PM To: Adam Young; OpenStack Development
Mailing List (not for usage questions); David Chadwick Subject: Re:
[openstack-dev] [keystone] Service scoped role definition
Hi Adam and David,
Thank you so much for all the great comments, seems we are making
good progress.
I have replied to your comments and also added some to support my
proposal
https://etherpad.openstack.org/p/service-scoped-role-definition
David, I like your suggestion for role-def scoping which can fit in
my Plan B and I think Adam is cool with plan B.
Please let me know if David's proposal for role-def scoping is cool
for everybody?
Thanks, Arvind
-Original Message- From: Adam Young
[mailto:ayo...@redhat.com] Sent: Wednesday, November 27, 2013 8:44
AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for
usage questions) Cc: Henry Nash; dolph.math...@gmail.com; David
Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped
role definition
On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
Hi Adam,
Based on our discussion over IRC, I have updated the below
etherpad with proposal for nested role definition
Updated. I made my changes Green. It isn't easy being green.
https://etherpad.openstack.org/p/service-scoped-role-definition
Please take a look @ Proposal (Ayoung) - Nested role
definitions, I am sorry if I could not catch your idea.
Feel
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David, I have added my comments underneath line # 97 till line #110, it is mostly aligned with your proposal with some modification. https://etherpad.openstack.org/p/service-scoped-role-definition Thanks for your time, Arvind -Original Message- From: Tiwari, Arvind Sent: Monday, December 02, 2013 4:22 PM To: Adam Young; OpenStack Development Mailing List (not for usage questions); David Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Adam and David, Thank you so much for all the great comments, seems we are making good progress. I have replied to your comments and also added some to support my proposal https://etherpad.openstack.org/p/service-scoped-role-definition David, I like your suggestion for role-def scoping which can fit in my Plan B and I think Adam is cool with plan B. Please let me know if David's proposal for role-def scoping is cool for everybody? Thanks, Arvind -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, November 27, 2013 8:44 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions) Cc: Henry Nash; dolph.math...@gmail.com; David Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped role definition On 11/26/2013 06:57 PM, Tiwari, Arvind wrote: Hi Adam, Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition Updated. I made my changes Green. It isn't easy being green. https://etherpad.openstack.org/p/service-scoped-role-definition Please take a look @ Proposal (Ayoung) - Nested role definitions, I am sorry if I could not catch your idea. Feel free to update the etherpad. Regards, Arvind -Original Message- From: Tiwari, Arvind Sent: Tuesday, November 26, 2013 4:08 PM To: David Chadwick; OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi David, Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP. Let me know your thoughts, please feel free to update below etherpad https://etherpad.openstack.org/p/service-scoped-role-definition Thanks again, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Arvind I have just added some comments to your blueprint page regards David On 19/11/2013 00:01, Tiwari, Arvind wrote: Hi, Based on our discussion in design summit , I have redone the service_id binding with roles BP https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition. I have added a new BP (link below) along with detailed use case to support this BP. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition Below etherpad link has some proposals for Role REST representation and pros and cons analysis https://etherpad.openstack.org/p/service-scoped-role-definition Please take look and let me know your thoughts. It would be awesome if we can discuss it in tomorrow's meeting. Thanks, Arvind ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Hi Adam and David, Thank you so much for all the great comments, seems we are making good progress. I have replied to your comments and also added some to support my proposal https://etherpad.openstack.org/p/service-scoped-role-definition David, I like your suggestion for role-def scoping which can fit in my Plan B and I think Adam is cool with plan B. Please let me know if David's proposal for role-def scoping is cool for everybody? Thanks, Arvind -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: Wednesday, November 27, 2013 8:44 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions) Cc: Henry Nash; dolph.math...@gmail.com; David Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped role definition On 11/26/2013 06:57 PM, Tiwari, Arvind wrote: Hi Adam, Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition Updated. I made my changes Green. It isn't easy being green. https://etherpad.openstack.org/p/service-scoped-role-definition Please take a look @ Proposal (Ayoung) - Nested role definitions, I am sorry if I could not catch your idea. Feel free to update the etherpad. Regards, Arvind -Original Message- From: Tiwari, Arvind Sent: Tuesday, November 26, 2013 4:08 PM To: David Chadwick; OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi David, Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP. Let me know your thoughts, please feel free to update below etherpad https://etherpad.openstack.org/p/service-scoped-role-definition Thanks again, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Arvind I have just added some comments to your blueprint page regards David On 19/11/2013 00:01, Tiwari, Arvind wrote: Hi, Based on our discussion in design summit , I have redone the service_id binding with roles BP https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition. I have added a new BP (link below) along with detailed use case to support this BP. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition Below etherpad link has some proposals for Role REST representation and pros and cons analysis https://etherpad.openstack.org/p/service-scoped-role-definition Please take look and let me know your thoughts. It would be awesome if we can discuss it in tomorrow's meeting. Thanks, Arvind ___ 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
Re: [openstack-dev] [keystone] Service scoped role definition
Hi David, Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP. Let me know your thoughts, please feel free to update below etherpad https://etherpad.openstack.org/p/service-scoped-role-definition Thanks again, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Arvind I have just added some comments to your blueprint page regards David On 19/11/2013 00:01, Tiwari, Arvind wrote: Hi, Based on our discussion in design summit , I have redone the service_id binding with roles BP https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition. I have added a new BP (link below) along with detailed use case to support this BP. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition Below etherpad link has some proposals for Role REST representation and pros and cons analysis https://etherpad.openstack.org/p/service-scoped-role-definition Please take look and let me know your thoughts. It would be awesome if we can discuss it in tomorrow's meeting. Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Service scoped role definition
Hi Adam, Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition https://etherpad.openstack.org/p/service-scoped-role-definition Please take a look @ Proposal (Ayoung) - Nested role definitions, I am sorry if I could not catch your idea. Feel free to update the etherpad. Regards, Arvind -Original Message- From: Tiwari, Arvind Sent: Tuesday, November 26, 2013 4:08 PM To: David Chadwick; OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi David, Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP. Let me know your thoughts, please feel free to update below etherpad https://etherpad.openstack.org/p/service-scoped-role-definition Thanks again, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Monday, November 25, 2013 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List Cc: Henry Nash; ayo...@redhat.com; dolph.math...@gmail.com; Yee, Guang Subject: Re: [openstack-dev] [keystone] Service scoped role definition Hi Arvind I have just added some comments to your blueprint page regards David On 19/11/2013 00:01, Tiwari, Arvind wrote: Hi, Based on our discussion in design summit , I have redone the service_id binding with roles BP https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition. I have added a new BP (link below) along with detailed use case to support this BP. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition Below etherpad link has some proposals for Role REST representation and pros and cons analysis https://etherpad.openstack.org/p/service-scoped-role-definition Please take look and let me know your thoughts. It would be awesome if we can discuss it in tomorrow's meeting. Thanks, Arvind ___ 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
[openstack-dev] [keystone] Service scoped role definition
Hi, Based on our discussion in design summit , I have redone the service_id binding with roles BPhttps://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition. I have added a new BP (link below) along with detailed use case to support this BP. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition Below etherpad link has some proposals for Role REST representation and pros and cons analysis https://etherpad.openstack.org/p/service-scoped-role-definition Please take look and let me know your thoughts. It would be awesome if we can discuss it in tomorrow's meeting. Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] Does authorization not needed on “/auth/tokens” API??
Thanks David. Since we are discussing authorization and access control, I would like to gain little attention on the below bug which basically propose authorization check on identity:check_token, identity:validate_token and identity:revoke_token APIs https://bugs.launchpad.net/keystone/+bug/1186059 Due to absence of a target on such API calls Auth is not possible, I would appreciate community's thoughts on the bug. Thanks, Arvind -Original Message- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Thursday, July 25, 2013 4:10 AM To: OpenStack Development Mailing List Cc: Tiwari, Arvind Subject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities I have responded to your post, as I dont think it solves the identified problem regards David On 24/07/2013 23:26, Tiwari, Arvind wrote: I have added my proposal @ https://etherpad.openstack.org/api_policy_on_target. Thanks, Arvind -Original Message- From: Henry Nash [mailto:hen...@linux.vnet.ibm.com] Sent: Wednesday, July 24, 2013 8:46 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities I think we should transfer this discussion to the etherpad for this blueprint: https://etherpad.openstack.org/api_policy_on_target I have summarised the views of this thread there already, so let's make any further comments there, rather than here. Henry On 24 Jul 2013, at 00:29, Simo Sorce wrote: On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote: ...the problem is that if the object does not exists we might not be able tell whether the use is authorized or not (since authorization might depend on attributes of the object itself)so how do we know wether to lie or not? If the error you return is always 'Not Found', why do you care ? Simo. Henry On 23 Jul 2013, at 21:23, David Chadwick wrote: On 23/07/2013 19:02, Henry Nash wrote: One thing we could do is: - Return Forbidden or NotFound if we can determine the correct answer - When we can't (i.e. the object doesn't exist), then return NotFound unless a new config value 'policy_harden' (?) is set to true (default false) in which case we translate NotFound into Forbidden. I am not sure that this achieves your objective of no data leakage through error codes, does it? Its not a question of determining the correct answer or not, its a question of whether the user is authorised to see the correct answer or not regards David Henry On 23 Jul 2013, at 18:31, Adam Young wrote: On 07/23/2013 12:54 PM, David Chadwick wrote: When writing a previous ISO standard the approach we took was as follows Lie to people who are not authorised. Is that your verbage? I am going to reuse that quote, and I would like to get the attribution correct. So applying this approach to your situation, you could reply Not Found to people who are authorised to see the object if it had existed but does not, and Not Found to those not authorised to see it, regardless of whether it exists or not. In this case, only those who are authorised to see the object will get it if it exists. Those not authorised cannot tell the difference between objects that dont exist and those that do exist So, to try and apply this to a semi-real example: There are two types of URLs. Ones that are like this: users/55FEEDBABECAFE and ones like this: domain/66DEADBEEF/users/55FEEDBABECAFE In the first case, you are selecting against a global collection, and in the second, against a scoped collection. For unscoped, you have to treat all users as equal, and thus a 404 probably makes sense. For a scoped collection we could return a 404 or a 403 Forbidden https://en.wikipedia.org/wiki/HTTP_403 based on the users credentials: all resources under domain/66DEADBEEF would show up as 403s regardless of existantce or not if the user had no roles in the domain 66DEADBEEF. A user that would be allowed access to resources in 66DEADBEEF would get a 403 only for an object that existed but that they had no permission to read, and 404 for a resource that doesn't exist. regards David On 23/07/2013 16:40, Henry Nash wrote: Hi As part of bp https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target I have uploaded some example WIP code showing a proposed approach for just a few API calls (one easy, one more complex). I'd appreciate early feedback on this before I take it any further. https://review.openstack.org/#/c/38308/ A couple of points: - One question is on how to handle errors when you are going to get a target object before doing you policy check. What do you do if the object does not exist? If you return NotFound, then someone, who was not authorized could troll for the existence of entities by seeing whether they got NotFound or Forbidden. If however, you return
Re: [openstack-dev] [barbican]
. On the backend, Barbican will support the use of KMIP to talk to whatever device the provider wishes to deploy. We will also support other interaction mechanisms including PKCS through OpenSSH, a development implementation and a fully free and open source software implementation. This also allows some advanced uses cases including federation. Federation will allow customers of public clouds like Rackspace's to maintain custody of their keys while still being able to delegate their use to the Cloud for specific tasks. I've been asked about KMIP support at the Summit and by several of Rackspace's partners. I was planning on getting to it at some point, probably after Icehouse. This is mostly due to the fact that we didn't find a suitable KMIP implementation for Python so it looks like we'd have to write one. If there is interest from people to create that implementation, we'd be happy to help do the work to integrate it into Barbican. We just released our M2 milestone and we are on track for our 1.0 release for Havana. I would encourage anyone interested to check our what we are working on and come help us out. We use this list for most of our discussions and we hang out on #openstack-cloudkeep on free node. From: Tiwari, Arvind [mailto:arvind.tiw...@hp.com] Sent: Monday, July 22, 2013 11:22 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [barbican] Hi All, I am following Barbican project and I have some question around it, I would appreciate if someone can answer them or point me to the correct resource 1. What is the state of the project, is it in the state where it can be utilized in production deployments? 2.Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on. 3.Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far? Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Extending policy checking to include target entities
Hi Henry, Do you have etherpad to capture these stuff? Arvind -Original Message- From: Henry Nash [mailto:hen...@linux.vnet.ibm.com] Sent: Tuesday, July 23, 2013 4:48 PM To: David Chadwick Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities ...the problem is that if the object does not exists we might not be able tell whether the use is authorized or not (since authorization might depend on attributes of the object itself)so how do we know wether to lie or not? Henry On 23 Jul 2013, at 21:23, David Chadwick wrote: On 23/07/2013 19:02, Henry Nash wrote: One thing we could do is: - Return Forbidden or NotFound if we can determine the correct answer - When we can't (i.e. the object doesn't exist), then return NotFound unless a new config value 'policy_harden' (?) is set to true (default false) in which case we translate NotFound into Forbidden. I am not sure that this achieves your objective of no data leakage through error codes, does it? Its not a question of determining the correct answer or not, its a question of whether the user is authorised to see the correct answer or not regards David Henry On 23 Jul 2013, at 18:31, Adam Young wrote: On 07/23/2013 12:54 PM, David Chadwick wrote: When writing a previous ISO standard the approach we took was as follows Lie to people who are not authorised. Is that your verbage? I am going to reuse that quote, and I would like to get the attribution correct. So applying this approach to your situation, you could reply Not Found to people who are authorised to see the object if it had existed but does not, and Not Found to those not authorised to see it, regardless of whether it exists or not. In this case, only those who are authorised to see the object will get it if it exists. Those not authorised cannot tell the difference between objects that dont exist and those that do exist So, to try and apply this to a semi-real example: There are two types of URLs. Ones that are like this: users/55FEEDBABECAFE and ones like this: domain/66DEADBEEF/users/55FEEDBABECAFE In the first case, you are selecting against a global collection, and in the second, against a scoped collection. For unscoped, you have to treat all users as equal, and thus a 404 probably makes sense. For a scoped collection we could return a 404 or a 403 Forbidden https://en.wikipedia.org/wiki/HTTP_403 based on the users credentials: all resources under domain/66DEADBEEF would show up as 403s regardless of existantce or not if the user had no roles in the domain 66DEADBEEF. A user that would be allowed access to resources in 66DEADBEEF would get a 403 only for an object that existed but that they had no permission to read, and 404 for a resource that doesn't exist. regards David On 23/07/2013 16:40, Henry Nash wrote: Hi As part of bp https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target I have uploaded some example WIP code showing a proposed approach for just a few API calls (one easy, one more complex). I'd appreciate early feedback on this before I take it any further. https://review.openstack.org/#/c/38308/ A couple of points: - One question is on how to handle errors when you are going to get a target object before doing you policy check. What do you do if the object does not exist? If you return NotFound, then someone, who was not authorized could troll for the existence of entities by seeing whether they got NotFound or Forbidden. If however, you return Forbidden, then users who are authorized to, say, manage users in a domain would aways get Forbidden for objects that didn't exist (since we can know where the non-existant object was!). So this would modify the expected return codes. - I really think we need some good documentation on how to bud keystone policy files. I'm happy to take a first cut as such a thing - what do you think the right place is for such documentation ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 ___ OpenStack-dev mailing list
[openstack-dev] [barbican]
Hi All, I am following Barbican project and I have some question around it, I would appreciate if someone can answer them or point me to the correct resource 1. What is the state of the project, is it in the state where it can be utilized in production deployments? 2.Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on. 3.Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far? Thanks, Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New BP - ServiceId binding with role definition
All, Added etherpad link, please share your comments or suggestion https://etherpad.openstack.org/serviceid-binding-with-role-definition Arvind From: Tiwari, Arvind Sent: Wednesday, June 19, 2013 4:42 PM To: OpenStack Development Mailing List Subject: New BP - ServiceId binding with role definition All, I have added a new BP, which advocates service id binding with role definition https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition Please look at it and share your comments. Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] New BP - ServiceId binding with role definition
All, I have added a new BP, which advocates service id binding with role definition https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition Please look at it and share your comments. Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
