Page History

...

Introduction

Trusted compute pools with 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.

...

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.

...

• 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

Test Guidelines

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.

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 with a cloudstack management server.
• The attestation service can be enabled or disabled through a global configuration parameter 'enable.attestation.service' (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 service server is already registered with the management server, any subsequent requests to register another attestation server will override the older registration.

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.
• 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 so, a whitelist configuration and registration, configureWhiteList followed by registerHost api calls are made to the attestation server. Open Issue 1
• 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 2.

Deploying an instance on a trusted host

Migration and HA

Database modifications

Web Services APIs

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.

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

Image Removed
Image Removed

...

<TBD>

Open Issues

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?