[openstack-dev] [trove] confused about trove-guestagent need nova's auth info
When using trove, we need to configure nova’s user information in the configuration file of trove-guestagent, such as l nova_proxy_admin_user l nova_proxy_admin_pass l nova_proxy_admin_tenant_name Is it necessary? In a public cloud environment, It will lead to serious security risks. I traced the code, and noticed that the auth data mentioned above is packaged in a context object, then passed to the trove-conductor via message queue. Is it more suitable for trove-conductor to get the corresponding information from its own conf file? Thanks! qiao___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] confused about trove-guestagent need nova's auth info
On 18/12/14 14:30, 乔建 wrote: When using trove, we need to configure nova’s user information in the configuration file of trove-guestagent, such as lnova_proxy_admin_user lnova_proxy_admin_pass lnova_proxy_admin_tenant_name Is it necessary? In a public cloud environment, It will lead to serious security risks. I traced the code, and noticed that the auth data mentioned above is packaged in a context object, then passed to the trove-conductor via message queue. Is it more suitable for trove-conductor to get the corresponding information from its own conf file? Yes - all good points. Experimenting with devstack Juno branch, it seems you can happily remove these three settings. However the guest agent does seem to need the rabbit host and password, which is probably undesirable for the same reasons that you mentioned above. Regards Mark __ 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
Re: [openstack-dev] [trove] confused about trove-guestagent need nova's auth info
Hello to all. On Sunday, January 11, 2015, Mark Kirkwood wrote: > On 18/12/14 14:30, 乔建 wrote: > >> When using trove, we need to configure nova’s user information in the >> configuration file of trove-guestagent, such as >> >> lnova_proxy_admin_user >> >> lnova_proxy_admin_pass >> >> lnova_proxy_admin_tenant_name >> >> >> >> >> Is it necessary? In a public cloud environment, It will lead to serious >> security risks. >> >> >> I traced the code, and noticed that the auth data mentioned above is >> packaged in a context object, then passed to the trove-conductor via >> message queue. >> >> Is it more suitable for trove-conductor to get the corresponding >> information from its own conf file? > > > Guest agent doesn't need configuration options described above. IIRC, only taskmanager needs them. About passing auth data. What are those benefits of changing the way in which auth data is shipped? If you still think of security risks - you may use SSL protocol that is available in most of messaging services. > Yes - all good points. Experimenting with devstack Juno branch, it seems > you can happily remove these three settings. > > However the guest agent does seem to need the rabbit host and password, > which is probably undesirable for the same reasons that you mentioned above. > > Regards > > Mark > > > __ > 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 > Kind regards, Denis M. __ 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
Re: [openstack-dev] [trove] confused about trove-guestagent need nova's auth info
On 11/01/15 22:25, Denis Makogon wrote: Guest agent doesn't need configuration options described above. IIRC, only taskmanager needs them. Right - so we need to update the default config files and doco - as they have them in there. About passing auth data. What are those benefits of changing the way in which auth data is shipped? If you still think of security risks - you may use SSL protocol that is available in most of messaging services. I guessing the original poster was thinking along these lines: breaking into the image gives the tenant access to privileged passwords. Whether the communication is SSL or not is another (interesting) factor. Regards Mark __ 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
