Improving OpenStack*
Hybrid Cloud Security
Together, Intel, Mirantis, and IBM SoftLayer demonstrate how Intel® Trusted Execution
Technology, attestation, and automation can enhance hybrid cloud security.
Private data centers strive to optimize efficiency and improve utilization.
However, when utilization peaks, it can diminish the data center’s ability to absorb bursts of demand or to accommodate workloads of an indeterminate lifespan or unknown viability. To address this problem these workloads are often deployed in a public cloud.
Intel believes that a secure hybrid cloud—a mixture of public and private deployments—is an important component of its effectiveness and efficiency. Even with public deployments, we must have transparent oversight of the deployment’s location and security to meet our fiduciary and efficiency goals. Therefore our cloud platform strategy stresses uncompromising security and control in both public and private deployments, while prioritizing three long-term objectives:
• Open, interoperable software
infrastructure. Help avoid vendor lock-in, accelerate component development, and facilitate collaboration with other large- scale enterprises.
• Automated cloud resource management.
Address rapidly changing end-user
demands, multitenancy, and utilization without compromising security or service-level agreements.
• Hybrid private/public architecture.
Establish a high-utilization, private cloud to run trusted, secure, mission- critical services and enable continuous operations, complemented by an on- demand public cloud for bursting and scaling under a predictable, pay-per- use cost model.
Intel took an agile, DevOps approach to building our hybrid cloud, basing our work on OpenStack*. Internal reference OpenStack deployments have helped us evolve our data center roadmap and business objectives. At the same time, we have used these deployments as platforms for proving the business value of Intel’s innovations and contributions to OpenStack open source projects in real-world environments. The next logical step was to create a reference hybrid deployment to demonstrate that a hybrid cloud environment can support enterprise-level security.
Hybrid Cloud Security
Private Cloud Public Cloud Hybrid
Cloud
Solution Provided By:
2
Proof of Concept
Running enterprise applications on a hybrid cloud presents several challenges.
An enterprise wants assurance that workloads are running on trusted infrastructure, isolated from other cloud subscribers. It also wants to know whether the required compute cycles are guaranteed and whether the service and the workload portability are reliable (see Figure 1).
To demonstrate that a hybrid cloud can address many of these challenges using today’s technology, Intel, Mirantis, and IBM SoftLayer designed a series of tests to validate that secure workloads were deployed only on virtual machines (VMs) located on physical hosts where their trust was validated through Measured Launch Environment (MLE) and attestation.
Throughout Intel’s cloud initiatives, we have learned that agility pays off.
“Go ahead and build it” is a good plan as long as rapid iteration does not compromise the principles of stability, availability, and security. Although the team did not expect to build the perfect solution, the proof of concept demonstrated the viability of building a secure OpenStack hybrid cloud using
heterogeneous hardware managed through a single management platform.
Intel® Trusted Execution Technology (Intel® TXT)1 enhanced infrastructure integrity and security in both the public and private components of the cloud:
• Public cloud component. The externally hosted cloud component was hosted on IBM SoftLayer, using server platforms with Trusted Platform Modules (TMPs) and the appropriate BIOS to utilize Intel TXT. The TPM, Intel TXT, and attestation created an MLE, within which externally hosted VM workloads could be securely executed.
• Private cloud component. The internally hosted cloud component used servers enabled with Intel TXT that were similarly measured, providing the attestation server with the ability to ensure a comparable trusted configuration. To facilitate private management communication between Intel and SoftLayer, a virtual private network (VPN) was established between the internal and external sites. A single Horizon dashboard and attestation service was hosted on the internal OpenStack cluster and was enabled to manage both locations.
Figure 1. Trust, performance, reliability, and portability are major challenges when running enterprise workloads in a hybrid cloud.
Meet the Team
Intel
Intel’s work on cloud initiatives spans multiple groups. One group may test and benchmark new technologies, another group may make key contributions to the open source community, and other groups may develop marketable technologies and help integrate them into the open cloud computing market. Examples of such activities include the development of Intel® Trusted Execution Technology and Intel® Service Assurance Administrator (part of the Intel® Datacenter Software family), participation in the Open Attestation project, and contributions to OpenStack* projects such as Nova.
Our cloud initiatives are based on OpenStack, whose flexible nature can make rapid iteration challenging. However, we have found that rapid iteration instead of lengthy planning and implementation cycles can provide the best business benefits through agility and innovation.
Mirantis
With years of experience spanning multiple, large-enterprise OpenStack projects and numerous contributions to the OpenStack code base, Mirantis is a recognized leader in the OpenStack ecosystem. Mirantis OpenStack—a close-to-trunk OpenStack distribution featuring one-click deployment with Fuel*—solved important parts of the deployment puzzle for Intel and shortened the project timeline.
Developed by Mirantis, Fuel is an open source, template-driven deployment engine. Fuel discovers hardware resources and rapidly and automatically creates robust OpenStack deployments based on tested reference architectures, drawn from real-world use cases.
IBM SoftLayer
Founded in 2005 and acquired by IBM in 2013, SoftLayer provides cloud infrastructure as a service from a growing number of data centers and network points of presence around the world. Products and services include bare metal and virtual servers, networking, turnkey big data solutions, and private cloud solutions.
SoftLayer’s Network-Within-a-Network topology provides true out-of-band access, enabling enterprises to deploy infrastructure off-premises but
completely within the enterprise’s security profile. Other aspects of SoftLayer include an easy-to-use customer portal and robust API for full remote access of all product and service management options.
Private
Cloud Public
Cloud
Cloud Enterprise Challenges:
• Trust
• Performance
• Reliability
• Portability
DAR BBR
To IBM SoftLayer Network PoP
Users Transit Peering
SLR FCR
Load Balancer (optional)
VPN
BCR
Servers Firewalls (optional)
MBR
Block Storage File
Storage Object Storage OS
Update API
Servers DNS Transcoding Images
Network
PoP
SoftLayer Data Center
PUBLIC
PRIVATE
BBR – backbone/border router; DAR – Data center aggregation router; FCR – front-end customer router; MBR – Master back-end router; PoP – Point of Presence; SLR – SoftLayer router Public
Private Management
Figure 2. In the IBM SoftLayer environment, network traffic routes from users to the SoftLayer data center, which features a network of networks. Public, private, and management traffic is segregated and secured.
Methodology
We followed these steps to build our proof-of-concept hybrid cloud:
1. Deploy OpenStack on private and public cloud infrastructures. In both cases we used server hardware equipped to support Intel TXT for infrastructure integrity.
2. Link public and private clouds across a VPN, under a single cloud control plane (OpenStack) hosted on the internal cluster. Internal hosting of the control plane prevented us from having to reconfigure the deployment if the public cloud became unavailable or was disabled to reduce capacity.
3. Deploy and configure operating system support for Intel TXT to obtain trusted compute and storage nodes on public and private clouds.
4. Configure the OpenStack management plane (Nova Scheduler) so that it is aware of the host trust measurement.
5. Install and configure the attestation service using the Open Attestation SDK for Intel TXT on the internal cluster.2 6. Define OpenStack “flavors” of workloads
that require trust validation.
7. Execute tests to validate full functionality of public and private clusters trusted by Intel TXT.
For the public cloud, the team selected SoftLayer, whose hardware base uses Intel TXT. SoftLayer was willing to collaborate to make changes to cluster networking to accommodate the recommended networking plan for scalability, security, and convenience.
Figure 2 shows the SoftLayer environment, including the traffic routing from users to the SoftLayer data center and server communication within the data center. SoftLayer’s network architecture consists of separate interfaces for public, private, and management networks—a unique approach in the industry. This network of networks delivers a high level of scalability and control, segregating and securing traffic while streamlining management. In addition, SoftLayer’s global network features more than 2,000 Gbps of connectivity between data centers and network points of presence (PoPs). Each location has multiple 10-Gbps transit connections as well as peering links to additional service providers and access networks.
Networking Plan
Requirements
• Four networks for administration and deployment
• OpenStack* management shared between internal and external clusters through a VPN
• Local virtual machine connectivity
• Storage
• Public network access
4
Deployment
The team first deployed the Mirantis OpenStack distribution on the private cloud, using the open source Fuel*
deployment tool for OpenStack (see the Meet the Team sidebar for more information on Fuel). Fuel automated the deployment and validated the initial internal cluster.
Next, the team set up the public cloud cluster using the same distribution and release process that was used for the private cloud, working with SoftLayer to configure the remotely hosted equipment.
Enabling this process required SoftLayer to create a network that allowed preboot execution environment (PXE) network communication. Post-deployment, Mirantis configured system-wide networking to use GRE (generic routing encapsulation) tunnels in place of the more common VLANs. Using GRE tunnels enabled both clusters to grow more gracefully, accommodating more tenants or VMs.
Once installed and configured, the two clouds appeared as regions in the Horizon dashboard (located on the private cluster), so that they could be uniformly administered from the same management platform. We assumed that the public cloud implementation provided cost-effective (lower service-
level agreement) burst capacity that could be relinquished, or even absorb failure, without affecting the usability of the private cluster.
Whole-Stack Security For Multitenant Clouds
The team used Intel TXT as a resource- efficient way to make a heterogeneous, multitenant cloud more secure. A critical complement to Intel TXT is an attestation server, which during the boot process anchors and revalidates the trusted state of the BIOS, host operating system, and hypervisor against a predetermined known-good configuration. This procedure lets automated network facilities and human operators know when the trust state of an underlying server infrastructure has changed (perhaps because of a tenant workload’s rogue behavior). Once notified, the affected nodes are isolated and, if possible, restarted in an attempt to reestablish trust.
Meanwhile, Intel TXT provides information to prevent the deployment of sensitive workloads on untrusted hosts through integration with the OpenStack Nova Scheduler service. This service determines the placement of VMs based on a set of criteria, called filters, combined with weighting factors (see Figure 3).3
Intel® Trusted Execution
Technology
Intel® Trusted Execution Technology (Intel® TXT) is an extension to the Intel® Xeon®
processor and is designed to harden platforms against attacks to the hypervisor and BIOS, malicious rootkit installations, and other firmware and software attacks. Intel TXT establishes a root of trust, a hardware-based security foundation that is used to verify the integrity of other system components, such as the hypervisor.
Intel TXT helps protect virtualized server environments through isolation and attestation. As shown below, at startup, Intel TXT measures the hash value of the hypervisor and compares it with a known good value. If the measurements do not match, indicating that the hypervisor may have been compromised, Intel TXT alerts IT to the situation.
IT staff can then define policies to respond to these alerts, such as blocking the launch. This enables the cloud service provider—or the private cloud—to establish pools of compute resources with proven integrity of server infrastructure on which tenant virtual machines run.
HARDWARE
HARDWARE WITH Intel® TXT
HARDWARE HYPERVISOR
HARDWARE HYPERVISOR
HARDWARE HYPERVISOROS OS APPS APPS
1
2
System powers on and Intel® TXT verifies system BIOS/firmware
IT staff blocks or allows launch, depending on whether a match exists
No Match Match
Figure 3. The OpenStack* Nova Scheduler service uses a set of criteria, called filters, combined with weighting factors to help place virtual machines on the appropriate host.
HOST 1 HOST 2 HOST 3 HOST 4 HOST 5 HOST 6
Hosts
sorted by number
HOST 1
HOST 3
HOST 5 HOST 6
Available Hosts
after filtering
HOST 5 HOST 3 HOST 1 HOST 6
Host Priority
after filtering and weighting factors applied HOST 2
HOST 4
The team configured Intel TXT to provide two trusted compute pools:
one in the private cluster, the other in the public cluster. The Nova-compute service determined through the use of filters whether an available host had a trust measurement and that the attestation server had matched that trust measurement to a preestablished “good”
MLE. The system allowed deployment of sensitive workloads only on trusted hosts and notified administrators about changes that might compromise trust or make it indeterminate.
The virtualization stack uses Intel®
Virtualization Technology (Intel® VT)4 for hardware-supported virtualization and involves the following primary software applications:
• Kernel-based Virtual Machine (KVM).
A hypervisor that allows an application to take advantage of Intel VT.
• QEMU (Quick EMUlator). A generic and open source machine emulator and virtualizer. QEMU can make use of KVM when running a target architecture that is the same as the host architecture.
• Libvirt. A virtualization API that interacts with the virtualization capabilities of the operating system.
1 No computer system can provide absolute security under all conditions. Intel® Trusted Execution Technology (Intel® TXT) requires a computer with Intel®
Virtualization Technology, an Intel TXT-enabled processor, chipset, BIOS, Authenticated Code Modules and an Intel TXT-compatible measured launched environment (MLE). Intel TXT also requires the system to contain a TPM v1.s. For more information, visit www.intel.com/technology/security.
2 This proof of concept used Intel’s derivative of the Open Attestation SDK, code-named Mt. Wilson.
3 The Open Attestation SDK is available at www.github.com/OpenAttestation.
4 Intel® Virtualization Technology requires a computer system with an enabled Intel® processor, BIOS, and virtual machine monitor (VMM). Functionality, performance or other benefits will vary depending on hardware and software configurations. Software applications may not be compatible with all operating systems. Consult your PC manufacturer. For more information, visit www.intel.com/go/virtualization.
THE INFORMATION PROVIDED IN THIS PAPER IS INTENDED TO BE GENERAL IN NATURE AND IS NOT SPECIFIC GUIDANCE. RECOMMENDATIONS (INCLUDING POTENTIAL COST SAVINGS) ARE BASED UPON INTEL’S EXPERIENCE AND ARE ESTIMATES ONLY. INTEL DOES NOT GUARANTEE OR WARRANT OTHERS WILL OBTAIN SIMILAR RESULTS.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS AND SERVICES. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR
OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL’S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS AND SERVICES INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
Intel, the Intel logo, Look Inside., the Look Inside. logo, and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others.
Copyright 2014 Intel Corporation. All rights reserved. Printed in USA Please Recycle 0914/GSEA/KC/PDF
Conclusion
This collaborative proof of concept is an important step on the road to full- featured hybrid cloud computing. It validates important aspects of Intel’s vision for the future of OpenStack and cloud computing. The results highlight OpenStack capabilities in linked private and public cluster configurations and illustrate how rapid, multi-platform deployment efficiencies delivered by Mirantis OpenStack and Fuel on Intel®
architecture-based hardware offered by SoftLayer can shorten time-to-benefit.
For more information on Mirantis, visit www.mirantis.com
For more information on IBM SoftLayer, visit www.softlayer.com
For more information on
Intel’s cloud computing initiatives, visit www.intel.com/Cloud
Solution Provided By:
Results
The proof of concept validated several aspects of improving security in a hybrid cloud environment, including the following:
• Visibility into the trust level of different VMs or workloads
• A way to tag and differentiate which workloads required additional security
• The ability to use common credentials and authentication and authorization across both public and private clouds The combination of trust measurement and the security specifications on the workloads made it much simpler to determine which workloads could run and where they should not run. The entire process could be automated, with no manual intervention to place the workloads, because placement of workloads was handled in the background by the OpenStack Nova Scheduler service with the help of the trust filter.
