Support for Intel TXT Technology

Bug Reference

Branch

master, 4.2.0

Introduction

Trusted compute pools with Intel Trusted Execution Technology enable isolation and tamper detection in boot process and complement run time protections. Meanwhile, hardware-based trust provides verification useful in compliance and trust status, which security and policy applications use to control workload.

Using Intel's TXT technology, a number of painpoints of a secure computing environments can be addressed. For example, Isolation is a key concern in a shared infrastructure where a lack of traditional guarantees of physical separation are lacking and multiple workloads may interfere with each other. Enforcement i.e. controls needed to enforce protection of Infrastructure can prevent pre-runtime environments are target of new attacks and low-level attacks are hard to detect and can be difficult to recover from. Encryption is another problem that can get worse in a cloud where data protection can be harder due to lack of boundaries and multi-tenancy.

Source: Intel TXT Overview

Purpose

This document describes the specifications and design of the feature.

References

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.

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.

Glossary

Feature Specification

Uses Cases

• A user wants to deploy an instance on a platform/OS/VMM for which trust verification has been done.
  • Administrator creates a service offering which enables deployment of an instance on only trusted user.
  • The service offering is made available to the user.
  • The user chooses this service offering while deploying an instance. Cloudstack picks up only trusted host in the deployment plan for deploying the instance.
• A user wants to move his instance to a host for which trust verification has been done.
  • The instance is shutdown/stopped by issuing a stopVirtualMachine call.
  • The service offering for the instance is updated. The new service offering allows deployment of an instance on only trusted host.
  • Instance start request is placed. Cloudstack only picks up trusted hosts to deploy it.

Architecture and Design description

Dependency on the attestation server client library
A java client library is available for easy integration with the attestation server. Cloudstack will be using it to register with the attestation server and to check for the trust relationship of a host. The library and this feature will be made available under non-oss.

Feature will be contained in a plugin

• The feature will be implemented and contained in a new plugin.
• It will provide the api for registering the attestation server with cloudstack.
• It will implement a listener for getting host connect notifications. It'll register with the agent manager to get the processConnect callbacks when agent connects to a host. On getting the callback it'll check with the attestation server (if configured) whether the given host is trusted or not. The callback gets called in the following scenarios
  • When a new host is added to the infrastructure.
  • When management server comes up and connects to the host.
  • When the host reboots/boots up, cloudstack will issue a processDisconnect callback when it looses connection and a processConnect callback on being able to connect again.

Registering an attestation server with cloudstack

• Only one attestation server can be registered per zone in cloudstack management server.
• The attestation service can be enabled or disabled through a global configuration parameter 'attestation.enable' (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 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.
  • If the host assertion checks return that either the Vmm or Bios assertions are not valid, the host is untrusted.
  • Otherwise the host is trusted.
• The assertion attributes are checked to make sure the host is trusted. If 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

• A service offering 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.

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
   zoneid	UUID	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.