Mirantis OpenStack

  • Download

    Mirantis OpenStack is the zero lock-in distro that makes deploying your cloud easier, and more flexible, and more reliable.

  • On-Demand

    Mirantis OpenStack Express is on demand Private-Cloud-as-a-Service. Fire up your own cloud and deploy your workloads immediately.

Solutions Engineering

Services offerings for all phases of the OpenStack lifecycle, from green-field to migration to scale-out optimization, including Migration, Self-service IT as a Service (ITaaS), CI/CD. Learn More

Deployment and Operations

The deep bench of OpenStack infrrastructure experts has the proven experience across scores of deployments and uses cases, to ensure you get OpenStack running fast and delivering continuous ROI.

Driver Testing and Certification

Mirantis provides coding, testing and maintenance for OpenStack drivers to help infrastructure companies integrate with OpenStack and deliver innovation to cloud customers and operators. Learn More

Certification Exam

Know OpenStack? Prove it. An IT professional who has earned the Mirantis® Certificate of Expertise in OpenStack has demonstrated the skills, knowledge, and abilities needed to create, configure, and manage OpenStack environments.

OpenStack Bootcamp

New to OpenStack and need the skills to run an OpenStack cluster yourself? Our bestselling 3 day course gives you the hands-on knowledge you need.

OpenStack: Now

Your one stop for the latest news and technical updates from across OpenStack ecosystem and marketplace, for all the information you need stay on top of rapid the pace innovation.

Read the Latest

The #1 Pure Play OpenStack Company

Some vendors choose to “improve” OpenStack by salting it with their own exclusive technology. At Mirantis, we’re totally committed to keeping production open source clouds free of proprietary hooks or opaque packaging. When you choose to work with us, you stay in full control of your infrastructure roadmap.

Learn about Our Philosophy

Trusted Cloud computing with Intel TXT: The challenge

on April 16, 2014

In today’s connected environments, attacks on compute infrastructure are ubiquitous. Major players have been compromised by hackers and malware, with damages inflicted both to their reputation and their business. Protecting the infrastructure from external and internal threats is an important part of operating production grade cloud environments.

Interested in hearing more about this topic?  Vote for Christian’s talk, Securing OpenStack with Intel Trusted Computing.

Approaches to meeting this challenge range from hoping it will not hit one’s own environment to fully locking down the environment with heavy gatekeepers and restrictive policies.

What is Intel TXT?

Intel Trusted Execution Technology (TXT) is a combination of hardware and software aimed at securing the execution of sensitive workloads.

In contrast to solutions that protect the Operating System, Intel TXT builds a chain of trust from the system firmware all the way to the server or hypervisor to prevent attacks on system firmware or BIOS, MBR, boot loader, OS and hypervisor.

Every component in this chain is verified against known good states and, depending on the result, marked either trusted or untrusted.

This approach allows detection of not only threats to the OS itself, such as viruses, but also attacks on the configuration and even manipulation of the server’s boot firmware and hardware. When a breach is detected, workloads that require secure execution can not be executed on this server.

How does this approach meet the challenge?

An entity attacking a cloud environment can choose many different paths, but unless the workload itself is attacked, the attack will leave traces in one or more of the Platform Control Registers (PCR). A changed value in a PCR results in a break in the chain of trust, which is then detected by TXT and leads to the resource being marked as untrusted. This happens both during boot and while the platform is running.

When a workload is scheduled, the trust status of the potential compute resources is verified by the scheduler. New workloads are only scheduled on compute resources that are still trusted.

Components to an Intel TXT environment

Servers used in Intel TXT contain a number of components to allow calculation of the required fingerprints and enable a trusted environment.

 

  • The Processor and server chipset must support Intel TXT extensions.
  • A TPM module (usually third party silicon) allows storing vendor and owner policies for ‘known good’ state.
  • The TPM also allows signing of PCR values that are transmitted to the attestation service.
  • BIOS and OS must contain Authenticated Code Modules (ACM) to build a complete chain of trust for TXT support.
  • A Launch Control Policy (LCP) allowing comparison of Platform Control Registers (PCR) with known good values.

 

During system boot and operation, the PCRs get populated with values that can then be compared locally with values in the TPM and remotely with known good values on the Attestation Server.

The OpenAttestation Server is a service that can be run on a separate compute resource, or if desired, on a virtual machine. It confirms or denies the Trusted status of a system based on PCR values submitted to it.

Integration with OpenStack

OpenStack Grizzly and newer versions provide a Trusted Filter for Filter Scheduler that uses Intel TXT to schedule workloads requiring trusted execution only to trusted compute resources. Clusters can have both trusted and untrusted compute resources.

Workloads not requiring trusted execution can be scheduled on any node, depending on utilization, while workloads with a trusted execution requirement will be scheduled only to trusted nodes.

An overview of the flow of information on a trusted compute request can be found in the OpenStack documentation:

inteltxt

Fig. 1:  Trusted computing attestation process. (Source: http://docs.openstack.org/grizzly/openstack-compute/admin/content/trusted-compute-pools.html, License: Apache 2.0)

In this graph the OpenAttestation Server is communicating with all compute nodes to determine a pool of trusted resources [1]. An API request is received with trust_lvl set to trusted [2]. The scheduler reaches out to the OpenAttestation Server to determine a trusted resource [3] via a RESTful API call. Upon receiving a pool of trusted resources, the scheduler schedules the workload on a machine inside the trusted compute pool [4].

Implementation example of an OpenStack cluster with Intel TXT support

Intel TXT support can be added to an existing cluster, provided the hardware is TXT capable. In this case, an existing cluster was modified.

An OpenAttestation Server was set up first. It is possible to use a VM inside the cluster to deploy OpenAttestation, but for security and maintainability reasons, the decision was made to use an external host for this environment. At the moment OpenAttestation 1.6, 2.0 and 2.1 are available, but Intel recommended using 1.6 for this project.

Interested in hearing more about this topic?  Vote for Christian’s talk The TPM hardware and Intel TXT were enabled in the BIOS of all compute nodes that were to be designated to be trusted. OpenAttestation Clients were installed on the controllers and all trusted compute nodes. Initial values of the PCMs were then added to the OpenAttestation Server.

The OpenStack configuration was modified to use TrustedScheduler instead of the default scheduler.

A trusted flavor was created to allow distinction between workloads that require trusted execution and workloads that don’t. To achieve this, the trust:trusted_host flag must be set in the newly created instance. Alternatively one or more existing flavors can be designated as trusted.

It was demonstrated that workloads scheduled with the trusted flavor would only be scheduled onto the trusted compute nodes, whereas workloads that were launched with a non-trusted flavor would be scheduled to any host.

Further security considerations

Attacks to an application that do not leave traces on the system level (e.g. SQL injection) will not trip the Trusted status of a compute node in Intel TXT. This is correct and expected behavior, because in this case the application, not the platform, is compromised. Applications requiring a high trust level must be secured separately with a combination of secure design, development best practices and thorough testing.

Finally, operations security with monitoring, security tests and audits  is necessary to spot threats before they develop into breaches.

Conclusion

Platform security with Intel TXT is a big step in the direction of securing OpenStack cloud platforms with a chain of trust spanning hardware, firmware and operating system. Integration into OpenStack is available and has proven reliable. Being able to run a cluster with both trusted and untrusted hosts strikes a balance between administration effort and security requirements.

However, Intel TXT is not a monolithic security solution, but in conjunction with application level security, monitoring and security audits is a cornerstone of a successful cloud security concept.

1 comment

One Response

Continuing the Discussion

  1. OpenStack中国社区周报 (3/1-3/7) « OpenStack中国社区

    […] 原文链接:http://www.mirantis.com/blog/challenge/ […]

    March 7, 201401:33

Some HTML is OK


or, reply to this post via trackback.