[Engine-devel] Trusted Compute Pools
Itamar Heim
iheim at redhat.com
Fri Nov 30 10:57:09 UTC 2012
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?
> 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.
>
> 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?
>
> 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.
2. depending on first question - amount of configuration needed for
secure communication with the attestation service.
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/VdsSelector.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);
}
}
...
}
More information about the Engine-devel
mailing list