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:[email protected]] Sent: Tuesday, October 11, 2016 1:32 PM To: [email protected] 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
