Re: [openstack-dev] [Fuel-dev] access-control-master-node
After some discussion on IRC we updated blueprint. Now it's available as review here https://review.openstack.org/#/c/96429/2 Nice looking version is here http://docs-draft.openstack.org/29/96429/3/check/gate-fuel-specs-docs/d5b32d5/doc/build/html/specs/5.1/access-control-master-node.html Blueprint was split into 4 stages so now we can implement it in smaller steps. Please comment. Regards, On Tue, May 27, 2014 at 8:41 PM, Andrew Woodward xar...@gmail.com wrote: AFIK, if we implement ironic as a replacement for cobbler, we will have Keystone on the fuel-master anyway. Supporting OAuth as an additional authentication entry would awesome too, but I'm not sure if there would be much demand over Keystone. On Tue, May 27, 2014 at 8:31 AM, Lukasz Oles lo...@mirantis.com wrote: There is some misunderstanding here. By using keystone I mean running keystone on fuel master node. After all it's just python program. It's used by OpenStack as authorization tool but it also can be used as standalone software or by different tools completely not connected with OpenStack. In future if want to use LDAP source, keystone already have plugin for it. Regards On Tue, May 27, 2014 at 5:08 PM, David Easter deas...@mirantis.com wrote: The other challenge of utilizing Keystone is which one to use. Fuel enables the deployment of multiple cloud environments from one UI; so when accessing the Fuel Master Node, it would be ambiguous which already deployed Keystone to contact for authentication. If/When Triple-O is utilized, one could perhaps see designating the Keystone of the undercloud; but that’s more a future requirement. For now, I’d suggest an internal authentication in the immediate short term. External auth sources can be added in future milestones – most likely an LDAP source that’s outside the deployed clouds and designated by IT. Thanks, - David J. Easter Director of Product Management, Mirantis From: Jesse Pretorius jesse.pretor...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, May 27, 2014 at 7:43 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel-dev] access-control-master-node On 27 May 2014 13:42, Lukasz Oles lo...@mirantis.com wrote: Hello fuelers, we(I and Kamil) would like start discussion about Enforce access control for Fuel UI blueprint https://blueprints.launchpad.net/fuel/+spec/access-control-master-node . First question to David, as he proposed this bp. Do you want to add more requirements? To all. What do you think about using keystone as authorization tool? We described all pros/cons in the specification. I would suggest both an internal authentication database and the option of plugging additional options in, with keystone being one of them and perhaps something like oauth being another. Keystone may not be available at the time of the build, or accessible from the network that's used for the initial build. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-...@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Łukasz Oleś -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-...@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Andrew Mirantis Ceph community -- Łukasz Oleś ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel-dev] access-control-master-node
Hello fuelers, we(I and Kamil) would like start discussion about Enforce access control for Fuel UI blueprint https://blueprints.launchpad.net/fuel/+spec/access-control-master-node. First question to David, as he proposed this bp. Do you want to add more requirements? To all. What do you think about using keystone as authorization tool? We described all pros/cons in the specification. Regards, -- Łukasz Oleś ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel-dev] access-control-master-node
On 27 May 2014 13:42, Lukasz Oles lo...@mirantis.com wrote: Hello fuelers, we(I and Kamil) would like start discussion about Enforce access control for Fuel UI blueprint https://blueprints.launchpad.net/fuel/+spec/access-control-master-node. First question to David, as he proposed this bp. Do you want to add more requirements? To all. What do you think about using keystone as authorization tool? We described all pros/cons in the specification. I would suggest both an internal authentication database and the option of plugging additional options in, with keystone being one of them and perhaps something like oauth being another. Keystone may not be available at the time of the build, or accessible from the network that's used for the initial build. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel-dev] access-control-master-node
The other challenge of utilizing Keystone is which one to use. Fuel enables the deployment of multiple cloud environments from one UI; so when accessing the Fuel Master Node, it would be ambiguous which already deployed Keystone to contact for authentication. If/When Triple-O is utilized, one could perhaps see designating the Keystone of the undercloud; but that¹s more a future requirement. For now, I¹d suggest an internal authentication in the immediate short term. External auth sources can be added in future milestones most likely an LDAP source that¹s outside the deployed clouds and designated by IT. Thanks, - David J. Easter Director of Product Management, Mirantis From: Jesse Pretorius jesse.pretor...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, May 27, 2014 at 7:43 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel-dev] access-control-master-node On 27 May 2014 13:42, Lukasz Oles lo...@mirantis.com wrote: Hello fuelers, we(I and Kamil) would like start discussion about Enforce access control for Fuel UI blueprint https://blueprints.launchpad.net/fuel/+spec/access-control-master-node. First question to David, as he proposed this bp. Do you want to add more requirements? To all. What do you think about using keystone as authorization tool? We described all pros/cons in the specification. I would suggest both an internal authentication database and the option of plugging additional options in, with keystone being one of them and perhaps something like oauth being another. Keystone may not be available at the time of the build, or accessible from the network that's used for the initial build. ___ 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] [Fuel-dev] access-control-master-node
There is some misunderstanding here. By using keystone I mean running keystone on fuel master node. After all it's just python program. It's used by OpenStack as authorization tool but it also can be used as standalone software or by different tools completely not connected with OpenStack. In future if want to use LDAP source, keystone already have plugin for it. Regards On Tue, May 27, 2014 at 5:08 PM, David Easter deas...@mirantis.com wrote: The other challenge of utilizing Keystone is which one to use. Fuel enables the deployment of multiple cloud environments from one UI; so when accessing the Fuel Master Node, it would be ambiguous which already deployed Keystone to contact for authentication. If/When Triple-O is utilized, one could perhaps see designating the Keystone of the undercloud; but that’s more a future requirement. For now, I’d suggest an internal authentication in the immediate short term. External auth sources can be added in future milestones – most likely an LDAP source that’s outside the deployed clouds and designated by IT. Thanks, - David J. Easter Director of Product Management, Mirantis From: Jesse Pretorius jesse.pretor...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, May 27, 2014 at 7:43 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel-dev] access-control-master-node On 27 May 2014 13:42, Lukasz Oles lo...@mirantis.com wrote: Hello fuelers, we(I and Kamil) would like start discussion about Enforce access control for Fuel UI blueprint https://blueprints.launchpad.net/fuel/+spec/access-control-master-node. First question to David, as he proposed this bp. Do you want to add more requirements? To all. What do you think about using keystone as authorization tool? We described all pros/cons in the specification. I would suggest both an internal authentication database and the option of plugging additional options in, with keystone being one of them and perhaps something like oauth being another. Keystone may not be available at the time of the build, or accessible from the network that's used for the initial build. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-...@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Łukasz Oleś ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
