[nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service

Oliver Walsh owalsh at redhat.com
Thu Nov 12 16:41:10 UTC 2020


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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201112/b20f6b45/attachment-0001.html>


More information about the openstack-discuss mailing list