Open Stack

> For tripleo the first issue to address is in puppet-nova where the dbs
are currently configured for every nova service.
> The fix seems trivial - https://review.opendev.org/755689. I also think
that should be completely safe to backport this to all stable branches.
I don't know whether we can backport that to stable branches.
I agreed to remove nova::db from the base nova class because we already
deprecated database parameters in the nova class, but in stable branches
we have these parameters still valid and removal of nova::db can cause some
issues with these parameters. (I guess pick dosn't work if the nova class
was
defined AFTER nova::db class and there are no hieradata used)
So I'd say it's better to leave it in stable branches if nova doesn't
require
absence of db parameters in stable branches.

Note that we can remove these parameters from compute nodes in TripleO
deployment
if we completely remove these hieradata from compute nodes.

Also from puppet's perspective we still need some fixes because the
standalone
deployment can still be broken with the change in nova.
We need to know what would be the decision made in each distro packaging
and use the proper config files to store db parameters or the other
parameters.



On Fri, Nov 13, 2020 at 1:43 AM Oliver Walsh <owalsh at redhat.com> wrote:

> IIUC from Sean's reply  most of the heavyweight configuration management
> frameworks already address the security concern.
>
> For tripleo the first issue to address is in puppet-nova where the dbs are
> currently configured for every nova service. The fix seems trivial -
> https://review.opendev.org/755689. I also think that should be
> completely safe to backport this to all stable branches.
>
> The tripleo changes in https://review.opendev.org/#/c/718552/ are not
> strictly necessary to remove the db creds from nova.conf. However I need
> to go further, also removing the hieradata that contains the db creds since
> completely removing the db creds from the compute hosts is the
> ultimate goal here.
>
> So when the configuration management frameworks are all good then what are
> we actually concerned about security-wise? Is it just operators that roll
> their own deployments?
>
> Cheers,
> Ollie
>
> On Wed, 11 Nov 2020 at 16:37, Balázs Gibizer <balazs.gibizer at est.tech>
> wrote:
>
>> Dear packagers and deployment engine developers,
>>
>> Since Icehouse nova-compute service does not need any database
>> configuration as it uses the message bus to access data in the database
>> via the conductor service. Also, the nova configuration guide states
>> that the nova-compute service should not have the
>> [api_database]connection config set. Having any DB credentials
>> configured for the nova-compute is a security risk as well since that
>> service runs close to the hypervisor. Since Rocky[1] nova-compute
>> service fails if you configure API DB credentials and set upgrade_level
>> config to 'auto'.
>>
>> Now we are proposing a patch[2] that makes nova-compute fail at startup
>> if the [database]connection or the [api_database]connection is
>> configured. We know that this breaks at least the rpm packaging, debian
>> packaging, and puppet-nova. The problem there is that in an all-in-on
>> deployment scenario the nova.conf file generated by these tools is
>> shared between all the nova services and therefore nova-compute sees DB
>> credentials. As a counter-example, devstack generates a separate
>> nova-cpu.conf and passes that to the nova-compute service even in an
>> all-in-on setup.
>>
>> The nova team would like to merge [2] during Wallaby but we are OK to
>> delay the patch until Wallaby Milestone 2 so that the packagers and
>> deployment tools can catch up. Please let us know if you are impacted
>> and provide a way to track when you are ready with the modification
>> that allows [2] to be merged.
>>
>> There was a long discussion on #openstack-nova today[3] around this
>> topic. So you can find more detailed reasoning there[3].
>>
>> Cheers,
>> gibi
>>
>> [1]
>>
>> https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457
>> [2] https://review.opendev.org/#/c/762176
>> [3]
>>
>> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23
>> --
>>
>> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51
>>
>>
>>
>>

-- 
----------
Takashi Kajinami
Senior Software Maintenance Engineer
Customer Experience and Engagement
Red Hat
e-mail: tkajinam at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201113/4f75a504/attachment-0001.html>