----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Gang Wei" <gang.wei(a)intel.com>
Cc: engine-devel(a)ovirt.org
Sent: Friday, February 8, 2013 2:02:41 PM
Subject: Re: [Engine-devel] Trusted Compute Pools
On 01/02/2013 10:25, Wei, Gang wrote:
> Design page updated according to in process Patchset 2.
>
http://wiki.ovirt.org/wiki/Trusted_compute_pools.
Hi Wei,
in general, looks good.
currently, user who creates the VM can choose the value for this
field.
i wonder if it should be limited to web admin, and not exposed to
power
users (user portal)
another way to think about this is do you want to set it at cluster
policy level, and/or if you want to give a specific permission which
is
required to edit this field (then users with this permission can
override the cluster policy maybe.
all this can wait of course, and is not blocking the patch for basic
functionality to get community feedback (but may be worth documenting
as
"open question / future thoughts" in the wiki.
two other thoughts/question
1. may be worth allowing to override the setting for this field in
run-once dialog.
2. currently, the dialog allows to choose "run on trusted node"
aren't the various values in TrustLevel enum relevant here for the
user?
(nit: should probably s/node/Host/)
Thanks,
Itamar
Agree on the cluster level use-case. Actually it may be more effective
to move attestation decision to cluster level in general, so you will
have an attested-cluster. Otherwise, you may have issues during migration
and load balancing which may fail other functionalities in the system.
Think of a use case where you want to upgrade the current hosts. If you
have a mixture of attested on non-attested hosts you may have to take down
a trusted VM since there's no suitable host for it. This will be easy
when working in attested-cluster where all VMs are free to migrate as
needed based on capacity only.
If you choose to keep attestation in VM-level, please explain how do you
plan to handle the cases I mentioned (migration, etc).
Additionally I'll be glad to see a more detailed design with reference
to the various parts- RESTful API, Engine and UI.
Thanks!
Doron
>
> Jimmy
>
> Wei, Gang wrote on 2012-11-20:
>> 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(a)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
>> 3. These measured data is sent to Attestation server when
>> challenged by
>> attestation server
>> 4. Attestation server verifies those measurements against
>> good/known
>> database to determine hosts' trustworthiness
>>
>> Hosts need to be installed with OAT host agent to report host
>> integrity to
>> attestation server.
>>
>> 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.
>>
>> Thanks
>> Gang (Jimmy) Wei
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel