Open Stack

If you need to update signed image data, you just need to make sure that
you also update the signature properties associated with that image.
Updating just the signed image itself would make it inconsistent with the
preexisting image signature, meaning that image signature verification
would fail when Nova attempts to boot the updated signed image.

This is orthogonal to the issues of certificate validation, but is still
important to clarify. Thanks for asking!

Peter

On 10/11/16, 1:36 PM, "Serguei Bezverkhi (sbezverk)" <sbezverk at cisco.com>
wrote:

>In some cases an image uploaded into glance need modification, example
>some attributes. How do you plan to handle cases like this? Are you
>planning this tool to update image signature?
>
>Serguei 
>
>-----Original Message-----
>From: Hamilton, Peter A. [mailto:Peter.Hamilton at jhuapl.edu]
>Sent: Tuesday, October 11, 2016 1:32 PM
>To: openstack-operators at lists.openstack.org
>Subject: [Openstack-operators] [openstack-operators][nova] Options for
>using trusted certificates in Nova image signature verification
>
>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
>
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators