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