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" <mriede...@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-requ...@lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to