Page History

...

http://www.intel.com/content/www/us/en/architecture-and-technology/trusted-execution-technology/malware-reduction-general-technology.html
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups

Document History

...

Deploying an instance on a trusted host

• A new TrustedHostProcessor will be provided. It will implement AffinityGroupProcessor. It'll exclude all the hosts that are not trusted.
• User can list the processor types available using listAffinityTypes API.
• User can create a trusted group using the types available.
• During VM deployment, user can specify trusted group id to be associated with the instance. Looking at the affinity group, the corresponding plugin that can handle this type will then process to set the deployment scope
• The service offering functionality will be updated to include an option for 'Use Trusted hosts'. Open Issue 3. How should this change be reflected. Should we provide a check box, like it is done for HA. As listed in the open issues, will the information be passed to the planners using a name/value pair (as has been proposed for Dedicated resources feature.)
  Note: This section will be updated when we get more clarity on how to make the option of using trusted hosts available in service offering and how this information will be passed to the allocators.
• Host allocators will be updated as follows.
• If a service offering specifies a trusted host is needed, host allocators will be updated to select a host only if it trusted.
If a service offering doesn't require a trusted host, host allocators will not restrict the deployment to untrusted hosts. A trusted host may get picked up for deployment too.

Migration and HA

• When hosts are listed for migration of an instance, if an instance is using an offering which requires trusted host, the host allocators will be updated to not to include hosts that are not trusted (information stored in the host_details table in the db). These hosts will be marked as 'Unsuitable' for migration (as seen in UI).
• Migration of instances using offering requiring trusted hosts, to untrusted hosts will be allowed. However, an alert will be raised to bring this to administrators attention.
• If an instance using a offering requiring trusted hosts goes down and HA is triggered for it, management server will try to bring it up on host that is trusted. If no trusted hosts are available HA for the instance will fail.

...

Web Services APIs

...

1. The documentation available suggests that the configureWhiteList and registerHost api calls can be used for registering a server for attestation. These apis haven't been tried as part of poc. Need to confirm this. Should we keep the white list configuration and registration of a host out of the scope? Additionally, should management server check with the attestation server if a host is trusted or not and on getting a host not registered exception, register it? Or instead, keep the information on whether a host is registered or not in the db.
2. Proposal is to fill the host_details table with an additional attribute for an host on checking if it is trusted or not. Should this information be stored elsewhere, probably in a separate table?
3. For Anti-affinity and Dedicated resources features changes are being made to address how an instance is deployed. It'll also affect this feature. For the current feature, changes are needed in the host allocators to not to pick up an untrusted host if the service offering requires trusted host. How should a service offering be updated to include the information that a trusted host is required? Should it be done using name/value pairs, as has been suggested for Dedicated resource feature. However, name/value pairs will be the property of a planner (I could be wrong); and here we need to pass this information to the allocators.
4. Should the attestation server details be kept in a new table or can they be kept in the <db>.host table itself?