<div dir="ltr"><div dir="auto"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri 13 Nov 2020, 01:25 Takashi Kajinami, <<a href="mailto:tkajinam@redhat.com" rel="noreferrer" target="_blank">tkajinam@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>> For tripleo the first issue to address is in puppet-nova where the 
dbs are currently configured for every nova service.</div><div>> The fix seems 
trivial - <a href="https://review.opendev.org/755689" rel="noreferrer noreferrer" target="_blank">https://review.opendev.org/755689</a>. I also think that should be completely safe to backport this to all stable branches.</div><div>I don't know whether we can backport that to stable branches.</div><div>I agreed to remove nova::db from the base nova class because we already</div><div>deprecated database parameters in the nova class, but in stable branches</div><div>we have these parameters still valid and removal of nova::db can cause some</div><div>issues with these parameters. (I guess pick dosn't work if the nova class was</div><div>defined AFTER nova::db class and there are no hieradata used)<br></div></div></blockquote><div><br></div><div>I believe you are correct about the pick function.</div><div>However I cannot think of any valid use case where the nova class would be used without also using one of the service specific classes (nova::api/nova::compute/nova::scheduler).</div><div><br></div><div>i.e if you previously did something like this it would still work:<br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div class="gmail_quote"><div>class { 'nova':</div></div></div><div><div class="gmail_quote"><div>  database_connection => "foobar"</div></div></div><div><div class="gmail_quote"><div>}</div></div></div><div><div class="gmail_quote"><div>include nova::api</div></div></div></blockquote><div dir="auto"><div class="gmail_quote"><div><br></div><div>if you previously did this it didn't work and continues to not work:</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div class="gmail_quote"><div>include nova::api</div><div>class { 'nova':</div></div></div><div><div class="gmail_quote"><div>  database_connection => "foobar"</div></div></div><div><div class="gmail_quote"><div>}</div></div></div><div><div class="gmail_quote"><br></div></div></blockquote><div dir="auto"><div class="gmail_quote"><div></div></div></div></div><div>if you previously did this you would get db conf, now you will not:</div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div class="gmail_quote"><div><div><div class="gmail_quote"><div>class { 'nova':</div></div></div></div></div></div><div><div class="gmail_quote"><div><div><div class="gmail_quote"><div>  database_connection => "foobar"</div></div></div></div></div></div><div><div class="gmail_quote"><div><div><div class="gmail_quote"><div>}</div></div></div></div></div></div></blockquote><div dir="auto"><div class="gmail_quote"><div>I'm not sure what purpose of this would be. I guess if you want to generate a nova.conf that contains just the config options that are common to all services...</div><div>If that is the use case then the DB creds should not be included, they are not common to all nova services.</div><div><br></div><div>If you are still concerned then in the backports we could continue including nova::db when any of the deprecated params are set. <br></div></div></div><div dir="auto"><div><div class="gmail_quote"><div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>So I'd say it's better to leave it in stable branches if nova doesn't require</div><div>absence of db parameters in stable branches.</div></div></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Note that we can remove these parameters from compute nodes in TripleO deployment</div><div>if we completely remove these hieradata from compute nodes.<br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Compute nodes would be ok but Controllers have nova-compute for ironic.</div><div dir="auto">Single-node all-in-one deployments are obviously an issue too.</div><div dir="auto"><br></div><div>Cheers,</div><div>Ollie</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Also from puppet's perspective we still need some fixes because the standalone</div><div>deployment can still be broken with the change in nova.</div></div></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We need to know what would be the decision made in each distro packaging</div><div>and use the proper config files to store db parameters or the other parameters. </div></div></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 13, 2020 at 1:43 AM Oliver Walsh <<a href="mailto:owalsh@redhat.com" rel="noreferrer noreferrer" target="_blank">owalsh@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>IIUC from Sean's reply  most of the heavyweight configuration management frameworks already address the security concern.<br></div><div><br></div><div>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 - <a href="https://review.opendev.org/755689" rel="noreferrer noreferrer" target="_blank">https://review.opendev.org/755689</a>. I also think that should be completely safe to backport this to all stable branches.</div><div><br></div><div>The tripleo changes in <a href="https://review.opendev.org/#/c/718552/" rel="noreferrer noreferrer" target="_blank">https://review.opendev.org/#/c/718552/</a> 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.<br></div><div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div>Ollie</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 11 Nov 2020 at 16:37, Balázs Gibizer <balazs.gibizer@est.tech> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear packagers and deployment engine developers,<br>
<br>
Since Icehouse nova-compute service does not need any database <br>
configuration as it uses the message bus to access data in the database <br>
via the conductor service. Also, the nova configuration guide states <br>
that the nova-compute service should not have the <br>
[api_database]connection config set. Having any DB credentials <br>
configured for the nova-compute is a security risk as well since that <br>
service runs close to the hypervisor. Since Rocky[1] nova-compute <br>
service fails if you configure API DB credentials and set upgrade_level <br>
config to 'auto'.<br>
<br>
Now we are proposing a patch[2] that makes nova-compute fail at startup <br>
if the [database]connection or the [api_database]connection is <br>
configured. We know that this breaks at least the rpm packaging, debian <br>
packaging, and puppet-nova. The problem there is that in an all-in-on <br>
deployment scenario the nova.conf file generated by these tools is <br>
shared between all the nova services and therefore nova-compute sees DB <br>
credentials. As a counter-example, devstack generates a separate <br>
nova-cpu.conf and passes that to the nova-compute service even in an <br>
all-in-on setup.<br>
<br>
The nova team would like to merge [2] during Wallaby but we are OK to <br>
delay the patch until Wallaby Milestone 2 so that the packagers and <br>
deployment tools can catch up. Please let us know if you are impacted <br>
and provide a way to track when you are ready with the modification <br>
that allows [2] to be merged.<br>
<br>
There was a long discussion on #openstack-nova today[3] around this <br>
topic. So you can find more detailed reasoning there[3].<br>
<br>
Cheers,<br>
gibi<br>
<br>
[1] <br>
<a href="https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899617e/nova/compute/rpcapi.py#L441-L457</a><br>
[2] <a href="https://review.opendev.org/#/c/762176" rel="noreferrer noreferrer noreferrer" target="_blank">https://review.opendev.org/#/c/762176</a><br>
[3] <br>
<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23" rel="noreferrer noreferrer noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T10:51:23</a> <br>
-- <br>
<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51" rel="noreferrer noreferrer noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-11-11.log.html#t2020-11-11T14:40:51</a><br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div>----------</div><div>Takashi Kajinami<br></div><div>Senior Software Maintenance Engineer<span style="font-family:arial,helvetica,sans-serif"></span><br><div style="outline:currentcolor none medium"><div dir="ltr">Customer Experience and Engagement<br>Red Hat</div><div>e-mail: <a href="mailto:tkajinam@redhat.com" rel="noreferrer noreferrer" target="_blank">tkajinam@redhat.com</a></div><div dir="ltr"><br></div></div></div></div></div></div></div>
</blockquote></div></div></div>
</div>