Open Stack

Hi everyone,

We are interested in improving user trust in the cloud and are
currently working on certificate validation for image signatures in
Nova. Users can upload signed images to Glance and then boot them via
Nova, with Nova validating the image signature when it downloads the
image. Adding certificate validation to this process helps users be
confident that the signed image they are booting is the image they
expect it to be.

For clarity, here is a brief description about how the feature works:

1. User signs an image with their signing certificate
2. User uploads the cert to a certificate manager (e.g. Barbican)
3. User uploads the signed image to Glance with signature metadata
4. User tells Nova to create a new server using the signed image
5. Nova retrieves the image and image metadata
6. Nova retrieves the signing certificate
7. Nova conducts signature verification
8. If successful, Nova creates the new server

With the addition of certificate validation, this workflow changes
slightly. 

...
6. Nova retrieves the signing certificate
7. Nova obtains the trusted certificate (which signed the signing cert)
8. Nova conducts certificate validation
9. If successful, Nova conducts signature verification
10. If successful, Nova creates the new server

Given that this is a feature that spans services and has an impact on
the end-user, we want to get as much feedback from the community as
possible, including from developers and operators.

Here are the current options for supporting certificate validation in
Nova, specifically dealing with how to obtain the trusted certificate:

1. Update the Nova API to let the user pass in the certificate ID

The current proposed approach is to update the Nova API for the server
create call to allow the user to specify the ID of the trusted
certificate to use when validating the image signature. This places
the user in-the-loop, requiring them to provide a new specific piece
of information to successfully boot a signed image. However, there are
no easy ways to find the trusted certificate ID for an arbitrary
signed image. If different users sign and boot the same image,
out-of-band communication and metadata storage would be needed.

2. Add support for a certificate trust store to define trusted certs

Another approach adds support for a certificate trust store, which
contains a set of trusted signing certificates that are accessed
when verifying the image signature. When Nova conducts image
signature verification, it would pull in the certificates in the trust
store and search through them until it finds the certificate that
signed the image's signing certificate. If Nova cannot find it, boot
fails.

3. Use a hybrid approach of both #1 and #2

A third approach is a hybridization of the above two approaches,
leveraging the benefits of both while minimizing their drawbacks. The
Nova API would be updated to allow the user to pass the trusted
certificate ID when creating a new server. However, if the user did
not provide this ID Nova would pull the trusted certificates from the
certificate trust store to fill the gap. Either the user-provided
trusted certificate (preferred) or the set of certificates pulled from
the certificate trust store (backup) can then be used as needed.

There are benefits and downsides to each approach. If you are
interested in further details, we are in the process of updating an
Ocata Nova spec for this feature, linked below:

https://review.openstack.org/#/c/357151/

We are interested in your thoughts on certificate validation,
specifically on which of the above three options you prefer and why.

Thank you for your time,
Peter Hamilton