• No results found

2 The Cloud Infrastructure Model

2.2 OpenStack Architectural Overview

OpenStack is a collection of independent components that intercommunicate through public APIs and collectively form a robust cloud computing platform. The logical archi-tecture of OpenStack is illustrated in Figure 2.8. Below, we review the main components of the OpenStack infrastructure cloud model; similar components are present in most cloud infrastructure platforms and deployments.

Compute Service

Compute is a core component responsible for provisioning and management of compute hosts. Compute service instances run on the hosts in a cloud deployment to support vir-tualization management tasks. Hardware virvir-tualization [73] allows to multiplex physical compute hosts among virtual machines or unikernels. Configuration of compute hosts can have far-reaching security implications. For example, a high instance per server density (over-commit) is beneficial from a resource utilization perspective when guests do not perform CPU or network-intensive tasks [74]. However, a higher over-commit ratio leads to increased interference from collocated virtual machines [74] and higher potential for side-channel information leakage [20, 75].

The choice of CPU architecture and vendor, along with server OEM determines the availability of - and support for - hardware-enabled security features. Security fea-tures such as AMD Secure Encrypted Virtualization [76, 77], TrustZone [78, 79], Intel SGX [50, 51] or SecureBlue++ [80] can protect computation and data both directly on the physical hosts and in virtualized environments deployed on such hosts [81]. However, such features differ wildly in their security models, firmware support and functionality.

Block Storage

Volume Manager

Block Storage Database

Block Storage Scheduler Registry

Object Store

Account Container Object

Token Backend

Catalog Backend

Policy Backend

object store block storage

storage

Network Database Network

Provider Network Agents

Network Plugins Network

Queue

network infrastructure

Network Controller

Compute Service

Compute Daemon

Compute Database Hypervisor

Compute

Scheduler compute

compute queue

Image Registry Image Service

Database

image store

Service and Admin API

Token Backend

Catalog Backend

Identity Backend

Identity service

Image Service Image API

Networking API

Compute/

Admin API

Block Storage API Object Store API

Deployment Administration

Interface

Figure 2.8: OpenStack Logical Architecture.

OpenStack compute component (Nova) was used in the prototype implementations described in Papers A, B included in this thesis.

Storage

Storage is essential for both infrastructure management and resource provisioning in enterprise deployments. From an IaaS management perspective, storage capacity is necessary for maintaining databases of tenant accounts, network topology information, authentication credentials, tokens and policies, along with multiple other critical data, i.e. management data. From a resource provisioning perspective, storage capacity is required for VM operating system execution along with additional file systems for storing VM images, as well as any further persistent storage for VM instances, i.e.

tenant data.

In terms of confidentiality, integrity and availability, the security concerns and require-ments towards tenant data and management data differ depending on the threat model.

In this context we distinguish between two data persistence categories:

• Ephemeral storage does not persist over virtual machine instantiation cycles. For example, such storage can be allocated to virtual machine instances used for data processing tasks that do not produce data that must be persisted. From a tenant point of view, data on ephemeral storage disappears when a virtual machine is terminated. Beyond RAM, this includes ephemeral disks [82] - virtual disks that can be mounted to and used by a virtual machine during its operation but are destroyed once the instance is terminated.

• Persistent storage outlives any other resource and is available regardless of the state of the virtual machine instance. Infrastructure providers use persistent stor-age to store infrastructure manstor-agement data.

Figure 2.8 illustrates two types of storage in enterprise deployments, namely block storage and object storage, further discussed below.

Block Storage Tenants use block storage to add storage to a virtual machine and maintain access to it even after the instance has been terminated. Tenants use the block storage API to create and operate persistent block storage volumes on servers.

Block storage is accessed through a block device that can be partitioned, formatted, and mounted. Such storage is appropriate for performance-sensitive scenarios - such as database storage, expandable file systems, access to raw block-level storage, etc.

Block storage volumes are located either off compute host storage - on a shared file system; on compute host storage - on a shared file system; or on compute host storage - in a dedicated file system. As illustrated in Figure 2.8, the high-level structure of a block storage component in an enterprise deployment is as follows: based on requests received through the block storage API, a volume manager operates storage partitions enumerated in a block storage database and described by meta-data information in a registry. The physical location of volumes is determined by the block storage scheduler based on deployment architecture and relevant policies. Examples of block storage back-ends include Ceph [83] and GlusterFS [84].

OpenStack block storage (Cinder) was used in the prototype implementations de-scribed in Papers B, C included in this thesis.

Object Storage Tenants use object storage to store, expose and manage data as ob-jects instead of files or blocks. Stored obob-jects contain a variable amount of meta-data, to facilitate indexing and data management in large-scale data stores. The design of object stores prioritizes horizontal scalability across multiple hosts (in the order of hundreds or thousands) and high availability; it is often tuned towards read-intensive data access patterns. Object stores support larger namespaces and eliminate name collisions by en-abling addressing and identification of individual objects by unique identifiers within a

bucket, or across the entire system. External entities access data stored in object stores through an API - such as the REpresenational State Transfer (REST) - that is limited to storage and retrieval of files and that does not support mounting directories (such as in the case of a file server). Figure 2.8 includes a high-level logical structure of an object store, which stores object data from multiple accounts in replicated containers located across a set of hosts in the deployment. Examples of object stores include Dynamo [85], PNUTS [86], Haystack [87], Azure (Blob storage) [88] and Ambry [89].

OpenStack object storage component (Swift) was used in the prototype implement-ation described in Paper D included in this thesis.

Image Service

In order to reduce data transfer and VM isntance launch time, enterprise deployments often maintain a set of virtual machine images offered to tenants for instantiation.

The image service is a repository that stores and versions VM images available to tenants. Integrity of the VM images made available through the repository is critical for protecting tenant data and computation. Furthermore, images provided through the repository must be patched and maintained up to date [90].

Identity service

The identity service maintains and provides tenant account and identity information.

This service communicates with all user-facing components of the deployment for au-thentication and authorization purposes. Security of the identity service is essential for preventing impersonation and privilege escalation attacks in cloud deployments [17].

Network infrastructure

Large-scale enterprise deployments implement a wide range of network topologies and architecture models. SDN is a popular architectural model in cloud deployments. Along with flat networks with Virtual Local Area Networks (VLANs) for tenant isolation, net-work control can take advantage of the SDN model and create massively scalable multi-tenant virtualized networks. The extension framework (network plugins in Figure 2.8) allows to deploy and manage software implementations of additional network services, such as load balancing, firewalls and virtual private networks. Figure 2.9 illustrates the types of networks present in cloud deployments:

• The install or out-of-band network enables deploying software images to compute hosts.

• The internal or management network enables communication between compute, storage and management hosts.

Configuration Server Controller Storage

Storage network Out of band network Tenant network Public network Management network Compute Host 3

Compute Host 2 Compute Host 1

Figure 2.9: Types of networks typically present in a cloud infrastructure deployment.

• The tenant network enables communication among instances.

• The storage network enables communication between compute hosts and storage back-ends.

• The public network enables instance access to the public network space; public network addresses are handled by a deployment-specific network agent on network controller nodes.

Network isolation is important to prevent interference from other networks in case of data-intensive transfers. Section 3.3 presents further aspects of SDN, along with security considerations for network connectivity in infrastructure cloud deployments.

Management Components

Depending on the use case and usage model of the infrastructure cloud deployment, additional common but deployment-specific components may be present. Such com-ponents include the log aggregation subsystem, telemetry comcom-ponents collecting usage data for billing purposes, or a dashboard displaying deployment status information.