[nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service

Alex Schultz aschultz at redhat.com
Mon Nov 23 13:15:00 UTC 2020


On Mon, Nov 23, 2020 at 3:47 AM Bal√°zs Gibizer <balazs.gibizer at est.tech> 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.
>

I can agree with this in theory, however I don't think it's nova's
responsibility to enforce this.  IMHO a warning about this condition
should be sufficient from a project standpoint.  It's up to the
operator to ensure this does not happen and not the project.  The
project can't foresee how the service is actually going to be
deployed.  In theory this is moot if the compute service is running on
the same host as the api and not in something like a container.
Escaping the service and having access to the host won't prevent the
hacker from reading /etc/nova/nova-db.conf instead of
/etc/nova/nova-compute.conf.

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




More information about the openstack-discuss mailing list