Open Stack

On Fri, Nov 13, 2020 at 11:19 PM Oliver Walsh <owalsh at redhat.com> wrote:

> 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"
> }
>
> I thought this could have worked somehow before we removed nova::db from
the nova class
but as you mentioned this was invalid method even if we have nova::db
included,
so I was wrong about that.

If we don't break any existing usage then I think we are good to backport
the fix to stable branches.


> 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.
>
Yeah I don't expect this usage in real deployment, either.


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

-- 
----------
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/20201114/f347c7fd/attachment-0001.html>