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

Thomas Goirand zigo at debian.org
Wed Nov 11 20:08:47 UTC 2020


On 11/11/20 5:35 PM, Bal√°zs Gibizer 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

IMO, that's ok if, and only if, we all agree on how to implement it.
Best would be if we (all downstream distro + config management) agree on
how to implement this.

How about, we all implement a /etc/nova/nova-db.conf, and get all
services that need db access to use it (ie: starting them with
--config-file=/etc/nova/nova-db.conf)?

If I understand well, these services would need access to db:
- conductor
- scheduler
- novncproxy
- serialproxy
- spicehtml5proxy
- api
- api-metadata

Is this list correct? Or is there some services that also don't need it?

Cheers,

Thomas Goirand (zigo)



More information about the openstack-discuss mailing list