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" <[email protected]> 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: [email protected]
>> [mailto:[email protected]] 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
>> > [email protected]
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : [email protected]
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : [email protected]
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
