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

Requirement:

• CloudStack will work with an attestation server to secure the deployed Hosts - the attestation server has the capability to compare launch values against "known good"
• When setting up a cloudstack environment, automatically understand which hosts are "trustworthy" and present it to the admin.
• Administrators are able to create a service offering that will allow users to select if they need the VMs to be deployed on trusted hosts.
• Ensure that instances requested in such a manner are always placed on trusted hosts. Instances that do not require a trusted host will not be blocked from getting deployed on a trusted host.
• Whenever a trusted host or the attestation server itself is rebooted, verify the trustworthiness.
• Migration of VM from a trusted to untrusted host should be allowed but it should raise an alert.

Non requirements

• The attestation server will not be managed by cloudstack. It'll have to be setup and configured and then registered with cloudstack for checking the trust attributes of a host.
• For checking the trust assertions of a host, a trust agent should be running on the host. Attestation server checks with the agent the trust relationship of the host. The trust agent should already have been configured.

...

• Only one attestation server can be registered with a per zone in cloudstack management server.
• The attestation service can be enabled or disabled through a global configuration parameter 'enable.attestation.serviceenable' (Boolean: true/false). It'll be disabled by default.
• A root administrator can register the details of an attestation server by making a registerAttestationServer api call. This is an async call. Cloudstack management server will open a connection to the attestation server and it'll use the KeystoreUtil.createUserInDirectory client library api call to register/create a user. On successful registration the attestation server details will be persisted in the db.
• The above request for a new user needs to be approved by an attestation server administrator. This is a manual process and will be included in the documentation.
• If an attestation server is already registered with the management server, any subsequent requests to register another attestation server will override the older registration.will fail. Administrator will have to unregister with the existing attestation server and carry out a new registration.

Registering a host for attestation

• A host has to be registered with the attestation server so that it can be checked if it is trusted or not. It can be done with the registerHostWithAttestationServer api.
• The api goes ahead and does whitelisting of the host and then registers the host with the attestation server.
• Trust assertion checks are also done on the host and it is tagged as trusted if the assertion checks are successful.

Checking the trust relationship of an host

• Whenever management server connects to a host, the processConnect callback routine gets triggered for the plugin.
• It verifies if attestation check is enabled in the global config and if an attestation server has been registered for the zone to which the host belongs.
• It opens a connection to the attestation server with the credentials registered with cloudstack.
• It then checks the assertion attributes for the host; i.e if the host is trusted or not. For that it makes an api.getSamlForHost(<HostIp>) call.
  • If a host assertion not available exception is thrown, it means the whitelist configuration for the host hasn't been done and it hasn't been registered with the attestation server.
  • To do the whitelist configuration and registration of host a configureWhiteList followed by registerHost api calls are made to the attestation server. Open Issue 1.
  • If the host assertion checks return that either the Vmm or Bios assertions are not valid, the host is untrusted.
  • Otherwise the host is trustedThese calls will be needed only when management server connects to a host for the first time.
• The assertion attributes are checked to make sure the host is trusted. Accordingly the host_details table is updated with a new name value pair 'trusted':true/false. Open Issue 2If the host assertion checks are successful and the host is identified to be trusted, it is tagged accordingly. A 'Trusted-Host' tag is applied on the host. If the host is identified to be untrusted, any such tag is removed from the host. The tag applied can be configured through global configuration parameter 'attestation.hosttag'.

Deploying an instance on a trusted host

• The A 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.)
• 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.
    Note: This section will be updated when we have 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.

Migration and HA

• can be created with an appropriate host tag, "Trusted-Host" by default.
• Any instance deployed with such a service offering will be placed on a trusted host.
• For such an instance, for migration only a trusted host will be marked as suitable for migration. The administrator may choose to migrate it to an untrusted host.
• Similarly for HA, cloudstack will move it only to a trusted host.
• 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.

Database modifications

A new table will be created in the db to hold the attestation server details. Open Issue 4.

Web Services APIs

1. registerAttestationServer : A new api to register an attestation server with cloudstack. It will take the details of the attestation server as a parameter and check if a connection can be established to it.

   Parameters	Type	Required/Optional	Comments
   url	String	Required	Url of the attestation server
   username	String	Required	Username with which cloudstack should register and connect with the attestation server
   password	String	Required	Password with which cloudstack should register and connect with the attestation server

...

1. zoneid

...

1. UUID

Hypervisor support

The functionality will be made available for VmWare, KVM and XenServer.

Supportability characteristics

Logging

All successful operations are logged to INFO, all exceptions/failures to ERROR, and all synchronization checks to DEBUG.

Events/Alerts

If an instance created from a service offering requires a trusted host and it is placed on an untrusted or unattested host, an alert will be raised to bring it to administrators attention.

UI Flow

<TBD>

Open Issues

...

1. Required	Zone to which the attestation server will be registered with
   name	String	Optional	Friendly name the identify the attestation server

   
   

   Response Object	Comment
   AttestationServerResponse	The parameters contained in the response object are uuid, url and username

2. listAttestationServer : A new api to list the attestation server registered with cloudstack. It will return AttestationServerResponse in response.

   Parameters	Type	Required/Optional	Comments
   id	UUID	Optional	Attestaion server id

3. unregisterAttestationServer : A new api to unregister an attestation server. It will return SuccessResponse.

   Parameters	Type	Required/Optional	Comments
   id	Uuid	Required	Id of the attestation server

4. registerHostWithAttestaionServer : A new api to register a host with the attestation server. It will whitelist and register the host with the attestation server. It will return RegisterHostWithAttestaionServerResponse object.

   Parameters	Type	Required/Optional	Comments
   id	Uuid	Required	Id of the host. This host gets whitelisted and registered with the attestation server registered for the zone to which the host belongs

   
   

   Response Object	Comment
   RegisterHostWithAttestaionServerResponse	The parameters contained in the response object are id of the host, attestation server id and flags detailing whether whitelisting, registeration and trust assertion of the host were successful.

Test Guidelines

<TBD>

Hypervisor support

The functionality will be made available for VmWare, KVM and XenServer.

Supportability characteristics

Logging

All successful operations are logged to INFO, all exceptions/failures to ERROR, and all synchronization checks to DEBUG.

UI Flow

The feature will be accessible only through apis. Whether a host is trusted or not can be established by looking at its tags.

...