vaultlocker

Prevent nova-compute starting if vaultlocker is not started succesfully

Bug #1863358 reported by Rodrigo Barbieri
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Nova Compute Charm
Fix Released
Undecided
James Page
OpenStack Nova Compute Charm 21.10
vaultlocker
In Progress
Undecided
Rodrigo Barbieri

Bug Description

In a scenario where Vault is not accessible or sealed, which will cause vaultlocker to not be able to successfully decrypt and mount /var/lib/nova/instances, nova-compute will start anyway and if it service requests from nova, it will create instances in the root filesystem's disk, which may not be encrypted.

This is a security flaw, as in such scenario encryption is configured and expected, but instances are created and used without encryption. This scenario can persist for a long time until an administrator finds out it is using the root filesystem's disk.

Ideally, nova-compute service should not start if vaultlocker service doesn't succeed initializing.

Tags: sts
Rodrigo Barbieri (rodrigo-barbieri2010)
tags: added: sts
Changed in vaultlocker:
assignee: nobody → Rodrigo Barbieri (rodrigo-barbieri2010)
status: New → In Progress
Revision history for this message
Rodrigo Barbieri (rodrigo-barbieri2010) wrote :

PR: https://github.com/openstack-charmers/vaultlocker/pull/10

Revision history for this message
James Page (james-page) wrote :

Please can we look at this the other way around and build the dependency from nova-compute -> vaultlocker-decrypt@<UUID> using overrides for the deployment?

The approach proposed in the PR is specialises vaultlocker in a way I'm not entirely comfortable with and using overrides you can use Requires which is a harder dependency that before/after.

Revision history for this message
Andrew McLeod (admcleod) wrote :

Hi Rodrigo,

I am also setting the status on the nova-compute charm to in progress, please modify if this is invalid

Changed in charm-nova-compute:
status: New → In Progress
assignee: nobody → Rodrigo Barbieri (rodrigo-barbieri2010)
Revision history for this message
Rodrigo Barbieri (rodrigo-barbieri2010) wrote :

In light of bug 1866861 it doesn't seem ideal to make changes to charm-nova-compute while that isn't addressed. Vaultlocker doesn't seem to work if "instances-path" config is changed, so that is another condition that needs to be handled before more dependency between them is added.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-nova-compute (master)

Fix proposed to branch: master
Review: https://review.opendev.org/729043

Revision history for this message
James Page (james-page) wrote :

this bug covers the vaultlocker use case, where the charm very much knows that /var/lib/nova will be on a separate block device and as such can also add the required systemd unit configuration overrides to ensure that nova-compute starts after the mount location has been mounted.

I'm concerned that there might also be use cases where /var/lib/nova is controlled by MAAS configuration and mounted during boot, before the charm even gets installed.

Revision history for this message
James Page (james-page) wrote :

Actually nova-compute will use the provided 'ephemeral-device' with or without encryption so the charm could cover use cases that are charm driven.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/charm-nova-compute/+/809204

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on charm-nova-compute (master)

Change abandoned by "James Page <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/charm-nova-compute/+/729043
Reason: Superceeded by https://review.opendev.org/c/openstack/charm-nova-compute/+/809204

Edward Hope-Morley (hopem)
Changed in charm-nova-compute:
assignee: Rodrigo Barbieri (rodrigo-barbieri2010) → James Page (james-page)
milestone: none → 21.10
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-nova-compute (master)

Reviewed: https://review.opendev.org/c/openstack/charm-nova-compute/+/809204
Committed: https://opendev.org/openstack/charm-nova-compute/commit/af2e40362594d19fc4ca2be0a11c186b684946af
Submitter: "Zuul (22348)"
Branch: master

commit af2e40362594d19fc4ca2be0a11c186b684946af
Author: James Page <email address hidden>
Date: Wed Sep 15 15:49:40 2021 +0100

    Block nova-compute startup on mountpoint

    If an ephemeral-device storage configuration has been provided,
    ensure that the nova-compute service will not start until the
    mountpoint (currently /var/lib/nova/instances) has actually
    been mounted. If this does not happen the nova-compute service
    will fail to start in a failsafe condition.

    Change-Id: Ic16691e119e430faec9994f6e207596629e47bb6
    Closes-Bug: 1863358

Changed in charm-nova-compute:
status: In Progress → Fix Committed
Alex Kavanagh (ajkavanagh)
Changed in charm-nova-compute:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.