Open Stack

On Wed, 2020-11-11 at 21:08 +0100, Thomas Goirand wrote:
> 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.
well not to be too blunt but im not sure we resonably can chose not to implement this.

i has been raised by customer that have don a security audit in the past as a hardening issue
that the db cred which are unused are present on the compute nodes.

all agreeing to do it the same way woudl be a good thing but at the end of the day we should do this
this cycle. we also shoudl come up with some upstream recomendation in the install docs on the best partice for this
hopefully we can get agreement but if a specific config managment tool chosses to go a different way i dont think they
should be force to chagne.

for example kolla already dose the right thing and has for several releases.
i dont think they shoudl need to change there approch.

the have a singel nova.conf per container but a different one for each container
https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/nova-cell/templates/nova.conf.j2#L136-L151
the nova.conf for the compute contaienr dose not contian the db info which is the correct approch.

openstack ansible also do the same thing
https://github.com/openstack/openstack-ansible-os_nova/blob/master/templates/nova.conf.j2#L183-L199

ooo will do the same thing
once https://review.opendev.org/#/c/718552/ is done more or less.

so form a config managment point of view the pattern is to generate a configile with only the info tha tis needed.

form a packager point of view hte only way to mimic that is to use multiple files with descreeet chunks
or to not install any config by default nad require operators to copy thet samples.

the install guides dont expclitly call this out
https://docs.openstack.org/nova/latest/install/controller-install-ubuntu.html#install-and-configure-components
https://docs.openstack.org/nova/latest/install/compute-install-ubuntu.html#install-and-configure-components

but the compute node one does not tell you to add the db config either.

i do thikn we shoudl update the comptue node install docs to use a different file however instad of nova.conf.

> 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)?
we might want two db files so nova-cell-db and nova-api-db really
> 
> If I understand well, these services would need access to db:
> - conductor
the super conductor need the cell db and the api db

form talking to dan the instance affinity/antiaffintiy late check would reuire
the cell db to unfortually need api db access too.


> - scheduler
the scudler need db acess although im not sure if it needs both.

> - novncproxy
> - serialproxy
> - spicehtml5proxy

so im not sure if these 3 do.
they might for some kind fo token storage although i did not think they really
should need db acess, maybe to get the instance host, it would be nice if these could be restrcted
to just use the api db but they might need both.

 there is a propsal too support passwords with consoles.
https://review.opendev.org/#/c/759828/
i have not check but i assume that will require tehm to have db access if they do not already.
although i think the password enforcement might be via the hypervisor e.g. libvirt so they may not
need db acess for that. we should determin that.


> - api
> - api-metadata
the api and metadata api both need db acess yes.
i think we need both the api db and cell db acess in both cases.
> 
> Is this list correct? Or is there some services that also don't need it?
the only other nova service is the compute agent and it does not need db acess.

im not sure if there is utility in 
> 
> Cheers,
> 
> Thomas Goirand (zigo)
>