[Engine-devel] Trusted Compute Pools

[Doron Fediuck]

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