Open Stack

On 4/18/2018 11:57 AM, Jay Pipes wrote:
>> There is a compute REST API change proposed [1] which will allow users 
>> to pass trusted certificate IDs to be used with validation of images 
>> when creating or rebuilding a server. The trusted cert IDs are based 
>> on certificates stored in some key manager, e.g. Barbican.
>>
>> The full nova spec is here [2].
>>
>> The main concern I have is that trusted certs will not be supported 
>> for volume-backed instances, and some clouds only support 
>> volume-backed instances.
> 
> Yes. And some clouds only support VMWare vCenter virt driver. And some 
> only support Hyper-V. I don't believe we should delay adding good 
> functionality to (large percentage of) clouds because it doesn't yet 
> work with one virt driver or one piece of (badly-designed) functionality.

Maybe it wasn't clear but I'm not advocating that we block the change 
until volume-backed instances are supported with trusted certs. I'm 
suggesting we add a policy rule which allows deployers to at least 
disable it via policy if it's not supported for their cloud.

>  > The way the patch is written is that if the user attempts to
>> boot from volume with trusted certs, it will fail.
> 
> And... I think that's perfectly fine.

I agree. I'm the one that noticed the issue and pointed out in the code 
review that we should explicitly fail the request if we can't honor it.

> 
>> In thinking about a semi-discoverable/configurable solution, I'm 
>> thinking we should add a policy rule around trusted certs to indicate 
>> if they can be used or not. Beyond the boot from volume issue, the 
>> only virt driver that supports trusted cert image validation is the 
>> libvirt driver, so any cloud that's not using the libvirt driver 
>> simply cannot support this feature, regardless of boot from volume. We 
>> have added similar policy rules in the past for backend-dependent 
>> features like volume extend and volume multi-attach, so I don't think 
>> this is a new issue.
>>
>> Alternatively we can block the change in nova until it supports boot 
>> from volume, but that would mean needing to add trusted cert image 
>> validation support into cinder along with API changes, effectively 
>> killing the chance of this getting done in nova in Rocky, and this 
>> blueprint has been around since at least Ocata so it would be good to 
>> make progress if possible.
> 
> As mentioned above, I don't want to derail progress until (if ever?) 
> trusted certs achieves this magical 
> works-for-every-driver-and-functionality state. It's not realistic to 
> expect this to be done, IMHO, and just keeps good functionality out of 
> the hands of many cloud users.

Again, I'm not advocating that we block until boot from volume is 
supported. However, we have a lot of technical debt for "good 
functionality" added over the years that failed to consider 
volume-backed instances, like rebuild, rescue, backup, etc and it's 
painful to deal with that after the fact, as can be seen from the 
various specs proposed for adding that support to those APIs.

-- 

Thanks,

Matt