Open Stack

On Mon, Nov 23, 2020 at 13:21, Thomas Goirand <zigo at debian.org> wrote:
> 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.

While I agree that we should do changes, if possible, to avoid the need 
of ssh between the computes, I don't agree that a compromised compute 
is a game over for the whole cloud. If the deployment is split up to 
cells, then the game over is limited to the cell the compromised 
compute is in.

Cheers,
gibi

> 
> Cheers,
> 
> Thomas Goirand (zigo)
>