Prevent nova-compute starting if vaultlocker is not started succesfully

[Rodrigo Barbieri]

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.

[Rodrigo Barbieri (rodrigo-barbieri2010)]

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

[James Page (james-page)]

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.

[Andrew McLeod (admcleod)]

Hi Rodrigo,

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

[Rodrigo Barbieri (rodrigo-barbieri2010)]

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.

[OpenStack Infra (hudson-openstack)]

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

[James Page (james-page)]

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.

[James Page (james-page)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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