Image Signing and Verification Support
This spec describes a means to support signing and signature validation of bootable images. DocImpact SecurityImpact Implements: blueprint image-signing-and-verification-support Change-Id: I305b2ae86415c8d256c641abb2795af663bee56a
This commit is contained in:
Brianna Poulos
parent
dbf1df09ea
commit
4a35f198f8
|
|
@ -0,0 +1,304 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=====================================
|
||||
Glance Image Signing and Verification
|
||||
=====================================
|
||||
|
||||
https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support
|
||||
|
||||
OpenStack currently does not support the following feature:
|
||||
|
||||
* Signature validation of uploaded signed images
|
||||
|
||||
Deploying authentication will protect image integrity by verifying that an
|
||||
image has not been modified after the upload by the user. This feature
|
||||
improves the enterprise-ready posture of OpenStack.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
There is no method for users to verify that a previously uploaded image has
|
||||
not been modified. An image could potentially be modified in transit (such as
|
||||
when it is uploaded to glance or transferred to nova) or glance itself could
|
||||
be untrusted and modify images without a user's knowledge. An image that is
|
||||
modified could include malicious code. Providing support for image signatures
|
||||
and signature verification would allow the user to verify that an image has
|
||||
not been modified prior to booting the image.
|
||||
|
||||
There are several use cases that this feature will support:
|
||||
|
||||
* An image is signed by an End User, using the user's private key. The user
|
||||
then uploads the image to Glance, along with the signature created and a
|
||||
reference to the user's public key certificate. Glance uses this
|
||||
information to verify that the signature is valid, and notifies the user
|
||||
if the signature is invalid.
|
||||
|
||||
* An image is created in Nova, and Nova signs the image at the request of the
|
||||
End User. When the image is uploaded to Glance, the signature and public
|
||||
key certificate reference are also provided. Glance verifies the signature
|
||||
before storing the image, and notifies Nova if the signature verification
|
||||
fails.
|
||||
|
||||
* A signed image is requested by Nova, and Glance provides the signature and
|
||||
a reference to the public key certificate to Nova along with the image so
|
||||
that Nova can verify the signature before booting the image.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
For the initial implementation, this change will use the property feature of
|
||||
Glance to store the metadata items needed for image signing and verification.
|
||||
These include a public key certificate reference, and the signature. These
|
||||
are provided when the image is created, and are accessible when the image is
|
||||
uploaded. Note that this proposed change will only support image uploads with
|
||||
the glance api v2 (and will not support using the glance api v1). Also note
|
||||
that multiple formats for the key (such as SubjectPublicKeyInfo) and for the
|
||||
signature (such as PSS) will be supported. The format of the signature will
|
||||
be stored as one of the properties.
|
||||
|
||||
The certificate reference will be used to access the certificate from a key
|
||||
manager, where the certificate will be stored. This certificate is added to
|
||||
the key manager by the end user before uploading the image. Note that the
|
||||
signature is done offline.
|
||||
|
||||
Glance already supports computing checksums of images when an image is
|
||||
uploaded, and this checksum is stored with the image. This same hash (which
|
||||
by default is MD5) will be used for the signature verification.
|
||||
|
||||
Since the checksum hash is computed in glance_store (when the image data is
|
||||
uploaded), it makes sense for the signature verification to be computed in
|
||||
glance_store. glance_store also has the mechanism to abort an image upload if
|
||||
a failure occurs.
|
||||
|
||||
In order for the signature to be verified by the store backend, the backend
|
||||
must have access to the public key certificate and the signature. The Glance
|
||||
frontend should use the reference to the public key certificate to retrieve
|
||||
the certificate from the key manager, and then pass this public key along with
|
||||
the signature to the backend. If the signature verification fails,
|
||||
glance_store will abort the change, allowing the user to update the signature
|
||||
property to a correct value before trying again.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
An alternative to using the hash already created in the store backend for the
|
||||
signature verification/creation is to compute a hash in the store frontend.
|
||||
However, eventlet.wsgi.Input file-like object that represents the image data
|
||||
can only be read once, and needs to be read in the store backend in order to
|
||||
upload the image. In order to read the image data in the Glance frontend,
|
||||
Glance could copy the data into a file, use the file to verify/create the
|
||||
signature, and then give this file to the store backend to upload. This would
|
||||
be similar to what is done with the S3 backend [1]. However, this approach
|
||||
would take significantly more time (during image upload), and there would not
|
||||
be much gained.
|
||||
|
||||
An alternative to storing a reference to the public key certificate in Glance
|
||||
would be to store the actual public key certificate in Glance. However, this
|
||||
approach would be insecure, since Glance, unlike a dedicated key manager, has
|
||||
not been created with storing keys or certificates in mind.
|
||||
|
||||
An alternative to performing the signature verification/creation in the
|
||||
glance_store backend is to only perform the hash creation in the backend, and
|
||||
perform the signature verification/creation in the Glance front end. However,
|
||||
there is not a clean way to remove the uploaded image data from the backend,
|
||||
and if the user wants to update the signature and attempt another upload, this
|
||||
will cause duplication errors. Since glance_store has a mechanism to abort a
|
||||
failed upload and remove data easily during an upload, it solves this issue.
|
||||
|
||||
An alternative to using asymmetric keys for integrity and confidentiality is
|
||||
to use symmetric keys. However, in order for Glance to be able to verify the
|
||||
image, it would need to have access to the key used to create the signature.
|
||||
This access would enable Glance to modify the image and create a new signature
|
||||
without the user's knowledge. Using asymmetric keys enables Glance to verify
|
||||
the signature without giving Glance the power to modify the image and
|
||||
signature.
|
||||
|
||||
An alternative to using the Glance properties to store and retrieve the
|
||||
signature metadata would be to create an API extension that support
|
||||
signatures. Then, instead of the user setting the metadata using the property
|
||||
key value pairs, the API extension would be used. Currently, if a user were to
|
||||
use the metadata keys (for the certificate and signature) for other purposes,
|
||||
the image uploads would fail. Another item of note is that an API extension
|
||||
would allow for the management of multiple signatures per image in a clean
|
||||
manner, which is not possible with the properties approach. However, the
|
||||
Images API does not support extensions, so this is not a valid approach.
|
||||
|
||||
Another alternative to using the Glance properties to store and retrieve the
|
||||
signature metadata would be to use the CMS (cryptographic message syntax)
|
||||
format as defined in RFC 5652 Section 5. However, the size for this would be
|
||||
variable, and could not use the existing Glance properties, which would
|
||||
require API modifications. For the initial implementation, Glance properties
|
||||
will be used, with the plan to migrate to using CMS in a future implementation
|
||||
as the need for increased flexibility arises.
|
||||
|
||||
An alternative to requiring the user to provide the signature separate from
|
||||
the image is to support images that already have an embedded signature.
|
||||
Although this could be included as a future improvement, the initial
|
||||
implementation will not provide embedded signature support, since it is
|
||||
advantageous to keep the initial effort focused and small.
|
||||
|
||||
An alternative to using the existing MD5 hash algorithm is to create a
|
||||
separate configurable hash for use with verifying/creating the signature.
|
||||
However, creating a separate hash negatively affects the performance, without
|
||||
providing much benefit. Note that since there are preferable hash algorithms
|
||||
to MD5 that are more secure, a separate change is being proposed to allow for
|
||||
the configuring of this hash algorithm [2]. This will not be included as a
|
||||
part of this change, in the interest of having a straightforward initial
|
||||
implementation.
|
||||
|
||||
An alternative to focusing on a single-cloud implementation would be to
|
||||
include support for multi-clouds in the initial implementation. If images are
|
||||
exchanged between different clouds, signature verification could be used to
|
||||
confirm that images have not be modified. However, in the interest of a more
|
||||
simplistic initial implementation, explicit support for multi-clouds will be
|
||||
saved for future iterations.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
No API changes will be needed for the initial implementation, provided that
|
||||
other services are able to retrieve all of the properties of a given image.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
This change improves the enterprise-ready posture of OpenStack by enabling
|
||||
signature signing and verification.
|
||||
|
||||
Although keys are used in this change, the keys themselves are assumed to be
|
||||
stored in a key manager, and only a reference to the certificate is stored in
|
||||
Glance.
|
||||
|
||||
This change involves hashing the image data for use in verifying and creating
|
||||
signatures for the image.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
This change will involve adding log messages to indicate the success or
|
||||
failure of signature verification and creation.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
The user will be required to provide the appropriate information needed for
|
||||
the signing and verification in order to use this feature.
|
||||
|
||||
There are no changes that need to be made to python-glanceclient.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
The feature will only be used if a user has provided the appropriate
|
||||
properties during the image upload. Otherwise, no signature verification or
|
||||
creation will occur.
|
||||
|
||||
When signature verification and creation do occur, there will be some latency
|
||||
associated with retrieving the certificate from the key manager. Since the
|
||||
hash is already being created for images, the hash creation has no impact to
|
||||
performance.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
In order to handle the communication between Glance and glance_store, more
|
||||
parameters will need to be included in the call to add an image to the backend
|
||||
(including the public key certificate and signature) and in what is returned
|
||||
by glance_store. The result is that there will be cross-project dependencies
|
||||
between glance and glance_store.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
Every store in the glance_store backend would be required to support
|
||||
creating a hash for the image signature verification when the
|
||||
checksum is created, using the hash appropriately to verify the signature.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
brianna-poulos
|
||||
|
||||
Other contributors:
|
||||
dane-fichter
|
||||
|
||||
Reviewers
|
||||
---------
|
||||
|
||||
Core reviewer(s):
|
||||
flaper87
|
||||
sigmavirus24
|
||||
nikhil_k
|
||||
|
||||
Other reviewer(s):
|
||||
joel-coffman
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
The feature will be tackled in the following stages:
|
||||
|
||||
1. Enable Glance to verify signatures provided by the user during an image
|
||||
upload initiated by the user.
|
||||
2. Enable Glance to verify signatures provided by Nova during an image upload
|
||||
of a snapshot taken by Nova.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
The cryptography library, which will be used for hash creation and signature
|
||||
verification and creation, is already a part of the global-requirements of
|
||||
OpenStack. However, it is not a part of glance or glance_store, and will
|
||||
need to be added there.
|
||||
|
||||
Glance currently does not interact with any key managers. Since a key manager
|
||||
is needed to manage the keys, changes will need to be made to allow Glance to
|
||||
retrieve the public key certificate using a key manager. Specifically,
|
||||
Castellan [3] will be used to interface with the key manager chosen. The
|
||||
initial key manager will be Barbican, but Castellan can be configured to use a
|
||||
different backend.
|
||||
|
||||
In order to take advantage of the signatures in Glance, Nova will need to
|
||||
be updated to retrieve the signatures from Glance and verify them. However,
|
||||
Glance does not depend on Nova to have this support in order to have the
|
||||
feature added. The spec for this in Nova [4] has not yet been approved.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Before Nova support for this feature is added, unit tests will be sufficient.
|
||||
Once Nova support is added, Tempest tests should ensure that the interaction
|
||||
between Nova and Glance works as expected.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Instructions for how to use the change will need to be documented. These
|
||||
include instructions for the user on how to create keys and signatures
|
||||
offline before providing this information during the creation of an image.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
cryptography: https://cryptography.io/en/latest/
|
||||
|
||||
[1] http://goo.gl/Y3u3lK
|
||||
[2] https://review.openstack.org/191542
|
||||
[3] http://git.openstack.org/cgit/openstack/castellan
|
||||
[4] https://review.openstack.org/#/c/188874/
|
||||
Loading…
Reference in New Issue