Open Stack

Hello,


This is very true and good feedback, something that nags me everytime I think about it.

Having a shared storage and using rbd images backend and still needing SSH between compute nodes.


I'm hoping to have some time helping out to clear that up in the libvirt driver.


Best regards

________________________________
From: Thomas Goirand <zigo at debian.org>
Sent: Monday, November 23, 2020 1:21:14 PM
To: openstack maillist
Subject: Re: [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service

On 11/23/20 11:42 AM, Balázs Gibizer wrote:
>
>
> On Mon, Nov 23, 2020 at 11:18, Thomas Goirand <zigo at debian.org> wrote:
>> On 11/23/20 9:30 AM, Tobias Urdin wrote:
>>>  Hello,
>>>
>>>
>>>  Just to clarify that this is already possible when using
>>>  puppet-nova, it's up to the deployment to
>>>
>>>  make sure the database parameters for the classes is set.
>>>
>>>
>>>  We've been running without database credentials in nova.conf on our
>>>  compute nodes for years.
>>>
>>>
>>>  Best regards
>>>
>>>  Tobias
>>
>> Hi Tobias,
>>
>> That's not what I'm suggesting.
>>
>> I'm suggesting that nova-compute code from upstream simply ignores
>> completely anything related to db connection, so we're done with the
>> topic. That is, if nova-compute process having access to the db is the
>> issue we're trying to fix.
>>
>> Or is it that the security problem is having the db credentials written
>> in a file on the compute node? If so, isn't having hacked root (or nova)
>> access to a compute node already game-over?
>>
>> What are we trying to secure here? If that's what I'm thinking (ie: some
>> VM code to escape from guest, and potentially the hacker can gain access
>> to the db), then IMO that's not the way to enforce things. It's not the
>> role of upstream Nova to do this apart from a well enough written
>> documentation.
>
> I always understood this as having a goal to limit the attack surface.
> So if a VM escapes out of the sandbox and access the hypervisor then
> limit how may other services get compromised outside of the compromised
> compute host.
>
> Cheers,
> gibi

In general, I would agree with this. However, because of the way cold
migrations are working, nova compute boxes are authenticated between
each other through ssh. You'd be limiting access to the db, but someone
with nova or root ssh access could destroy all compute nodes. So, like
it or not, it's game-over anyways. If you want to fix things, make it so
that Nova doesn't require such ssh authentication anymore, because
that's more urgent, *THEN* we can revisit this topic.

Cheers,

Thomas Goirand (zigo)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201123/c2b710b7/attachment.html>