As far as I know this feature is planned for the next releases.
But I think the main problem is: it's not obvious that just by
installing a plugin, even without enabling the plugin in Fuel user could
break or somehow alter already existing environments. It could be done
by malicious attacker who could compromise plugin or just
unintentionally with some bug in the plugin code.
Unfortunately, by installing some plugin a user jeopardizes his existing
environments. And I think we should at least document these risks.
On 07.12.2015 19:52, Javeria Khan wrote:
My two cents. It would be useful to have a role that could execute on
the Fuel Master host itself rather than a container.
--
Javeria
On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" <m...@romcheg.me
<mailto:m...@romcheg.me>> wrote:
Alexey,
thank you for bringing this up. IMO discussing security problems
is better to be done in a special kind of Launchpad bugs.
- romcheg
> 7 груд. 2015 р. о 17:36 Alexey Elagin <aela...@mirantis.com
<mailto:aela...@mirantis.com>> написав(ла):
>
> Hello all,
>
> We have a security problem in Fuel 7.0. It's related to plugin
> development and allows to execute code in mcollective docker
container
> on Fuel master node. Any fuel plugin may contains a yaml file with
> deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and
there is
> an ability to run some code on node with role "master". It's also
> possible to connect to any target node via ssh without a
password from
> within the container.
>
> As i understood, it was made to simplify some deployment cases.
I see
> some steps for resolving this situation:
> 1. Fuel team should disallow
> execution of any puppet manifests or bash code on nodes with master
> role.
> 2. Append the Fuel documentation. Notify users about this
> security issue.
>
> What do you think about it? What deployment cases which require
> execution of code on role "master" do you know?
>
> --
> Best regards,
> Alexey
> Deployment Engineer
> Mirantis, Inc
> Cell: +7 (968) 880 2288 <tel:%2B7%20%28968%29%20880%202288>
> Skype: shikelbober
> Slack: aelagin
> mailto:aela...@mirantis.com <mailto:aela...@mirantis.com>
>
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Eugene Korekin
Partner Enablement Team Deployment Engineer
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
