Open Stack

On 11/23/20 11:31 AM, Balázs Gibizer wrote:
> It is still a security problem if nova-compute ignores the config as the
> config still exists on the hypervisor node (in some deployment scenarios)

Let's say we apply the patch you're proposing, and that nova-compute
isn't loaded anymore with the db credentials, because it's on a separate
file, and nova-compute doesn't load it.

In such scenario, the /etc/nova/nova-db.conf could still be present with
db credentials filled-in. So, the patch you're proposing is still not
effective for wrong configuration of nova-compute hosts.

> From the nova-compute perspective we might be able to
> replace the [api_database]connection dependency with some hack. E.g to
> put the service name to the global CONF object at the start of the
> service binary and depend on that instead of other part of the config.
> But I feel pretty bad about this hack.

Because of the above, I very much think it'd be the best way to go, but
I understand your point of view. Going to the /etc/nova/nova-db.conf and
nova-api-db.conf thing is probably good anyways.

As for the nova-conductor thing, I very much would prefer if we had a
clean and explicit "superconductor=true" directive, with possibly some
checks to display big warnings in the nova-conductor.log file in case of
a wrong configuration. If we don't have that, then at least things must
be extensively documented, because that's really not obvious what's
going on.

Cheers,

Thomas Goirand (zigo)