← Back to team overview

openstack team mailing list archive

Re: nova and trusted computing


I would like to document my counter-proposal for trusted computing in Nova here.

Trusted computing requires functionality in the scheduler that filters hosts based on information that can only be gathered from a third party attestation server. The information cannot be trusted from the actual compute node or host directly. Furthermore, this information takes a nontrivial amount of time for the attestation server to gather--we cannot simply expect to do a full attestation for each relevant host each time we see an instance request.

So the problem that the trusted computing blueprint must address is: How are we going to cache the trust information about hosts?

My view is that the attestation server (which lives outside of openstack) should be responsible for this caching. First, putting the caching in Nova seems too invasive. Second, it seems likely that other attestation clients would not want to do their own caching as well, so it would be good for TC in general to have this feature. 

Some caching is already a part of the attestation server, but it is done based on the request id. That is, the api looks like

Request: POST attestation/PostHosts {"hostnames": ["host1", "host2", ...]}
Response: { "QueryServiceId": <request-id> }

Checking back later:

Request: GET attestation/<request-id>
Response: { "host1": {"trust_state": "trusted", "timestamp"...},
            "host2": {"trust_state": "not cool", "timestamp"...}, ... }

This doesn't work well for the scheduler because when an instance create request comes in, we cannot know the ids of the previous requests we have made to attestation service. 

HOWEVER: If the attestation API also exposed the results per host, rather than only per request id, the problem would be solved. That is, if a filter in the scheduler could perform relatively fast queries like

Request: GET attestation/Hosts/host1
Response: { "trust_state": "trusted", "timestamp": ...}

then TC wouldn't require anything other than the ability to plug third party libraries into the scheduler filter mechanism.

I am of course relatively unfamiliar with trusted computing, so I am interested to hear any reasons why this proposal is infeasible.

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

> 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@xxxxxxxxxxxxxxxxxxx
>> [mailto:openstack-bounces+fred.yang=intel.com@xxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxx
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp