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.
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
- scheduler
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-ce... 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... 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.htm... https://docs.openstack.org/nova/latest/install/compute-install-ubuntu.html#i... 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. 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. the scudler need db acess although im not sure if it needs both.
- novncproxy - serialproxy - spicehtml5proxy
- api - api-metadata
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. 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)