<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hello,</p>
<p><br>
</p>
<p>This is very true and good feedback, something that nags me everytime I think about it.</p>
<p>Having a shared storage <span style="font-size:12pt">and using rbd images backend and still needing SSH between compute nodes.</span></p>
<p><br>
</p>
<p>I'm hoping to have some time helping out to clear that up in the libvirt driver.</p>
<p><br>
</p>
<p>Best regards</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Thomas Goirand <zigo@debian.org><br>
<b>Sent:</b> Monday, November 23, 2020 1:21:14 PM<br>
<b>To:</b> openstack maillist<br>
<b>Subject:</b> Re: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 11/23/20 11:42 AM, Balázs Gibizer wrote:<br>
> <br>
> <br>
> On Mon, Nov 23, 2020 at 11:18, Thomas Goirand <zigo@debian.org> wrote:<br>
>> On 11/23/20 9:30 AM, Tobias Urdin wrote:<br>
>>> Hello,<br>
>>><br>
>>><br>
>>> Just to clarify that this is already possible when using<br>
>>> puppet-nova, it's up to the deployment to<br>
>>><br>
>>> make sure the database parameters for the classes is set.<br>
>>><br>
>>><br>
>>> We've been running without database credentials in nova.conf on our<br>
>>> compute nodes for years.<br>
>>><br>
>>><br>
>>> Best regards<br>
>>><br>
>>> Tobias<br>
>><br>
>> Hi Tobias,<br>
>><br>
>> That's not what I'm suggesting.<br>
>><br>
>> I'm suggesting that nova-compute code from upstream simply ignores<br>
>> completely anything related to db connection, so we're done with the<br>
>> topic. That is, if nova-compute process having access to the db is the<br>
>> issue we're trying to fix.<br>
>><br>
>> Or is it that the security problem is having the db credentials written<br>
>> in a file on the compute node? If so, isn't having hacked root (or nova)<br>
>> access to a compute node already game-over?<br>
>><br>
>> What are we trying to secure here? If that's what I'm thinking (ie: some<br>
>> VM code to escape from guest, and potentially the hacker can gain access<br>
>> to the db), then IMO that's not the way to enforce things. It's not the<br>
>> role of upstream Nova to do this apart from a well enough written<br>
>> documentation.<br>
> <br>
> I always understood this as having a goal to limit the attack surface.<br>
> So if a VM escapes out of the sandbox and access the hypervisor then<br>
> limit how may other services get compromised outside of the compromised<br>
> compute host.<br>
> <br>
> Cheers,<br>
> gibi<br>
<br>
In general, I would agree with this. However, because of the way cold<br>
migrations are working, nova compute boxes are authenticated between<br>
each other through ssh. You'd be limiting access to the db, but someone<br>
with nova or root ssh access could destroy all compute nodes. So, like<br>
it or not, it's game-over anyways. If you want to fix things, make it so<br>
that Nova doesn't require such ssh authentication anymore, because<br>
that's more urgent, *THEN* we can revisit this topic.<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</div>
</span></font>
</body>
</html>