[openstack-dev] [nova] Confusion over how enable_certificate_validation is meant to be used

Poulos, Brianna L. Brianna.Poulos at jhuapl.edu
Tue Jun 12 14:55:03 UTC 2018


Matt,

The end goal is that certificate validation will always occur alongside signature validation, but we wanted there to be an upgrade path that would allow signature validation to continue to work until certificate validation was set up.  See the first paragraph of the proposed change in the spec [1].

We also wanted the user to be able to use certificate validation even if the operator has not enabled it across a deployment.  This is why the user supplying trusted certs overrides the enable_certificate_validation (and the verify_glance_signatures) option.  We wanted to avoid a "silent fail" scenario where a user provided trusted certs but certificate validation (and/or signature verification) wasn't enabled in the configuration, which would lead to the user thinking that certificate validation was performed when it wasn't.

We provided additional clarification about the options and how they interact in the documentation for the feature [2].

[...]
    In this scenario, if the user fails to provide trusted certs when 
    creating or rebuilding a server, it's going to result in a build abort 
    exception (NoValidHost) from the compute. Is that the intention? 
[...]

Yes, the intention is that if both signature verification and certificate validation are enabled in the configuration file, trusted certificates must be provided (either by the user or by the default list of trusted certs) or the build will be aborted.

[...]
    Also, the enable_certificate_validation option is deprecated and meant 
    for "transition" but what transition is that? And when will we drop the 
    enable_certificate_validation option?
[...]

The enable_certificate_validation option is meant to help transition from a deployment (or subset) that requires signature verification but does not yet have trusted certs configured, to a deployment (or subset) that can support both signature verification and certificate validation.  The enable_certificate_validation option would be dropped once sufficient time was given to set up trusted certs (and then verify_glance_signatures would always cause certificate validation as well), since the end goal is that certificate validation would always be performed along signature verification.

[1] https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/nova-validate-certificates.html#proposed-change
[2] https://review.openstack.org/#/c/560158/40/doc/source/user/certificate-validation.rst@19

Thanks,
~Brianna

On 6/12/18, 10:01, "Matt Riedemann" <mriedemos at gmail.com> wrote:

    Sylvain and I were reviewing https://review.openstack.org/#/c/479949/ 
    today and I'm at least a bit confused over how the 
    enable_certificate_validation config option is meant to be used.
    
    The current logic during driver.spawn() on the compute is going to be:
    
    if the user supplied trusted certs or verify_glance_signatures:
         ...
         if user supplied trusted certs:
             # validate the user supplied trusted certs
         elif enable_certificate_validation:
             raise error because the user did not provide certs
         else:
             noop
    
    I realize from the API change later in the series that if the user does 
    not provide trusted certs when creating or rebuilding a server, and 
    verify_glance_signatures=True, enable_certificate_validation=True and 
    default_trusted_certificate_ids=[something], we use the configured 
    default_trusted_certificate_ids so once we get down to the compute to 
    verify the image signature it will look like the user supplied trusted 
    certs (even if we are using the default_trusted_certificate_ids from 
    config).
    
    Is the point that, as an operator, I can say:
    
    verify_glance_signatures=True - yes verify image signatures (at least on 
    a subset of compute hosts)
    
    enable_certificate_validation - yes verify certs (at least on a subset 
    of compute hosts)
    
    default_trusted_certificate_ids=[] - but I don't want to provide default 
    trusted cert IDs, which forces my users to provider their own certs (at 
    least on a subset of compute hosts)
    
    In this scenario, if the user fails to provide trusted certs when 
    creating or rebuilding a server, it's going to result in a build abort 
    exception (NoValidHost) from the compute. Is that the intention?
    
    Also, the enable_certificate_validation option is deprecated and meant 
    for "transition" but what transition is that? And when will we drop the 
    enable_certificate_validation option?
    
    I'm trying to understand some of the upgrade flow here.
    
    -- 
    
    Thanks,
    
    Matt
    
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    



More information about the OpenStack-dev mailing list