[Engine-devel] Trusted Compute Pools

[Wei, Gang]

Thanks a lot for such a detailed reply with good questions & suggestions.
Some comments below.

Jimmy

Itamar Heim wrote on 2012-11-30:
> On 11/20/2012 08:06 AM, Wei, Gang wrote:
>> Hi,
>> 
>> I am an engineer working in Intel Open Source Technology Center,
>> interested in integrating Intel initiated OpenAttestation(OAT) project
>> (https://github.com/OpenAttestation/OpenAttestation.git) into oVirt to
>> provide a way for Administrator to deploy VMs on trusted hosts hardened
>> with H/W-based security features, such as Intel TXT.
>> 
>> I made a draft feature page for this:
>> http://wiki.ovirt.org/wiki/Trusted_compute_pools
>> 
>> My draft idea is to provide trust_level requirement while doing vm
creation
>> like below:
>> 
>> curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
>>      -H "Content-type: application/xml"
>>      -d '<vm><name>my_new_vm</name>
>> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
>> <template id="00000000-0000-0000-0000-000000000000"/>
>> <trust_level>trusted</trust_level></vm>'
>>      'http://10.35.1.1/rhevm-api/vms'
>> Then oVirt Engine should query attestation server built with OAT via
RESTful
>> API to get all trusted hosts and select one to create the VM.
>> 
>> Attestation server performs host verification through following steps:
>> 1. Hosts boot with Intel TXT technology enabled
>> 2. The hosts' BIOS, hypervisor and OS are measured
> 
> a feature page on collecting bios info was just posted, please review it
> for your needs: http://wiki.ovirt.org/wiki/Features/Design/HostBiosInfo
> 
>> 3. These measured data is sent to Attestation server when challenged by
>> attestation server
> 
> does this has to be live or can be cached?

This has to be live.

>> 4. Attestation server verifies those measurements against good/known
>> database to determine hosts' trustworthiness
> 
> btw, you can do a uiplugin which adds a subtab or a field to an existing
> subtab so when standing on an intel host, user would see attestation
> status of the host from the attestation service.

Good suggestion.

>> Hosts need to be installed with OAT host agent to report host integrity
to
>> attestation server.
> 
> iiuc, this has nothing to do with vdsm, so this would be a plugin to the
> new ovirt-host-deploy host bootstrap script to install this rpm on hosts?

Yes, it has nothing to do with vdsm by far. I will look into how to update
ovirt-host-deploy host bootstrap script to install it.

>> By far, I am still in process of getting familiar with oVirt code and not
>> get solid idea yet on how the oVirt Engine should be modified to support
>> this feature.
>> 
>> Any kind of comments or suggestions will be highly appreciated.
> 
> several questions (apologies if covered in the feature page, i'm offline)
> 
> 1. is the attestation server open source and intended to be
>     packaged/deployed together with engine, or assumption is it is an
>     external service engine only needs to integrate with?
>     same question on anything needed to be deployed on host side.

Attestation server is open source, but it is expected to be deployed as a
separate service outside of ovirt engine. Ovirt engine need to integrate
with it. Host side need to deploy a host agent for attestation.

> 2. depending on first question - amount of configuration needed for
>     secure communication with the attestation service.

Yes.

I will think about your suggested approaches below throughout and then come
back to you.

> 3. I see two main approaches to implementing such a feature in engine
>     (regardless of the bundling/packaging/deployment aspects mentioned
>     above)
> a. fully integrated
> - adding a field to vm scheme with this field.
> - adding a set of config options for attestation service url and
>    authentication info
> - adding to RunVm command a method to check attestation aspects.
> 
> b. pluggable
> - this would be somewhat like the custom hooks in vdsm
> - you would add a custom property to vm for this field (no need for db
> scheme change, just a config change for this custom property. if the
> plugin is packaged with ovirt, it could be a predefined one, so user
> does not need to do anything. if the plugin is optional, then the plugin
> will configure this config key as well at deployment.
> - you can use a uiplugin to make this custom property appear as a main
> field in the vm dialog, but i think a custom property can be a good
> enough start. we have feature which are only implemented as custom
> properties (i.e., advanced options).
> - you will add an engine plugin to do the check (engine plugins do not
> exist yet).
> 
> more notes/thoughts:
> - Gilad is looking into making the scheduler pluggable and will send his
> thoughts on this. this means you could extend the scheduler with the
> check you want to do.
> - you can add a cluster level policy on allowed values for this field at
> vm level, this should also be possible via cluster level custom
> properties and plugins (when we'll have them).
> - should engine call attestation service for each host each time, or can
> just load a cache every X minutes for all hosts?
> 
> since there are several options for the final approach, i suggest you
> start with a POC based on the simplest option and check it is working,
> then hopefully the other tangents will converge or will revisit the best
> solution.
> 
> a POC patch would be a branch in your repo or the gerrit, flagged as WIP
> (work in progress) so it can be reviewed/commented/tested, but not
> merged till we revisit best approach for the feature (which may be to
> merge it and enhance at a later time as well, pending the other factors)
> 
> the POC should allow you to have a working solution based on private
> builds from the branch to test the integration.
> 
> for a POC patch i suggest: 1. use vm custom level property as simpler
> for first phase then changing the db scheme. 2. use bare minimum engine
> config support for service location/authentication. 3. assume no plugins
> and just add the code to the relevant part in RunVM which filters the
> relevant hosts:
> 
> relevant logic is in this class:
> ./backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Vds
> S elector.java
> 
> the getVdsToRunOn[1] method has a loop to filter irrelevant hosts, then
> to choose the best host.
> sounds like you need to add a hostValidator which will call the class
> actually communicating with the attestation service (or hopefully, will
> check against the cache this class maintains).
> 
> hope this makes things a bit more clearer on the available options.
> 
> Thanks,
>     Itamar
> [1] private Guid getVdsToRunOn(Iterable<VDS> vdss, boolean isMigrate) {
>          StringBuilder sb = new StringBuilder();
>          final List<VDS> readyToRun = new ArrayList<VDS>();
>          for (VDS curVds : vdss) {
>              if (validateHostIsReadyToRun(curVds, sb, isMigrate) ==
> ValidationResult.VALID) {
>                  readyToRun.add(curVds);
>              }
>          }
> ...
>      }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8586 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20121201/92e9d549/attachment.p7s>