openstack
/
nova
Code Issues Proposed changes
nova/doc/source/user/certificate-validation.rst

675 lines
27 KiB
ReStructuredText
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Image Signature Certificate Validation
======================================
Nova can determine if the certificate used to generate and verify the signature
of a signed image (see `Glance Image Signature Verification documentation`_) is
trusted by the user. This feature is called certificate validation and can be
applied to the creation or rebuild of an instance.
Certificate validation is meant to be performed jointly with image signature
verification but each feature has its own Nova configuration option, to be
specified in the ``[glance]`` section of the ``nova.conf`` configuration file.
To enable certificate validation, set
:oslo.config:option:`glance.enable_certificate_validation` to True. To
enable signature validation, set
:oslo.config:option:`glance.verify_glance_signatures` to True.
Conversely, to disable either of these features, set their option to False or
do not include the option in the Nova configurations at all.
Certificate validation operates in concert with signature validation in
`Cursive`_. It takes in a list of trusted certificate IDs and verifies that the
certificate used to sign the image being booted is cryptographically linked to
at least one of the provided trusted certificates. This provides the user with
confidence in the identity and integrity of the image being booted.
Certificate validation will only be performed if image signature validation is
enabled. However, the presence of trusted certificate IDs overrides the
``enable_certificate_validation`` and ``verify_glance_signatures`` settings. In
other words, if a list of trusted certificate IDs is provided to the instance
create or rebuild commands, signature verification and certificate validation
will be performed, regardless of their settings in the Nova configurations.
See `Using Signature Verification`_ for details.
.. _Cursive: http://git.openstack.org/cgit/openstack/cursive/
.. _Glance Image Signature Verification documentation: https://docs.openstack.org/glance/latest/user/signature.html
.. note::
Certificate validation configuration options must be specified in the Nova
configuration file that controls the ``nova-osapi_compute`` and
``nova-compute`` services, as opposed to other Nova services (conductor,
scheduler, etc.).
Requirements
------------
Key manager that is a backend to the `Castellan Interface`_. Possible key
managers are:
* `Barbican`_
* `Vault`_
.. _Castellan Interface: https://docs.openstack.org/castellan/latest/
.. _Barbican: https://docs.openstack.org/barbican/latest/contributor/devstack.html
.. _Vault: https://www.vaultproject.io/
Limitations
-----------
* As of the 18.0.0 Rocky release, only the libvirt compute driver supports
trusted image certification validation. The feature is not, however, driver
specific so other drivers should be able to support this feature over time.
See the `feature support matrix`_ for information on which drivers support
the feature at any given release.
* As of the 18.0.0 Rocky release, trusted image certification validation is
not supported with volume-backed (boot from volume) instances. The block
storage service support may be available in a future release:
https://blueprints.launchpad.net/cinder/+spec/certificate-validate
* Trusted image certification support can be controlled via
`policy configuration`_ if it needs to be disabled. See the
``os_compute_api:servers:create:trusted_certs`` and
``os_compute_api:servers:rebuild:trusted_certs`` policy rules.
.. _feature support matrix: https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_trusted_certs
.. _policy configuration: https://docs.openstack.org/nova/latest/configuration/policy.html
Configuration
-------------
Nova will use the key manager defined by the Castellan key manager interface,
which is the Barbican key manager by default. To use a different key manager,
update the ``backend`` value in the ``[key_manager]`` group
of the nova configuration file. For example::
[key_manager]
backend = barbican
.. note:: If these lines do not exist, then simply add them to the end of the
file.
Using Signature Verification
----------------------------
An image will need a few properties for signature verification to be enabled:
``img_signature``
Signature of your image. Signature restrictions are:
* 255 character limit
``img_signature_hash_method``
Method used to hash your signature. Possible hash methods are:
* SHA-224
* SHA-256
* SHA-384
* SHA-512
``img_signature_key_type``
Key type used for your image. Possible key types are:
* RSA-PSS
* DSA
* ECC-CURVES
* SECT571K1
* SECT409K1
* SECT571R1
* SECT409R1
* SECP521R1
* SECP384R1
``img_signature_certificate_uuid``
UUID of the certificate that you uploaded to the key manager. Possible certificate types are:
* X_509
Using Certificate Validation
----------------------------
Certificate validation is triggered by one of two ways:
1. The Nova configuration options ``verify_glance_signatures`` and
``enable_certificate_validation`` are both set to True::
[glance]
verify_glance_signatures = True
enable_certificate_validation = True
2. A list of trusted certificate IDs is provided by one of three ways:
.. note:: The command line support is pending changes
https://review.openstack.org/#/c/500396/ and
https://review.openstack.org/#/c/501926/ to python-novaclient and
python-openstackclient, respectively.
Environment Variable
Use the environment variable ``OS_TRUSTED_IMAGE_CERTIFICATE_IDS`` to
define a comma-delimited list of trusted certificate IDs. For example:
.. code-block:: console
$ export OS_TRUSTED_IMAGE_CERTIFICATE_IDS=79a6ad17-3298-4e55-8b3a-1672dd93c40f,b20f5600-3c9d-4af5-8f37-3110df3533a0
Command-Line Flag
If booting or rebuilding an instance using the :command:`nova` commands,
use the ``--trusted-image-certificate-id`` flag to define a single trusted
certificate ID. The flag may be used multiple times to specify multiple trusted
certificate IDs. For example:
.. code-block:: console
$ nova boot myInstanceName \
--flavor 1 \
--image myImageId \
--trusted-image-certificate-id 79a6ad17-3298-4e55-8b3a-1672dd93c40f \
--trusted-image-certificate-id b20f5600-3c9d-4af5-8f37-3110df3533a0
If booting or rebuilding an instance using the :command:`openstack server` commands,
use the ``--trusted-image-certificate-id`` flag to define a single trusted
certificate ID. The flag may be used multiple times to specify multiple trusted
certificate IDs. For example:
.. code-block:: console
$ openstack --os-compute-api-version=2.63 server create myInstanceName \
--flavor 1 \
--image myImageId \
--nic net-id=fd25c0b2-b36b-45a8-82e4-ab52516289e5 \
--trusted-image-certificate-id 79a6ad17-3298-4e55-8b3a-1672dd93c40f \
--trusted-image-certificate-id b20f5600-3c9d-4af5-8f37-3110df3533a0
Nova Configuration Option
Use the Nova configuration option
:oslo.config:option:`glance.default_trusted_certificate_ids` to
define a comma-delimited list of trusted certificate IDs. This
configuration value is only used if ``verify_glance_signatures`` and
``enable_certificate_validation`` options are set to True, and the trusted
certificate IDs are not specified anywhere else. For example::
[glance]
default_trusted_certificate_ids=79a6ad17-3298-4e55-8b3a-1672dd93c40f,b20f5600-3c9d-4af5-8f37-3110df3533a0
Example Usage
-------------
For these instructions, we will construct a 4-certificate chain to illustrate
that it is possible to have a single trusted root certificate. We will upload
all four certificates to Barbican. Then, we will sign an image and upload it to
Glance, which will illustrate image signature verification. Finally, we will
boot the signed image from Glance to show that certificate validation is
enforced.
Enable certificate validation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enable image signature verification and certificate validation by setting both
of their Nova configuration options to True::
[glance]
verify_glance_signatures = True
enable_certificate_validation = True
Create a certificate chain
^^^^^^^^^^^^^^^^^^^^^^^^^^
As mentioned above, we will construct a 4-certificate chain to illustrate that
it is possible to have a single trusted root certificate. Before we begin to
build our certificate chain, we must first create files for OpenSSL to use for
indexing and serial number tracking:
.. code-block:: console
$ touch index.txt
$ echo '01' > serial.txt
Create a certificate configuration file
"""""""""""""""""""""""""""""""""""""""
For these instructions, we will create a single configuration file called
``ca.conf``, which contains various sections that we can specify for use on the
command-line during certificate requests and generation.
Note that this certificate will be able to sign other certificates because it
is a certificate authority. Also note the root CA's unique common name
("root"). The intermediate certificates' common names will be specified on the
command-line when generating the corresponding certificate requests.
``ca.conf``::
[ req ]
prompt = no
distinguished_name = dn-param
x509_extensions = ca_cert_extensions
[ ca ]
default_ca = ca_default
[ dn-param ]
C = US
CN = Root CA
[ ca_cert_extensions ]
keyUsage = keyCertSign, digitalSignature
basicConstraints = CA:TRUE, pathlen:2
[ ca_default ]
new_certs_dir = . # Location for new certs after signing
database = ./index.txt # Database index file
serial = ./serial.txt # The current serial number
default_days = 1000
default_md = sha256
policy = signing_policy
email_in_dn = no
[ intermediate_cert_extensions ]
keyUsage = keyCertSign, digitalSignature
basicConstraints = CA:TRUE, pathlen:1
[client_cert_extensions]
keyUsage = keyCertSign, digitalSignature
basicConstraints = CA:FALSE
[ signing_policy ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Generate the certificate authority (CA) and corresponding private key
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
For these instructions, we will save the certificate as ``cert_ca.pem`` and the
private key as ``key_ca.pem``. This certificate will be a self-signed root
certificate authority (CA) that can sign other CAs and non-CA certificates.
.. code-block:: console
$ openssl req \
-x509 \
-nodes \
-newkey rsa:1024 \
-config ca.conf \
-keyout key_ca.pem \
-out cert_ca.pem
Generating a 1024 bit RSA private key
............................++++++
...++++++
writing new private key to 'key_ca.pem'
-----
Create the first intermediate certificate
"""""""""""""""""""""""""""""""""""""""""
Create a certificate request for the first intermediate certificate. For these
instructions, we will save the certificate request as
``cert_intermeidate_a.csr`` and the private key as ``key_intermediate_a.pem``.
.. code-block:: console
$ openssl req \
-nodes \
-newkey rsa:2048 \
-subj '/CN=First Intermediate Certificate' \
-keyout key_intermediate_a.pem \
-out cert_intermediate_a.csr
Generating a 2048 bit RSA private key
.............................................................................................................+++
.....+++
writing new private key to 'key_intermediate_a.pem'
-----
Generate the first intermediate certificate by signing its certificate request
with the CA. For these instructions we will save the certificate as
``cert_intermediate_a.pem``.
.. code-block:: console
$ openssl ca \
-config ca.conf \
-extensions intermediate_cert_extensions \
-cert cert_ca.pem \
-keyfile key_ca.pem \
-out cert_intermediate_a.pem \
-infiles cert_intermediate_a.csr
Using configuration from ca.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'First Intermediate Certificate'
Certificate is to be certified until Nov 15 16:24:21 2020 GMT (1000 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Create the second intermediate certificate
""""""""""""""""""""""""""""""""""""""""""
Create a certificate request for the second intermediate certificate. For these
instructions, we will save the certificate request as
``cert_intermeidate_b.csr`` and the private key as ``key_intermediate_b.pem``.
.. code-block:: console
$ openssl req \
-nodes \
-newkey rsa:2048 \
-subj '/CN=Second Intermediate Certificate' \
-keyout key_intermediate_b.pem \
-out cert_intermediate_b.csr
Generating a 2048 bit RSA private key
..........+++
............................................+++
writing new private key to 'key_intermediate_b.pem'
-----
Generate the second intermediate certificate by signing its certificate request
with the first intermediate certificate. For these instructions we will save
the certificate as ``cert_intermediate_b.pem``.
.. code-block:: console
$ openssl ca \
-config ca.conf \
-extensions intermediate_cert_extensions \
-cert cert_intermediate_a.pem \
-keyfile key_intermediate_a.pem \
-out cert_intermediate_b.pem \
-infiles cert_intermediate_b.csr
Using configuration from ca.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'Second Intermediate Certificate'
Certificate is to be certified until Nov 15 16:25:42 2020 GMT (1000 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Create the client certificate
"""""""""""""""""""""""""""""
Create a certificate request for the client certificate. For these
instructions, we will save the certificate request as ``cert_client.csr`` and
the private key as ``key_client.pem``.
.. code-block:: console
$ openssl req \
-nodes \
-newkey rsa:2048 \
-subj '/CN=Client Certificate' \
-keyout key_client.pem \
-out cert_client.csr
Generating a 2048 bit RSA private key
.............................................................................................................................+++
..............................................................................................+++
writing new private key to 'key_client.pem'
-----
Generate the client certificate by signing its certificate request with the
second intermediate certificate. For these instructions we will save the
certificate as ``cert_client.pem``.
.. code-block:: console
$ openssl ca \
-config ca.conf \
-extensions client_cert_extensions \
-cert cert_intermediate_b.pem \
-keyfile key_intermediate_b.pem \
-out cert_client.pem \
-infiles cert_client.csr
Using configuration from ca.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'Client Certificate'
Certificate is to be certified until Nov 15 16:26:46 2020 GMT (1000 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Upload the generated certificates to the key manager
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In order interact with the key manager, the user needs to have a `creator` role.
To list all users with a `creator` role, run the following command as an admin:
.. code-block:: console
$ openstack role assignment list --role creator --names
+---------+-----------------------------+-------+-------------------+--------+-----------+
| Role | User | Group | Project | Domain | Inherited |
+---------+-----------------------------+-------+-------------------+--------+-----------+
| creator | project_a_creator_2@Default | | project_a@Default | | False |
| creator | project_b_creator@Default | | project_b@Default | | False |
| creator | project_a_creator@Default | | project_a@Default | | False |
+---------+-----------------------------+-------+-------------------+--------+-----------+
To give the `demo` user a `creator` role in the `demo` project, run the
following command as an admin:
.. code-block:: console
$ openstack role add --user demo --project demo creator
.. note:: This command provides no output. If the command fails, the user will
see a "4xx Client error" indicating that "Secret creation attempt not
allowed" and to "please review your user/project privileges".
.. note:: The following "openstack secret" commands require that the
`python-barbicanclient <https://pypi.org/project/python-barbicanclient/>`_
package is installed.
.. code-block:: console
$ openstack secret store \
--name CA \
--algorithm RSA \
--expiration 2018-06-29 \
--secret-type certificate \
--payload-content-type "application/octet-stream" \
--payload-content-encoding base64 \
--payload "$(base64 cert_ca.pem)"
$ openstack secret store \
--name IntermediateA \
--algorithm RSA \
--expiration 2018-06-29 \
--secret-type certificate \
--payload-content-type "application/octet-stream" \
--payload-content-encoding base64 \
--payload "$(base64 cert_intermediate_a.pem)"
$ openstack secret store \
--name IntermediateB \
--algorithm RSA \
--expiration 2018-06-29 \
--secret-type certificate \
--payload-content-type "application/octet-stream" \
--payload-content-encoding base64 \
--payload "$(base64 cert_intermediate_b.pem)"
$ openstack secret store \
--name Client \
--algorithm RSA \
--expiration 2018-06-29 \
--secret-type certificate \
--payload-content-type "application/octet-stream" \
--payload-content-encoding base64 \
--payload "$(base64 cert_client.pem)"
The responses should look something like this:
.. code-block:: console
+---------------+------------------------------------------------------------------------------+
| Field | Value |
+---------------+------------------------------------------------------------------------------+
| Secret href | http://127.0.0.1/key-manager/v1/secrets/8fbcce5d-d646-4295-ba8a-269fc9451eeb |
| Name | CA |
| Created | None |
| Status | None |
| Content types | {u'default': u'application/octet-stream'} |
| Algorithm | RSA |
| Bit length | 256 |
| Secret type | certificate |
| Mode | cbc |
| Expiration | 2018-06-29T00:00:00+00:00 |
+---------------+------------------------------------------------------------------------------+
Save off the certificate UUIDs (found in the secret href):
.. code-block:: console
$ cert_ca_uuid=8fbcce5d-d646-4295-ba8a-269fc9451eeb
$ cert_intermediate_a_uuid=0b5d2c72-12cc-4ba6-a8d7-3ff5cc1d8cb8
$ cert_intermediate_b_uuid=674736e3-f25c-405c-8362-bbf991e0ce0a
$ cert_client_uuid=125e6199-2de4-46e3-b091-8e2401ef0d63
Create a signed image
^^^^^^^^^^^^^^^^^^^^^
For these instructions, we will download a small CirrOS image:
.. code-block:: console
$ wget -nc -O cirros.tar.gz http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-source.tar.gz
--2018-02-19 11:37:52-- http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-source.tar.gz
Resolving download.cirros-cloud.net (download.cirros-cloud.net)... 64.90.42.85
Connecting to download.cirros-cloud.net (download.cirros-cloud.net)|64.90.42.85|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 434333 (424K) [application/x-tar]
Saving to: ‘cirros.tar.gz’
cirros.tar.gz 100%[===================>] 424.15K --.-KB/s in 0.1s
2018-02-19 11:37:54 (3.79 MB/s) - ‘cirros.tar.gz’ saved [434333/434333]
Sign the image with the generated client private key:
.. code-block:: console
$ openssl dgst \
-sha256 \
-sign key_client.pem \
-sigopt rsa_padding_mode:pss \
-out cirros.self_signed.signature \
cirros.tar.gz
.. note:: This command provides no output.
Save off the base64 encoded signature:
.. code-block:: console
$ base64_signature=$(base64 -w 0 cirros.self_signed.signature)
Upload the signed image to Glance:
.. code-block:: console
$ openstack image create \
--public \
--container-format bare \
--disk-format qcow2 \
--property img_signature="$base64_signature" \
--property img_signature_certificate_uuid="$cert_client_uuid" \
--property img_signature_hash_method='SHA-256' \
--property img_signature_key_type='RSA-PSS' \
--file cirros.tar.gz \
cirros_client_signedImage
+------------------+------------------------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------------------------+
| checksum | d41d8cd98f00b204e9800998ecf8427e |
| container_format | bare |
| created_at | 2019-02-06T06:29:56Z |
| disk_format | qcow2 |
| file | /v2/images/17f48a6c-e592-446e-9c91-00fbc436d47e/file |
| id | 17f48a6c-e592-446e-9c91-00fbc436d47e |
| min_disk | 0 |
| min_ram | 0 |
| name | cirros_client_signedImage |
| owner | 45e13e63606f40d6b23275c3cd91aec2 |
| properties | img_signature='swA/hZi3WaNh35VMGlnfGnBWuXMlUbdO8h306uG7W3nwOyZP6dGRJ3 |
| | Xoi/07Bo2dMUB9saFowqVhdlW5EywQAK6vgDsi9O5aItHM4u7zUPw+2e8eeaIoHlGhTks |
| | kmW9isLy0mYA9nAfs3coChOIPXW4V8VgVXEfb6VYGHWm0nShiAP1e0do9WwitsE/TVKoS |
| | QnWjhggIYij5hmUZ628KAygPnXklxVhqPpY/dFzL+tTzNRD0nWAtsc5wrl6/8HcNzZsaP |
| | oexAysXJtcFzDrf6UQu66D3UvFBVucRYL8S3W56It3Xqu0+InLGaXJJpNagVQBb476zB2 |
| | ZzZ5RJ/4Zyxw==', |
| | img_signature_certificate_uuid='125e6199-2de4-46e3-b091-8e2401ef0d63', |
| | img_signature_hash_method='SHA-256', |
| | img_signature_key_type='RSA-PSS', |
| | os_hash_algo='sha512', |
| | os_hash_value='cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a92 |
| | 1d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927d |
| | a3e', |
| | os_hidden='False' |
| protected | False |
| schema | /v2/schemas/image |
| size | 0 |
| status | active |
| tags | |
| updated_at | 2019-02-06T06:29:56Z |
| virtual_size | None |
| visibility | public |
+------------------+------------------------------------------------------------------------+
.. note:: Creating the image can fail if validation does not succeed. This will
cause the image to be deleted and the Glance log to report that
"Signature verification failed" for the given image ID.
Boot the signed image
^^^^^^^^^^^^^^^^^^^^^
Boot the signed image without specifying trusted certificate IDs:
.. code-block:: console
$ nova boot myInstance \
--flavor m1.tiny \
--image cirros_client_signedImage
.. note:: The instance should fail to boot because certificate validation fails
when the feature is enabled but no trusted image certificates are
provided. The Nova log output should indicate that "Image signature
certificate validation failed" because "Certificate chain building failed".
Boot the signed image with trusted certificate IDs:
.. code-block:: console
$ nova boot myInstance \
--flavor m1.tiny \
--image cirros_client_signedImage \
--trusted-image-certificate-id $cert_ca_uuid,$cert_intermediate_a_uuid \
--trusted-image-certificate-id $cert_intermediate_b_uuid
.. note:: The instance should successfully boot and certificate validation
should succeed. The Nova log output should indicate that "Image
signature certificate validation succeeded".
Other Links
-----------
* https://etherpad.openstack.org/p/mitaka-glance-image-signing-instructions
* https://etherpad.openstack.org/p/queens-nova-certificate-validation
* https://wiki.openstack.org/wiki/OpsGuide/User-Facing_Operations
* http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/nova-validate-certificates.html
View Git Blame Copy Permalink