[Openstack] trusted computing and nova
mark.washenberger at rackspace.com
Fri Dec 9 21:34:34 UTC 2011
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 at intel.com> said:
>> -----Original Message-----
>> From: openstack-bounces+fred.yang=intel.com at lists.launchpad.net
>> [mailto:openstack-bounces+fred.yang=intel.com at lists.launchpad.net] 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
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
More information about the Openstack