----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Gang Wei" <gang....@intel.com> > Cc: engine-devel@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 "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 > >> 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@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel