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 "vdcad...@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); > } > } > ... > }
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel