openstack team mailing list archive

["Mark Washenberger" <mark.washenberger@xxxxxxxxxxxxx>]

Do we need anything more than a way to inject a third-party filter into schedulers?

I'm assuming that we need to schedule based on whether or not the attestation server verifies the host. And I understand that this situation introduces some peculiar and novel requirements on the scheduler. But I don't think it makes sense to deduce from that that we should write an attestation client into nova and create a new scheduler and manager service. Instead, we should robustify (is that even a word? :-) the plug-ability of the scheduler with these requirements in mind.

I really appreciate the work that has gone into making this transparent and generic with the standalone http-based attestation server. I just don't think it goes quite as far as it needs to. 

"Yang, Fred" <fred.yang@xxxxxxxxx> said:

> 
> 
>> -----Original Message-----
>> From: openstack-bounces+fred.yang=intel.com@xxxxxxxxxxxxxxxxxxx
>> [mailto:openstack-bounces+fred.yang=intel.com@xxxxxxxxxxxxxxxxxxx] On
>> Behalf Of Vishvananda Ishaya
>> Sent: Friday, December 09, 2011 11:33 AM
>> To: Michael Pittaro
>> Cc: OpenStack Mailing List; Mark Washenberger
>> Subject: Re: [Openstack] trusted computing and nova
>>
>> I suggested a couple alternative solutions for implementations in one
>> of the reviews.  Hoping to hear back from fred yang/intel on whether
>> one of those solutions will work.  Copied suggestions here in case
>> anyone else is following along.
>>
>> Brian Waldon and I were discussing the possibility of a couple
>> different approach for trusted computing which wouldn't require adding
>> a separate component and scheduler.
>>
>> 1. add an admin api to add and remove hosts from an availabilty zone.
>> Then the component that is verifying trust could periodically check the
>> hosts and remove them from the trusted zone if they fail. The scheduler
>> could just use regular availability-zone scheduling to send the hosts
>> to the trusted zone.
> Service providers can have mixed computing nodes of trusted or non-trusted nodes
> dispatched pending on subscribers' demands.  The intent is to make "trust" to be
> transparent to providers' zone setup
>>
>> 2. rather than verify trust during schedule, provide an external
>> service that is exposed to users where they could verify trust. They
>> could basically request the trust state of an instance. The service
>> would speak to nova through an admin api to discover which host the
>> instance is running on and verify the trustedness of the host, and
>> return "trusted" to the user if the node passes.
> If understand correctly, this approach is to address after fact that Nova
> scheduler have selected-and-run instance.  This approach can directly impact/break
> subscriber's needs/data already since instance  has been started and would need
> subscribers intervention.  This is why we need to perform scanning through
> scheduler
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>