Open Stack

Vish,

Mark and I have worked a while and yet to have a get a better approach.  Let me describe key features need to be addressed and a possible approach for base discussion

Nova scheduler's select_and_run can dispatch N instances directly which makes trusted computing a little bit challenge.

To achieve trusted computing, we should achieve following requirements
1. Provide hosts' trust cache to Nova scheduler as capability - similar to existing "Compute" capability
2. Refresh host trust state if the host is rebooted "since"
3. Computing pools should support trust state enforcement, that is, instances should not be launched on trusted node(s) is no trust requirement is specified
4. Plug-in approach and reuse nova core as much to keep it small - this has been done through nova FLAGS.  If not configured, then no trusted computing code will be exercised
5. https client connection to attestation server - we can refine this to be more generic usage to other nova components


On Requirement#1 - 'Trust' caps should be in its own cap than in 'Compute' because Hosts periodically updates 'Compute" caps through AMPQ.  Also, 'Trust' data should be from a trusted entity, Attestation server which exporting REST API.  Trust caps should also be ready scheduler filter, similar to 'Compute' cap 

On Requirement#2 - A Host may be rebooted since last trust state check point, so the logic is to reuse and align on existing hosts keep-alive ticks mechanism to track if a host is rebooted_since.   Note nova knows heartbeats of all the compute nodes.

To accomplish Requirement #1 and #2, a daemon derived from SchedulerManager to periodically identify rebooted_since nodes and refresh the trust cache is any

To accomplish Requirement #3, a new json filter is derived from existing json_filter to perform nodes filtering twice if no trust req. specified by the instance

Above patches can all be turned on/off by FLAGS control without embedding code into existing nova code

Suggestion?

-Fred




> -----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: Tuesday, January 03, 2012 12:33 PM
> To: Mark Washenberger
> Cc: Openstack Mailing List
> Subject: Re: [Openstack] nova and trusted computing
> 
> Hey Mark,
> 
> I agree with the comments you have made on the merge prop so far, and
> I'm glad you've been working with the authors to find something more
> amenable.  I'm all for keeping the responsibilities of nova small and
> adding plug-in points and extensibility to support these types of
> features.
> 
> Vish
> 
> On Jan 3, 2012, at 7:00 AM, Mark Washenberger wrote:
> 
> > Nova folks,
> >
> > I have some concerns about the approach adopted in the trusted
> computing blueprint
> >
> > https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools
> > http://wiki.openstack.org/TrustedComputingPools
> >
> > Basically, the assumption of this blueprint is that Nova has to be
> responsible for caching the "trust" status of hosts. In order to do
> this without allowing hosts to lie to the scheduler, a long lived
> component must be created. My sense is that this approach is too
> invasive and inappropriately pushes responsibilities from the "trust"
> infrastructure into Nova.
> >
> > I have been working with Fred Yang to try to address these concerns--
> and I'm confident that Nova can adjust in a reasonable way to
> accommodate trusted computing. However, the blueprint appears to have
> been approved with the approach I don't like baked in, and I don't want
> to overstep.
> >
> > So I ask: Is there a consensus among nova-core that the approach
> given in the blueprint needs to be changed? Or the other way around, is
> there a consensus approving of this approach?
> >
> > Thanks
> >
> >
> > Mark Washenberger
> > Rackspace Hosting
> > Software Developer
> > mark.washenberger at rackspace.com
> >
> >
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> 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