Open Stack

On Fri 13 Nov 2020, 01:25 Takashi Kajinami, <tkajinam at redhat.com> wrote:

> > 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)
>

I believe you are correct about the pick function.
However I cannot think of any valid use case where the nova class would be
used without also using one of the service specific classes
(nova::api/nova::compute/nova::scheduler).

i.e if you previously did something like this it would still work:

class { 'nova':
  database_connection => "foobar"
}
include nova::api


if you previously did this it didn't work and continues to not work:

include nova::api
class { 'nova':
  database_connection => "foobar"
}

if you previously did this you would get db conf, now you will not:

class { 'nova':
  database_connection => "foobar"
}

I'm not sure what purpose of this would be. I guess if you want to generate
a nova.conf that contains just the config options that are common to all
services...
If that is the use case then the DB creds should not be included, they are
not common to all nova services.

If you are still concerned then in the backports we could continue
including nova::db when any of the deprecated params are set.


> 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.
>

Compute nodes would be ok but Controllers have nova-compute for ironic.
Single-node all-in-one deployments are obviously an issue too.

Cheers,
Ollie


> 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/66f9c892/attachment.html>