Coordination of Cooperative Cloud Computing Platforms

Mathieu Lavallée Michel Mayrand Elisa Shahbazian

Prepared by: OODA Technologies Inc. 4580 Circle Rd Montréal, QC H3W 1Y7

PWGSC Contract Number: W7707-145677/001/HAL Technical Authority: Anthony W. Isenor Contractor’s Publication Date: April 2017

The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of the Department of National Defence of Canada.

Contract Report DRDC-RDDC-2017-C118 May 2017

Template in use: (2010) SR Advanced Template_EN (051115).dotm

© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2017 © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2017

Coordination of Cooperative Cloud Computing Platforms

B316<=:=573A

Mathieu Lavall´ee Michel Mayrand Elisa Shahbazian

Prepared By: OODA Technologies Inc. 4580 Circle Rd Montr´eal(Qc), H3W 1Y7 514.476.4773

Prepared For: Defence Research & Development Canada, Atlantic Research Centre 9 Grove Street, PO Box 1012 Dartmouth, NS B2Y 3Z7 902-426-3100

Scientiﬁc Authority: Anthony W. Isenor Contract Number: W7707-145677/001/HAL Call Up Number: 17 Project: Design, develop, manage, test and/or implement speciﬁc software or data source modules Report Delivery Date: April 7, 2017

The scientiﬁc or technical validity of this Contract Report is entirely the responsibility of the contractor and the contents do not necessarily have the approval or endorsement of Defence R&D Canada. This page is intentionally left blank. Executive Summary

Cloud computing has infiltrated multiple aspects of technology solutions for industry as well as everyday life. It provides many benefits: fault tolerance to hardware failure, automatic update and backup, scalability, flexibility, accessibility, facilitation of collaboration, and many more. The cloud provides the resources to process real-time commercial/financial transactions, social network analysis, data mining and all kinds of algorithms which benefit from a large farm of processors or need to process a large quantity of data or both. The tools for managing/monitoring a cloud have evolved to a point that it is now possible for an individual to build his or her own cloud at home, thanks to state-of-the-art open-source software. Now, the new trend is to understand how to coordinate resources across multiple homogeneous or heterogeneous clouds and to create the standards and the tools to achieve intercloud communication. In the context of a maritime operation regrouping a fleet where each ship has its own private cloud, the utility of intercloud communication becomes obvious: automatic database exchange or merge, remote hardware resource sharing, redundancy, remote service providers, identity authentication, etc.

The first part of this report addresses literature and tools review on cloud environments, their frameworks and the standards used to connect them for exchanging resources. The second part of this report describes the installation of two clouds using OpenStack framework and the configuration necessary to allow intercloud communication. The next step is the investigation on how to use intercloud capability for exchanging information between two clouds. In that context, we describe what are the possibilities for intercloud communication in the context of an OpenStack federation at different levels: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). The main goal of this study is to assess the existing capabilities of the state-of-the-art cloud environments for at-sea interoperability assuming none of the constraints and limitations that at-sea environments may impose. A short description of such constraints and limitations is included at the end of this report.

i OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Contents

Executive Summary i

Contents iii

List of Figures vii

List of Tables ix

List of Acronyms xi

1 Introduction 1

1.1 Background ...... 1

1.2 Document Overview ...... 2

2 Literature Review 3

2.1 Research Methodology ...... 3

2.1.1 Keywords ...... 4

2.1.2 Glossary ...... 6

2.2 Standards ...... 10

2.2.1 Standard Inventory ...... 10

2.2.2 Relevant Standards ...... 10

2.2.2.1 Cloud Data Management Interface (CDMI) ...... 10

2.2.2.2 Open Cloud Computing Interface (OCCI) ...... 10

2.3 Cloud environments ...... 12

iii Final Report for RISOMIA Call-up 17

2.3.1 Cloud levels of services ...... 12

2.3.2 Cloud software review ...... 14

2.4 Tool recommendation ...... 15

2.5 Other recommended books and articles ...... 16

2.5.1 Books ...... 16

2.5.2 Articles ...... 16

3 Multicloud Existing Applications 19

3.1 Success Stories ...... 19

3.1.1 The Interop challenge ...... 19

3.1.2 European Grid Infrastructure (EGI) ...... 19

3.1.3 NeCTAR ...... 20

3.2 On-going experiences and projects ...... 20

3.2.1 Project Tricircle ...... 20

3.2.2 Project Trio2o ...... 21

3.2.3 Inter Cloud Resource Federation ...... 22

4 OpenStack Components and Federation Architecture 25

4.1 Components roles ...... 25

4.2 OpenStack Federation ...... 28

4.2.1 Deﬁnition ...... 28

4.2.2 Architecture ...... 29

4.3 Federation architecture and mechanisms ...... 29

4.3.1 Discovery ...... 30

4.3.2 Management and monitoring ...... 30

5 Installation Guide 31

5.1 Centos installation ...... 32

5.1.1 Installation ...... 32

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. CONTENTS

5.2 OpenStack installation ...... 33

5.2.1 Architecture ...... 34

5.2.2 Installation ...... 34

5.2.2.1 Every computer node ...... 34

5.2.2.2 On the controller node ...... 36

5.3 Federation conﬁguration ...... 37

5.3.1 Architecture ...... 38

5.3.2 Conﬁguration Identity Provider (IdP) ...... 38

5.3.3 Conﬁguration Service Provider (SP) ...... 40

6 Applications of Communication Between Federated OpenStack Cloud 43

6.1 Federated OpenStack Features ...... 43

6.2 IaaS application examples ...... 43

6.2.1 Workload transfer ...... 44

6.3 PaaS application examples ...... 44

6.3.1 Database synchronization ...... 44

6.3.2 Application provisioning ...... 44

6.4 SaaS application examples ...... 45

6.4.1 Exchange of services ...... 45

7 At-sea Environment Limitation 47

8 Conclusion and Future Work 51

Bibliography 53

Appendix A Installation Internet references A-1

A.1 OpenStack ...... A-1

A.2 OpenStack Federation ...... A-1

A.3 Shibboleth ...... A-2

v OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

A.4 Keystone ...... A-2

A.5 Wiki and Blogs ...... A-2

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. LIST OF FIGURES

List of Figures

2.1 OCCI Architecture ...... 12

2.2 Types of cloud services ...... 13

3.1 Tricircle Architecture ...... 21

3.2 Trio2o Architecture ...... 22

3.3 Inter Cloud Resource Federation Architecture ...... 23

4.1 OpenStack component architecture ...... 25

4.2 OpenStack component interaction ...... 27

4.3 Single sign-on using SAML in a Web browser ...... 29

5.1 Cloud federation proposed architecture ...... 34

5.2 Identity Provider Conﬁguration ...... 38

5.3 Service Provider Conﬁguration ...... 40

7.1 DoD Enterprise Cloud Environment. Source: [15] ...... 48

vii OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

viii

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. LIST OF TABLES

List of Tables

2.1 Primary search Keywords...... 4

2.2 Secondary Search Keywords ...... 5

2.3 Glossary of cloud related deﬁnitions...... 6

2.4 Cloud standard list by Cloud Standards Customer Council (CSCC) ...... 11

2.5 Available cloud software ...... 14

2.5 Available cloud software ...... 15

5.1 Conﬁguration modiﬁcation for each cloud controller ...... 42

ix OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. List of Acronyms

List of Acronyms

API Application Programming Interface AWS Amazon Web Service CDMI Cloud Data Management Interface CSCC Cloud Standards Customer Council DaaS Data Storage as a Service DMTF Distributed Management Task Force DNS Domain Name System EGI European Grid Infrastructure HTTP Hypertext Transfer Protocol IaaS Infrastructure as a Service IdP Identity Provider

NIST National Institute of Standards and Technology OASIS Organization for the Advancement of Structured Information Standards OCCI Open Cloud Computing Interface OGF Open Grid Forum PaaS Platform as a Service REST Representational State Transfer RHEL RedHat Enterprise Linux SaaS Software as a Service SNIA Storage Networking Industry Association SP Service Provider SSO Single Sign On

xi OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

xii

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 1

Introduction

1.1 Background

Many questions arise naturally:

• What is the state of these cloud framework environments?

• Have they achieved a certain level of maturity? Are they stable?

• Are they easy to use?

• What can we do with it? And cannot be done?

• Are they secured?

This study will try to provide some answers to these questions.

The ﬁrst part of this report reﬂects on the literature and tools review on cloud environments, their frameworks and the standards used to inter-connect them enabling exchanging resources. The

1 Final Report for RISOMIA Call-up 17 second part of this report describes the installation of two clouds using OpenStack framework and the conﬁguration necessary to allow intercloud communication. The next step is the investigation on how to use intercloud capability for exchanging information between two clouds. In that context, we describe what are the possibilities for intercloud communication in the context of an OpenStack federation at diﬀerent levels: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). The main goal of this study is to assess the existing capabilities of the state-of-the-art cloud environments for at-sea interoperability assuming none of the constraints and limitations that at-sea environments may impose. A short description of such constraints and limitations is included at the end of this report.

1.2 Document Overview

This document is organized as follows:

• Section 2 presents a literature review of cloud technology which includes a description of cloud standards developed by the open-source community and the industry’s main contributors.

• Section 3 enumerates previous success stories of multicloud deployment as well as on-going projects related to cloud federation.

• Section 4 presents the core components of the OpenStack architecture and their role in a multicloud environment.

• Section 6 presents what is possible to do in a federated multicloud environment.

• Section 7 presents possible limitations of cloud computing in an at-sea environment and what needs to be done to overcome them.

• Section 8 presents the lessons learned, possible future work and concluding remarks.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2

Literature Review

2.1 Research Methodology

Very early in the literature review, we made these observations:

1. Cloud usage has been spreading to many aspects of our society and there is no sign that it will slow down.

2. Cloud development is now accessible not only to large corporations but also to individuals.

3. Cloud technology is evolving extremely fast.

Consequently, it becomes clear that reviewing out-of-date information on cloud technologies would be a waste of energy. For these reasons, we focused only on the very recent tools developed for cloud deployment and standards.

What is happening in cloud software development and why is it going so fast? Many contributors are working in parallel, with each team implementing and testing new code, to obtain the certi- ﬁcation to merge their features. It leads to frequent releases. For example, in a previous report [1], more than half of an open-source cloud framework (Openshift) was redesigned within the time frame of the analysis of the tool. We observe a similar situation in the evolution of the virtualization software Docker which is widely used in cloud environments and where each release introduces major features and is rarely backward compatible. Sadly, a side eﬀect of this fast-track development is poor documentation, not in the sense of low quantity (see https://docs.openstack.org/) but in the sense of its usefulness (multiple out-of-date versions, contradictory or unclear instructions, lack of examples, etc.). The software evolves faster than it takes to write or update the documentation. Contributors probably do not invest much time in good quality documentation because:

1. these tools are intended for only a relatively small number of network administrators who can ﬁgure out by themselves how to use them and how to debug them;

2. they are open-source in the sense that it may not be always suﬃciently founded;

3 Final Report for RISOMIA Call-up 17

3. the focus is put on adding new features and fast growth instead of productization and proper documentation;

4. and ﬁnally, a very hungry cloud-driven society in the making.

There is less value in documenting and studying a deprecated software. This is why we focus this research on the very recent developments. The early developments of the cloud, while interesting, would have little impact on the outcome of this investigation.

2.1.1 Keywords

The tool survey was mainly driven by searching the web but also based on our past experience with similar technologies (Openshift, see [1]). Tables 2.1 and 2.2 provide the list of keywords used to query the Google search engine.

Table 2.1: Primary search Keywords.

Keywords Notes

Cloud interoperability Often deﬁnes standard action of interfacing that can be reused across multiple cloud implementations.

Intercloud Deﬁnes interaction between multiple clouds. Used in standard documentation.

Multicloud Yet another word for interaction between clouds, not used very often.

Cloud federation A communication between clouds with a mutually trusted authentication and authorization mechanism. Usually implies a homogeneous multicloud environment

Hybrid cloud Used to deﬁne a public-private cloud interaction. Usually implies a heterogeneous multicloud environment

k2k Keystone to keystone – Used to describe a cloud federation which uses Keystone as an authentication mechanism.

TripleO OpenStack On OpenStack – A project to deploy a production cloud over a provisioning cloud.

SSO Single Sign On

OpenStack Open-source IaaS framework

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2. Literature Review

Table 2.1: Primary search Keywords.

RDO RDO is a community of people using and deploying OpenStack on CentOS, Fedora, and Red Hat Enterprise Linux. A community sup- ported distribution of OpenStack based on the upstream source code for Redhat Linux family.

Public cloud Company that provides cloud services (IaaS, PaaS, SaaS) to the public usually for a fee.

Private cloud Cloud infrastructure where the providers, developers and users are all under the same company or organization.

From the ﬁrst set of articles found with the above keywords, we discovered another set of technical keywords related to cloud technology that was useful in reﬁning our research queries:

Table 2.2: Secondary Search Keywords

Keywords Notes

CDMI Cloud Data Management Interface

CSCC Cloud Standards Customer Council

Devstack Development group for OpenStack

Packstack Semi-automated installation tool for OpenStack using Puppet.

SAML Security Assertion Markup Language

IDP Identity Provider

SP Service Provider

Horizon OpenStack Dashboard

Keystone OpenStack identity service

Shibboleth Implementation of SAML2

Cloud bursting Mechanism by which a task is moved from one cloud to another (usually from a private to a public cloud) for load-balancing purpose.

Tricircle Provide networking automation across the module Neutron in multiple OpenStack deployments.

5 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

2.1.2 Glossary

A glossary made from the deﬁnitions found on the web is presented to provide a better understanding of the following sections of this study.

For a longer and more complete cloud related glossary, see reference [13].

Table 2.3: Glossary of cloud related deﬁnitions.

Item Deﬁnition

OpenStack “OpenStack is a free and open-source software platform for cloud computing, mostly deployed as an infrastructure-as- a-service (IaaS)1.”

DevStack “DevStack is a series of extensible scripts used to quickly bring up a complete OpenStack environment based on the latest versions of everything from git master. It is used interactively as a development environment and as the basis for much of the OpenStack project’s functional testing2.”

PackStack “PackStack is a command line utility that uses Puppet3 modules to support rapid deployment of OpenStack on existing servers over an SSH connection. PackStack is suitable for deploying both single node proof of concept installations and more complex multi-node installations. Deployment options are provided either interactively, via the command line, or via a text ﬁle containing preconﬁgured answers to the questions PackStack asks4.”

Puppet “Puppet provides a standard way of delivering and operating software, no matter where it runs. With the Puppet approach, you deﬁne what you want your apps and infrastructure to look like using a common easy-to-read language. From there you can share, test and enforce the changes you want to make across your data centre. And at every step of the way, you have the visibility and reporting you need to make decisions and prove compliance. The result: you get a standard way of automating all of it, at scale5.”

1 https://en.wikipedia.org/wiki/OpenStack 2 https://docs.openstack.org/developer/devstack 3 http://www.puppetlabs.com/ 4 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/ html/Getting_Started_Guide/part-Deploying_OS_using_PackStack.html 5 https://puppet.com/product/how-puppet-works

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2. Literature Review

Table 2.3: Glossary of cloud related deﬁnitions.

Horizon (Open- “Horizon is the canonical implementation of Openstack’s Stack) Dashboard, which provides a web-based user interface to OpenStack services including Nova, Swift, Keystone, etc6.”

“Horizon ships with three central dashboards, a User Dash- board, a System Dashboard, and a Settings dashboard. Be- tween these three they cover the core OpenStack applications and deliver on Core Support. The Horizon application also ships with a set of API abstractions for the core Open- Stack projects in order to provide a consistent, stable set of reusable methods for developers. Using these abstractions, developers working on Horizon don’t need to be intimately familiar with the APIs of each OpenStack project7.”

Federation (Open- “In a standard OpenStack setup, users authenticate against Stack) the identity APIs, usually implemented by the Keystone service. With federated Keystone, the options for authentication are greatly increased since it outsources that responsibility to an external Identity Provider (IdP). The Service Provider Keystone (SP) can instead just focus on managing access to resources on the cloud where it resides. As a result, a speciﬁc group of users in a trusted IdP service can access the cloud services without needing explicit accounts on the SP8.”

Security Assertion “SAML is an Extensible Markup Language (XML) -based, Markup Language open-standard data format for exchanging authentication (SAML) and authorization data between parties, in particular, between an identity provider and a service provider9.”

6 https://wiki.openstack.org/wiki/Horizon 7 https://docs.openstack.org/developer/horizon/intro.html 8 https://platform9.com/blog/openstack-keystone-federation/ 9 https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

7 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

Table 2.3: Glossary of cloud related deﬁnitions.

Keystone (Open- “Keystone is an OpenStack identity service that manages Stack) user databases and OpenStack service catalogs and their API endpoints. It integrates with existing backend directory services like LDAP and supports multiple authentication mechanisms, such as username-and-password, token- based systems and AWS-style logins10.” “It currently supports token-based authN and user-service authorization. It has recently been rearchitected to allow for expansion to support proxying external services and AuthN/AuthZ mechanisms such as oAuth, SAML and openID in future versions11.”

Single Sign On “Single sign-on (SSO) is a session and user authentication (SSO) service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. The service authenticates the end user for all the applications the user has been given rights to and eliminates fur- ther prompts when the user switches applications during the same session. On the back end, SSO is helpful for log- ging user activities as well as monitoring user accounts12.”

Shibboleth “Shibboleth is an open-source project that provides Sin- gle Sign-On capabilities and allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner13.”

“The Shibboleth Internet2 middleware initiative created an architecture and open-source implementation for identity management and federated identity-based authentication and authorization (or access control) infrastructure based on Security Assertion Markup Language (SAML). Feder- ated identity allows the sharing of information about users from one security domain to the other organizations in a federation. This allows for cross-domain single sign-on and removes the need for content providers to maintain user names and passwords. Identity providers (IdPs) supply user information, while service providers (SPs) consume this information and give access to secure content14.”

10 http://blog.flux7.com/blogs/openstack/tutorial-what-is-keystone-and-how-to-install-keystone-in-openstack 11 https://wiki.openstack.org/wiki/Keystone 12 http://searchsecurity.techtarget.com/definition/single-sign-on 13 http://www.puppetlabs.com/ 14 https://en.wikipedia.org/wiki/Shibboleth_(Internet2)

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2. Literature Review

Table 2.3: Glossary of cloud related deﬁnitions.

token “A software token ... is a type of two-factor authentication security device that may be used to authorize the use of computer services. Software tokens are stored on a general- purpose electronic device such as a desktop computer, lap- top, PDA, or mobile phone and can be duplicated15.”

Identity Provider “The Identity Provider provides Single Sign-On services (IDP) and extends reach into other organizations and new services through authentication of users and securely provid- ing appropriate data to requesting services. In addition to a simple yes/no response to an authentication request, the Identity Provider can provide a rich set of user-related data to the Service Provider. This data can help the service provide a more personalized user experience, save the user from having to manually enter data the service requires, and re- fresh the data each time the user logs onto the service16. ”

Service Provider “A cloud provider is a company that oﬀers some compo- (SP) nent of cloud computing – typically Infrastructure as a Service (IaaS), Software as a Service (SaaS) or Platform as a Service (PaaS) – to other businesses or individuals. Cloud providers are sometimes referred to as cloud service providers or CSPs17.”

Web Server Gate- “The Web Server Gateway Interface (WSGI) is a speciﬁca- way Interface tion for simple and universal interface between web servers (WSGI) and web applications or frameworks for the Python programming language18.”

“It is just an interface speciﬁcation by which server and application communicate. Both server and application interface sides are speciﬁed in the Python Enhancement Pro- posals (PEP) 3333 which is the Python Web Server Gate- way Interface. If an application (or framework or toolkit) is written to the WSGI spec then it will run on any server written to that spec19.”

15 https://en.wikipedia.org/wiki/Software_token 16 https://shibboleth.net/products/identity-provider.html 17 http://searchcloudprovider.techtarget.com/definition/cloud-provider 18 https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface 19 http://wsgi.tutorial.codepoint.net/

9 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

2.2 Standards

There are many organizations involved in the cloud ecosystem. These organizations gather together to deﬁne standards. This section enumerates and describes existing standards relevant to cloud interoperability and communications.

2.2.1 Standard Inventory

The cloud computing ecosystem is wide and it offers a broad range of services and applications. The standards define the foundation of a cloud ecosystem by ensuring the compatibility and communication of every component toward each other. The standards are required in order to achieve communication between multiple clouds. The Cloud Standards Customer Council (CSCC) is an organism that helps define best practices, patterns, case studies and standards. The CSCC compiled a list of standards applicable to many components of the cloud and is shown in Table 2.4.

2.2.2 Relevant Standards

Two of the standards described in table 2.4 stand out from the others: the Cloud Data Management Interface (CDMI) and the Open Cloud Computing Interface (OCCI).

2.2.2.1 CDMI

The CDMI is a SNIA standard that specifies a protocol for self-provisioning, administering and accessing cloud storage. This standard defines abstraction of complexity and promotes the simplicity of use as cloud resources. It defines the Data Storage as a Service (DaaS) interface for managing all kinds of data stored in the cloud. The functionalities defined in this standard include the operation and management of data objects, containers, accounts, capabilities, queues and data system metadata through a Representational State Transfer (REST)ful Hypertext Transfer Proto- col (HTTP) Application Programming Interface (API). The CDMI interface is designed to work alongside OpenStack storage interface as of release v1.1 in March 2015.

2.2.2.2 OCCI

The Open Cloud Computing Interface (OCCI) is a set of speciﬁcations delivered through the OGF, for the standard services of cloud computing service development. The OCCI goals are interoperability, portability, integration and extensibility. The interoperability goal is achieved by deﬁning a single interface to interact with every cloud without having to manage multiple

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2. Literature Review

Standard Description Authority

Distributed Man- Open Visualization For- A packaging standard that is designed to address agement Task mat the portability and deployment of virtual machines. Force (DMTF)

Deﬁnes the functional interface that applications Storage Network- Cloud Data Manage- will use to create, retrieve, update and delete data ing Industry As- ment Interface (CDMI) elements from the cloud. sociation (SNIA)

A set of open speciﬁcations that deﬁne a protocol Open Cloud Computing Open Grid Forum and APIs for all kinds of cloud computing manage- Interface (OGF) ment tasks.

Organization for Topology and Orches- Description of applications and infrastructure cloud the Advancement tration Speciﬁcation services, of the relationships between parts of the of Structured for Cloud Applications service, and of the operational behavior of these Information Stan- (TOSCA) services (e.g., deploy, patch, shutdown). dards (OASIS)

Cloud Application Deﬁnes an interoperability protocol that cloud de- Management for Plat- signers can use to package and deploy their appli- OASIS forms (CAMP) cations.

Cloud Auditing Data Deﬁne open standards for cloud auditing. DMTF Federation (CADF)

LDAP, OAuth, OpenID Standards that enable third party ID and Access Many implemen- Connect and SAML Management functionality. tations

A standard that speciﬁes the security requirements National Institute which need to be satisﬁed by a cryptographic mod- of Standards US FIPS 140-2 ule used within a security system protecting sensi- and Technol- tive information. ogy (NIST)

Table 2.4: Cloud standard list by CSCC

11 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17 dependencies on multiple APIs. The objective of portability is to avoid technical lock-in and to enable the client to switch providers with minimal technical costs. The integration involves the deﬁnition of a stable interface in order to support the legacy and the latest infrastructure. Finally, the extensibility goal is achieved by using the meta-model and capabilities discovery feature to be able to interact with any OCCI server using the provider’s extensions. The OCCI client system interaction is illustrated in the Figure 2.1. There is an OpenStack implementation of the OCCI interface that interacts directly with the OpenStack API20.

Figure 2.1: OCCI Architecture. Source: http://occi-wg.org/about.

2.3 Cloud environments

Cloud infrastructure is really complex, there are a lot of terms and keywords that are often abused or misinterpreted. Levels of cloud services (IaaS, PaaS and SaaS) are often confused because some cloud providers oﬀer many levels of services.

2.3.1 Cloud levels of services

The following subsections deﬁne levels of cloud services with clear deﬁnitions of cloud providers and cloud user roles. Furthermore, it explains how each level plays with other levels.

• The IaaS cloud provider owns hardware and network resources. The IaaS is intended for a consumer who is a developer or system administrator. The cloud provider runs software to

20 https://github.com/openstack/ooi

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2. Literature Review

enable consumers to deploy and manage virtual machine. The IaaS provider’s challenge is ensuring constant performance and reliability to the customer. The cloud consumer use the resources to install an operating system and software without bothering with purchasing the hardware or dealing with hardware failures. Popular IaaS public providers are Amazon Web Service (AWS), Microsoft Azure and Rackspace. OpenStack is a solution to run a private IaaS.

• The PaaS cloud provider offers ready-to-run infrastructure for developers. The provider’s role is to ensure standard running instances such as defined python, Tomcat, Docker container runtime, Postgresql instance, MongoDB etc. The PaaS consumers are application developers aiming for a controlled and stable environment to ease testing and deployment of applications. The PaaS provider can offer the hardware infrastructure and the PaaS software as a whole or rely on a third party IaaS to host their PaaS software. Popular PaaS providers are Google Appengine, Heroku, OpenShift. Among the PaaS mentioned, Heroku21 and OpenShift Online host their IaaS software on AWS. OpenShift community is a PaaS platform for PaaS providers.

Figure 2.2: Types of cloud services. Source: http://ots.si/Prejsnje_konference/OTS_2011/ images/files/trust_v3.Gabi.pdf.

• The SaaS cloud provider oﬀers an application (often a web-based application) to the consumer. The consumer of the cloud would be any cloud user. The SaaS provider may run on a PaaS or on a IaaS. The Software provided as a service can be a web application, a web

21 https://devcenter.heroku.com/articles/regions#data-center-locations

13 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

service or may use any protocol. Some of the most popular IaaS are Gmail, DropBox, Google Document, etc. Dropbox used to run on AWS22.

Cloud services offer many levels of abstraction and target different consumers for each level. The link between levels of services and consumer is shown in figure 2.2.

2.3.2 Cloud software review

Table 2.5: Available cloud software. Source: https://en. wikipedia.org/wiki/Cloud_computing_comparison

Software Initial License(s) Written in As a Local release service installation

ﬂuid Op- 2009-03-01 Proprietary Java, No Yes erations / Groovy eCloudManager

AppScale 2009-03-07 Apache License[2] Python, Yes Yes Ruby, Go

Cloud Foundry 2011-04-12 Apache License Ruby, C, Yes Yes Java, Go

Cloud.com 2010-05-04 Apache license Java, C Yes Yes /CloudStack

Eucalyptus 2008-05-29 Proprietary, GPL Java, C Yes Yes v3

Flexiant Lim- 2007-01-15 Proprietary soft- Java, C Yes Yes ited ware

Nimbus 2009-01-09 Apache License Java, Yes Yes Python

OpenNebula 2008-03-?? Apache License C++, C, Yes Yes Ruby, Java, Shell script, lex, yacc

22 https://blogs.dropbox.com/tech/2016/03/magic-pocket-infrastructure/

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2. Literature Review

Table 2.5: Available cloud software. Source: https://en. wikipedia.org/wiki/Cloud_computing_comparison

Software Initial License(s) Written in As a Local release service installation

OpenQRM 2008-03-?? GPL License C++, PHP, Yes Yes Shell script

OpenShift 2011-05-04 Apache License Go Yes Yes

OpenStack 2010-10-21 Apache License Python Yes Yes

OnApp 2010-07-01 Proprietary Java, Ruby, Yes Yes C++

oVirt 2012-08-09 Apache License Java, ? Yes Python

Jelastic 2011-01-27 GPL License, Java, Yes Yes Apache License, JavaScript, BSD License Perl, Shell script

2.4 Tool recommendation

From the above results, we conclude that DRDC choice to go with the cloud tool OpenStack for its private cloud deployment is sound and justiﬁed. Putting aside the faulty documentation, there are many other factors demonstrating that OpenStack is the right choice. Firstly, there is a huge community composed of the major players in IT companies that are contributing to the OpenStack Software23. Second, many of the contributing companies oﬀer support. The fact that OpenStack is compatible with two of the most important standards is a important factor for interoperability. Also, OpenStack has an important position in last year’s trends survey for private cloud usage24.

23 http://stackalytics.com/ 24 http://www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-2016-state-cloud-survey

15 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

2.5 Other recommended books and articles

This section underlines some of the scarce but recent and interesting publications on the subject of intercloud communications and mainly cloud federations. Note that these references diﬀer a lot from the online documentation of open-source cloud framework. As mentioned before the latter was often deprecated, contradictory, rarely updated and very technical. On the other hand, the following references are in-depth documents on cloud technology and future developments.

2.5.1 Books

Here are some of the books we found:

1. Identity, Authentication, and Access Management in OpenStack: Implementing and Deploy- ing Keystone [10]. Some parts are accessible from GoogleBooks25. Easy to read. Approaches basic concepts. It focuses on Keystone which is the portal between clouds in a federation.

2. OpenStack Cloud Computing Cookbook - Third Edition [8]. This book describes each Open- Stack module and describes the installation and conﬁguration of each module. This edition covers the Juno and Kilo version of OpenStack but not the latest versions.

3. Openstack Essentials [11]. Mixed reviews. Can be helpful for starting up but may not be suﬃcient for more advanced features. Only about single OpenStack implementation, with nothing for federation of OpenStack.

4. Intercloud: Solving Interoperability and Communication in a Cloud of Clouds [3]. The URL provided in the reference shows the ﬁrst ﬁfty pages of the book. The book that is the most related to this study: intercloud communication. Easy to read but too much Cisco-Oriented.

5. OpenStack cloud security [9]. Better than OpenStack Essentials from the same series. At least, it mentions federation identity related information but it can become rapidly limited for one’s need.

6. OpenStack Operations Guide [13]. Similar to Openstack Essentials but more detailed for each OpenStack module. Very little on federations. Very large cloud-related glossary.

Of the books listed above, only one [3], addresses in depth the subject of intercloud communication.

2.5.2 Articles

More updated and related information can be found in some articles:

1. In Tartarini [14], we have a good tutorial of how a federation of cloud is set up at CERN. Although the report is slightly old (2014) compared to other references, we make an exception

25 https://books.google.ca/books?id=nZYpCwAAQBAJ&pg=PT16&source=gbs_toc_r&cad=4#v=onepage&q&f=false

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 2. Literature Review

for this reference as it provides nevertheless a very good introduction on diﬀerent concepts of intercloud technologies.

2. In Assis and Bittencourt [2], they survey diﬀerent types of cloud federation architectures.

3. In Lee [5], the author describes how to approach the management of a federation.

4. In [6] and [12], the articles describe setting up of a federated OpenStack system.

The articles provide better understanding of OpenStack federations but these articles are still partially out-of-date. In order to really understand the OpenStack framework, we have to fall back on the software documentation (https://docs.openstack.org/).

17 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 3

Multicloud Existing Applications

OpenStack was ﬁrst released in 2010. Since then, a lot of fans of this technology have deployed a private cloud in their infrastructure. These users have established a baseline that enables Open- Stack community to evolve and improve. This section refers to success stories and on-going projects related to multicloud and interoperability.

3.1 Success Stories

Three success stories that have helped improve OpenStack through their lessons and recommen- dations are described below.

3.1.1 The Interop challenge

The Interop challenge1 has been submitted to the major players of the OpenStack community. The main goal was to achieve complete interoperability between diﬀerent OpenStack cloud providers. The group of providers worked together to develop a common and standard operation to deploy cloud resources. They succeeded and developed orchestration tools that facilitate deployment of cloud resources using templates.

Interoperability is the ability of a system or a product to work with other systems or products without special eﬀort on the part of the customer2.

3.1.2 European Grid Infrastructure (EGI)

EGI is an organization that’s being developed to coordinate the European Grid Infrastructure, based on the federation of individual National Grid Infrastructures, to support a multi-disciplinary

1 https://wiki.openstack.org/wiki/Interop_Challenge 2 http://searchmicroservices.techtarget.com/definition/interoperability

19 Final Report for RISOMIA Call-up 17 user community. The EGI regroups the infrastructure into two realms: The Open Standard realm and the OpenStack realm. The Open Standard Realm regroups heterogeneous IAAS cloud technology together using the OCCI standard. The OpenStack realm, while compatible with the OCCI standard, uses the OpenStack native API. The EGI cloud infrastructure provides services of identiﬁcation, monitoring, a Virtual Machine image catalog, a service registry and many more.

3.1.3 NeCTAR

NeCTAR3 is similar to the EGI cloud. It is an Australian government funded federated cloud, distributed across Australia and made for research purposes.

Each site runs its own computing nodes, object storage and virtual machine image storage services. The whole infrastructure shares the same authentication services (keystone), a virtual machine image registry and a dashboard. When a site uses other sites’ computing power, they need to pay back in computing power time.

3.2 On-going experiences and projects

This section presents an overview of projects and of architectures of communicating clouds.

3.2.1 Project Tricircle

This project aims to provide a networking automation across multi-region OpenStack deployment. The project enables networking between two clouds by connecting local Neutron (network services) servers using a coordinator Neutron server. The coordinating Neutron ensures the management of the IP address pool, of the IP/MAC address allocation and of the network segment allocation without conflicts across clouds. This type of configuration enables fast communication between clouds using low level Internet protocols (L2 and L3). The common architecture is illustrated in the figure 3.1.

From the control plane view (cloud management view ), Tricircle is to make Neutron(s) in multi-region OpenStack clouds working as one cluster, and enable the creation of global network/router etc abstract networking resources across multiple OpenStack clouds. From the data plane view (end user resources view), all VMs (could also be bare metal servers or containers) are provisioned in diﬀerent clouds but can be interconnected via the global abstract networking resources, of course, with tenant level isolation4. 3 https://www.openstack.org/user-stories/nectar/ https://nectar.org.au/cloudpage/ https://www.openstack.org/summit/portland-2013/session-videos/presentation/ 13-months-of-operations-a-federated-cloud-serving-the-broader-research-community 4 https://wiki.openstack.org/wiki/Tricircle

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 3. Multicloud Existing Applications

Figure 3.1: Tricircle Architecture Source: https://wiki.openstack.org/wiki/Tricircle.

3.2.2 Project Trio2o

This project aims to implement an API gateway between two OpenStack clouds and is derived from the Tricircle project. Trio2o is based on a top-bottom architecture, using a top Trio2o instance in front of multiple pods, as seen in the Figure 3.1. Trio2o provides storage service gateway (nova, cinder). Trio2o proposes to use one instance of keystone to authenticate users.

21 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

Figure 3.2: Trio2o Architecture Source: https://wiki.openstack.org/wiki/Trio2o.

3.2.3 Inter Cloud Resource Federation

The Inter Cloud Resource Federation project5 aims to provide an architecture of two independent clouds to establish a federation. The ﬁgure 3.3 shows how a user would authenticate to another cloud through his own keystone instance. Once authenticated, the user can request the resources catalog from any keystone. Keystone, the authentication module of OpenStack, acts as an Identity Provider and as a Service Provider. The keystone federation project was integrated to the core keystone API.

5 https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 3. Multicloud Existing Applications

Figure 3.3: Inter Cloud Resource Federation Architecture Source: https://wiki.openstack. org/wiki/Inter_Cloud_Resource_Federation.

23 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 4

OpenStack Components and Federation Architecture

OpenStack is a cloud system that controls large pools of computing, storage, and networking resources through a data centre. Everything can be managed through a dashboard that gives control to the administrators while empowering the users to provision resources through a web interface. OpenStack assembles many components operating together to provide a fully working IaaS. This section describes every core component of OpenStack and their role in a multicloud environment.

4.1 Components roles

The components’ roles and names are displayed in the 4.1 ﬁgure.

Figure 4.1: OpenStack component architecture. Source: https://docs.openstack.org/ security-guide/introduction/introduction-to-openstack.html

25 Final Report for RISOMIA Call-up 17

Nova : Compute Manages the life cycle of computing instances in an OpenStack environment. Features include spawning, scheduling and decommissioning of machines on demand. Nova support a wide variety of computing technologies, including libvirt variant, Hyper V, VMware and docker using a third party plug in.

Cinder : Block Storage Provides persistent disk (block) storage for running instances. Its pluggable driver architecture facilitates the creation and management of block storage devices.

Neutron : Networking Provides various networking services for cloud instances such as IP address management, DNS, DHCP, load balancing and firewall rules. Neutron offers a fine-grained network configuration enabling users to manage guest network, traffic isolation and network availability. It has a pluggable architecture that supports many popular networking vendors and technologies.

Glance : Image Service Provides a catalog of predeﬁned virtual machine. Glance enables the administrator to add, delete and manage accessibility of virtual machine. Users can directly use glance’s proposed instance to start VM.

Swift : Object Storage Provides a RESTful HTTP based API to store and retrieve unstructured data object. Data object is best used for storing static data such as media ﬁles, virtual machine images and backup. Swift is highly fault tolerant with its data replication and scale out architecture.

Keystone : Identity Provides authentication and authorization services for other OpenStack services. Keystone is the entry point of the whole cloud. It provides a catalog of endpoints for all OpenStack services. Keystone also enables identiﬁcation through federation.

Horizon : Dashboard Provides a web-base interface for both cloud administrators and users. Horizon enables the user to easily interface with all the OpenStack services.

For a more detailed description of the above modules, the reader is invited to visit the following websites:

1. https://en.wikipedia.org/wiki/OpenStack

2. https://docs.openstack.org/

3. http://vmartinezdelacruz.com/in-a-nutshell-how-openstack-works/

Every component of OpenStack oﬀers a documented REST API1. Furthermore, every OpenStack component is open source and the source can be consulted on the OpenStack GitHub2. OpenStack

1 https://developer.openstack.org/api-guide/quick-start/ 2 https://github.com/openstack

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 4. OpenStack Components and Federation Architecture services have very limited dependency upon each other, the main dependency is by keystone managing the authentication. Many services can be added or replaced with minimal impact. OpenStack oﬀers a software development kit3 to aid development of a new module.

The interaction between the components is illustrated in the ﬁgure 4.2.

Figure 4.2: OpenStack component interaction. Source: http://ken.pepple.info/openstack/ 2012/09/25/openstack-folsom-architecture/

Beside these core components, other popular components can easily be added to OpenStack. Open- Stack oﬀers a list of optional components4 with varying levels of maturity. The orchestration service called Heat is one of the most interesting components in that list. Heat allows the deployment of a pre-deﬁned infrastructure using templates.

Each of the web services of OpenStack can be enabled/disabled individually. For example, we can deactivate the Nova service5. Because there are individual web services, it is quite possible to replace any of the OpenStack services by another custom made web service as long as they obey the same API deﬁned for that service. Components interact with each other using the HTTP protocol following a standard API. If the custom-made component follows the same API, it should be compatible with the other OpenStack services. For example, Nova is compatible with the OCCI standard interface and the reference of the API is deﬁned in https://developer.

3 https://developer.openstack.org/sdks/python/openstacksdk/users/index.html 4 https://www.openstack.org/software/project-navigator 5 https://docs.openstack.org/admin-guide/cli-nova-manage-services.html

27 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17 openstack.org/api-ref/compute/. Similarly for Neutron, an architecture guide proposes to use the old Nova networking capability. The API is deﬁned in https://developer.openstack.org/ api-ref/networking/v2/index.html.

Another aspect of network management is resistance to network outages. In this case, there is no miracle. The cloud environment will provide tools to resync the system after an outage but the responsibility for how the system or application will react is up to the developer, choosing to use or not the tools provided by the cloud environment6.

Besides the API constraint, each web service could be modiﬁed to adopt additional constraints. Network control is much more sophisticated in clouds than organization/business networks. For example, with Neutron, you can still create proxies, ﬁrewalls, and other IP tables rules. On top of that, cloud networking allows you to completely isolate applications or create custom-made sub-nets on a need to know basis. OpenStack is project-based (before that, projects were called tenants). A project can have a limitation. Projects have their own resources of computing and networking and are isolated from other network projects by default. Each project manages its own network. The network can be exposed or not. The TriCircle project aims to manage Neutron across multi-region cloud.

Even if the components are independent and self containing, OpenStack evolves very quickly and new features may break legacy or outdated third party components.

4.2 OpenStack Federation

A federated identity network represents the establishment of a trust relationship between clouds. It enables users to securely access resources across multiple endpoints (in diﬀerent clouds) by using their credential only once. Federated projects also centralize the identity management and allow the usage of multiple clouds simultaneously. This section deﬁnes the federation components and illustrates the architecture of a federation.

4.2.1 Deﬁnition

The main components of an identity federation are the service provider and the identity provider. The role of the service provider is to provide cloud services to users. The role of the identity provider is to manage the authentication process for all the other clouds. The service provider must be conﬁgured to trust the identity provider. The conﬁguration is often made through an exchange of metadata between them. Thus, the service provider doesn’t manage or store any user credential. The Identity Provider (IdP) stores and manages the credential of every cloud user. Keystone can act as both service provider and identity provider for OpenStack. However, it needs an external software to act as a service provider and to use the federation protocol.

The federated identity ﬂow is deﬁned by a federation protocol. There are three main federation

6 https://docs.openstack.org/developer/swift/overview_container_sync.html# what-s-going-on-behind-the-scenes-in-the-cluster, https://docs.openstack.org/developer/swift/overview_container_sync.html

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 4. OpenStack Components and Federation Architecture protocols: Oauth, SAML2 and Openid Connect. SAML2 is recommended in OpenStack despite the complexity of the installation of its components.

4.2.2 Architecture

In the case of a two-cloud federation, a Keystone to Keystone (k2k) federation can be established. One keystone becomes the identity provider and the other, the service provider. The access can then be symmetrical: users of both clouds can authenticate and use the resources of the other cloud. The federation authentication is also called Single Sign On (SSO) and it is brieﬂy illustrated in the ﬁgure 4.3.

Figure 4.3: Single sign-on using SAML in a Web browser

4.3 Federation architecture and mechanisms

There are multiple conﬁguration possibilities to connect multiple clouds together. The standards, described in section 2, are mostly deﬁned for IaaS clouds. This section describes the mechanisms

29 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17 of discovery, management and monitoring when more than one cloud environment is available to fulﬁll a request.

4.3.1 Discovery

In a single cloud environment, keystone plays the role of identity management and cataloguing. In a multicloud environment, multiple keystones can be connected together to form a federated identity network. Once the federated identity is established, both keystones’ catalogs are available to users. The catalogs are the points of access to all the services oﬀered by the cloud.

4.3.2 Management and monitoring

The Horizon dashboard exploits the API of each module to oﬀer a convenient web interface to interact with all the OpenStack components. The web interface is simple but powerful. It provides a usage dashboard to help monitor the available resources. OpenStack also oﬀers a command-line utility that interacts with components through the API. Horizon can help manage multiple clouds simultaneously.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 5

Installation Guide

This section describes the installation of a cloud identity federation. OpenStack is a collection of services that can be deployed on one or more computers. It can be used for several different use cases which make it very flexible. However, this flexibility makes it complex and hard to configure. Considering this, it is not feasible to develop a quick installation guide.

This guide provides information, insight and trouble shooting regarding the deployment made in our experiment. We have deployed the cloud federation several times on virtual hardware and only two actual computers. In order to be able to deploy multi-node clouds, this guide will refer to resources about multi-node clouds when needed.

Warning: The following instructions are meant to be executed by someone with deep understanding of large system installation and network administration and conﬁguration. These instructions may vary depending on the context such as special ﬁrewall or proxy settings. We suggest the system administrator to revisit previous RISOMIA reports where instructions were given for that context (MSARI administration documents and [1]). Also, we strongly suggest not to deviate from the following instructions as a lot of lessons learned and debugging were included in these instructions. The OpenStack version used in this section is the latest one at the time of writing: the ocata release. If you use another version, past or future, some of the provided instructions may not apply.

A list of all the web resources used for debugging and producing this set of consistent instructions can be found in Annex A.

This chapter is divided in three sections:

• Section 5.1 Centos installation : describes the installation steps of centos Operating system for OpenStack cloud deployment.

• Section 5.2 OpenStack installation : explains how to install an OpenStack cloud.

• Section 5.3 Federation conﬁguration: details how to establish a cloud federation

31 Final Report for RISOMIA Call-up 17

5.1 Centos installation

This section enumerates steps to install Centos. Centos is a free-Software operating system derived from RedHat Enterprise Linux (RHEL) sources. It’s free of charge and it’s fully compatible with RHEL. In the case of a multi-node clouds, you should follow these instructions for every computer.

5.1.1 Installation

1. Download centos minimal: ”http://mirror.esecuredata.com/centos/7/isos/x86 64/CentOS- 7-x86 64-Minimal-1611.iso” and burn the ISO image on a CD. Alternative mirrors can be found at https://www.centos.org/download/mirrors/

2. Proceed with the installation on a server (with Internet access) with suﬃcient disk space (500GB or higher) and memory (16GB or higher).

3. Define the network so we can enable NTP in the next step. In the Network and hostname section, define the parameters for your network. In our case, we used a manual (static IP address) configuration.

4. Set date and time, keyboard and language settings using the GUI interface.

5. In the Installation source section, use the automatic settings for installation from the media or choose another installation option (i.e. network). If access to Internet is required, you may have to provide proxy information (for DRDC: http://webproxy.drdc-rddc.gc.ca:8080). See instructions in Call-up 13 3.3.1.1.

6. In the Software selection section, select Minimal install.

7. In the Installation destination section, select/conﬁgure the disk partition that will contain the OS with the appropriate mount point. If you use a disk partition which already has Grub installed, uncheck the installation disk in the ”boot loader” section (bottom left).

8. When all the sections are conﬁgured, click on Begin Installation.

9. In the User settings (next page) create the root password and another user administrator (recommended). In the advanced section, we set the oodaadmin home in the /.

10. Click on the Reboot button when the installation process is complete. Remove the CD.

11. For those who are using an already installed Grub, you must run sudo update-grub2 on the OS that contains the ﬁrst grub installation in order to detect the new Centos in the Grub boot section.

12. Connect in the administrative account (root or oodaadmin).

13. Adjust the network parameter files if necessary (mostly /etc/hosts to add other machines, /etc/sysconfig/network-scripts/ifcfg-XXXXX, /etc/resolv.conf, etc) in order to reflect your network configuration. Reboot to activate any modification.

14. Run

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 5. Installation Guide

yum -y update

15. Run

yum install -y net-tools wget bind-utils iptables-services bridges-utils \ bash-completion policycoreutils-python

16. Conﬁgure your SSH:

(a) Add the following line to the default /etc/ssh/sshd config ¯ PermitRootLogin yes Note: A similar configuration to callup 13 has been tried, but was too restrictive and yielded problem at OpenStack installation (b) Generate keys ssh-keygen -t rsa -b 4096 Note: You can also copy the full .ssh directory from another machine (c) Copy public keys from the two computers in the ”authorized keys” file. (d) Include also a local copy of the id rsa.pub in authorized keys to allow copy between admin accounts. (e) Adjust the permission of .ssh (700) and .ssh/authorized keys (600) is ok. semanage fcontext -at user_home_dir_t /oodaadmin semanage fcontext -at ssh_home_t /oodaadmin/.ssh semanage fcontext -at ssh_home_t /oodaadmin/.ssh/authorized_keys restorecon -Rv /oodaadmin

17. Test the SSH connection

5.2 OpenStack installation

Since OpenStack is a free software licensed under the Apache license, many big companies have developed a “ﬂavor” of OpenStack, often customizing the dashboard interface. Every single service can be installed manually, but to facilitate and accelerate the installation, a deployment solution is preferable. For this project, we sought an open source and free openstack deployment solution. We evaluated three solutions: devstack, packstack and openstack-ansible.

The OpenStack development community has developed a tool called devstack to easily deploy openstack for development. Devstack installs a selected component directly from github source code. The Devstack community advertises that this deployment solution is not stable and should not be used for production.

Packstack is a Redhat based community way ( RDOproject1 ) aiming to develop an easy and stable OpenStack development solution. The developed tool uses a puppet2 tool to conﬁgure and deploy every OpenStack component. The project uses mature and stable OpenStack source and advertises a production-ready deployment solution.

1 https://www.rdoproject.org/ 2 https://puppet.com/product/capabilities

33 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

OpenStack Ansible is deployment solution similar to Packstack. Ansible is an orchestration, deployment and conﬁguration manager.

Packstack was used in this project because of its stability and simplicity and because it’s speciﬁcally designed for Red Hat-based operating systems.

5.2.1 Architecture

The OpenStack services can be deployed in many diﬀerent ways to fulﬁll every requirement and/or restriction of a project. There are many architecture guidelines that can help design the deploy- ment3.

For a simple deployment, we suggest using one controller node and few compute nodes as illustrated in the ﬁgure 5.1.

Figure 5.1: Cloud federation proposed architecture

5.2.2 Installation

The installation is divided in two sections: the configuration to be made on all computers and the configuration of the controller node of each cloud. We propose to install and configure each cloud separately then configure the federation described in the section 5.3.

5.2.2.1 Every computer node

1. Conﬁgure network interface

3 https://docs.openstack.org/arch-design/ https://access.redhat.com/documentation/en-us/red hat openstack platform/10/html/architecture guide/ https://docs.oracle.com/cd/E36784 01/html/E54155/archover.html https://www.ibm.com/support/knowledgecenter/SST55W 4.3.0/liaca/liaca deploy overview.html

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 5. Installation Guide

OpenStack Networking does not work on systems that have the Network Manager service enabled. Each server must disable NetworkManager and enable the standard network service. Disable NetworkManager

systemctl stop NetworkManager.service systemctl disable NetworkManager.service

To enable the standard network service, the interface network script must be modiﬁed to add the following lines.

# /etc/sysconfig/network-scripts/ifcfg-enp3s0 NM_CONTROLLED="no" ONBOOT="yes"

Finally, the network service must be started and enabled at boot time.

systemctl start network.service systemctl enable network.service

2. Configure firewall The last version of CentOS comes with firewalld instead of iptables. We must replace firewalld with iptables. Install iptables

yum install iptables-services

Disable ﬁrewalld and enable iptables

systemctl disable firewalld.service systemctl stop firewalld.service

systemctl start iptables.service systemctl enable iptables.service

systemctl start ip6tables.service systemctl enable ip6tables.service

3. Disable SElinux

setenforce 0 getenforce # should output 'Permissive'

4. Modify sshd Add the following line to /etc/ssh/sshd conﬁg

PermitRootLogin yes

5. Set hostname The hostname should be diﬀerent from the compute node, ie: controller.cloud1.drdc- rddc.lan, compute01.cloud1.drdc-rddc.lan, compute02.cloud1.drdc-rddc.lan... The hostname should be self-described, and will be used on other steps of the installation. Fully qualiﬁed name is recommended

hostnamectl set-hostname controller.cloud1.drdc-rddc.lan

35 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

6. Install network time service

yum install chrony -y systemctl enable chronyd systemctl start chronyd systemctl status chronyd

5.2.2.2 On the controller node

In case of a multi-node deployment, the controller node should be able to access every compute node using ssh without password.

1. Install packstack

yum install openstack-packstack -y

2. Generate answer ﬁle

packstack --gen-answer-file=answerfile.txt

note: This command will create an answer ﬁle to be used by the current user. The answer generated ﬁle contains information about the current user. ie: ssh keypair and default host.

3. Generate ssl sertiﬁcate for every service

openssl req -x509 -sha256 -newkey rsa:2048 -keyout /etc/pki/tls/private/selfkey.key \ -out /etc/pki/tls/certs/selfcert.crt -days 365 -nodes

openssl req -x509 -sha256 -newkey rsa:2048 -keyout /etc/pki/tls/private/ssl\_vnc.key \ -out /etc/pki/tls/certs/ssl\_vnc.crt -days 365 -nodes

openssl req -x509 -sha256 -newkey rsa:2048 -keyout /etc/pki/tls/private/ssl\_dashboard.key \ -out /etc/pki/tls/certs/ssl\_dashboard.crt -days 365 -nodes

chmod 600 /etc/pki/tls/private/* chmod go-rX /etc/pki/tls/private/

4. Modify the answer ﬁle Open the answer ﬁle with your preferred editor and modify the line described above. For a multi-node deployment, the and should be replaced with the cloud 1 controller hostname and compute node hostname respectively set at the section 5.1. In the case of a single node deployment, the controller node will also act as a compute node. The should change according to the cloud. ie: RegionOne, RegionTwo.

CONFIG_SSH_KEY=/root/.ssh/id_rsa.pub

CONFIG_HORIZON_SSL=y

CONFIG_CONTROLLER_HOST=

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 5. Installation Guide

# List the servers on which to install the Compute service. (the control node may be in the list) CONFIG_COMPUTE_HOSTS=,

# IP address of the server on which to install the AMQP service. (Usually the controller node) CONFIG_AMQP_HOST=

# Default region name to use when creating tenants in the Identity # Service. CONFIG_KEYSTONE_REGION=< RegionX >

# Identity service API version string. ['v2.0', 'v3'] CONFIG_KEYSTONE_API_VERSION=v3

CONFIG_SSL_CACERT_FILE=/etc/pki/tls/certs/selfcert.crt

CONFIG_SSL_CACERT_KEY\_FILE=/etc/pki/tls/private/selfkey.key

CONFIG_VNC_SSL_CERT=/etc/pki/tls/certs/ssl_vnc.crt

CONFIG_VNC_SSL_KEY=/etc/pki/tls/private/ssl_vnc.key

CONFIG_HORIZON_SSL_CERT=/etc/pki/tls/certs/ssl_dashboard.crt

CONFIG_HORIZON_SSL_KEY=/etc/pki/tls/private/ssl_dashboard.key

CONFIG_HORIZON_SSL_CACERT=/etc/pki/tls/certs/selfcert.crt

5. Install OpenStack The installation downloads and installs all components. In case of a multi-node environment, the controller node will install the required software to every compute node. The installation is a long process.

packstack --answer-file=answerfile.txt --timeout=1000 6. Validate At the end of the installation, the script should output a file called keystonerc admin in the home directory of the current user. This file contains the login variables to be able to manage OpenStack. You can access the url http:///dashboard to validate the OpenStack installation. The credential information should be in the keystonerc admin file. The OpenStack user guide4 offers pertinent information about how to use the dashboard and also the OpenStack command line client. The section OpenStack command-line interface cheat sheet shows a broad list of examples of the OpenStack command line client.

5.3 Federation conﬁguration

An identity federation allows to rely on a trusted third party’s authentication system in order to use a service. A federation generally involves an identity provider and a service provider. In a 4 https://docs.openstack.org/user-guide/UserGuide.pdf

37 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

Keystone federation, two keystones are involved (Identity Service for OpenStack). One keystone becomes the Service provider while the other is the Identity Provider. As describe in the ﬁgure 5.1, the cloud 1 controller will act as the Identity Provider (IdP) and the cloud 2 will act as the Service Provider (SP).

This documentation seeks to help you deploy a keystone to keystone federation using OpenStack Ocata version (latest at this time).

5.3.1 Architecture

At this point, the cloud 1 controller should be able to ping the cloud 2 controller by hostname and vice versa. This means that either a Domain Name System (DNS) server resolves the hostname or the /etc/hosts ﬁle has been populated with the hostname/ip of each cloud controller.

5.3.2 Conﬁguration Identity Provider (IdP)

The controller.cloud1.drdc-rddc.lan host is the controller of the cloud 1.

Figure 5.2: Identity Provider Conﬁguration

1. Install dependency

yum install xmlsec1 xmlsec1-openssl python-pysaml2 -y

2. Generate keystone saml signing key

mkdir /etc/keystone/ssl mkdir /etc/keystone/ssl/certs /etc/keystone/ssl/private

openssl req -x509 -newkey rsa:2048 -keyout /etc/keystone/ssl/private/signing_key.pem \ -out /etc/keystone/ssl/certs/signing_cert.pem -days 9999 -nodes

3. Edit /etc/keystone/keystone.conf

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 5. Installation Guide

[saml] certfile=/etc/keystone/ssl/certs/signing_cert.pem keyfile=/etc/keystone/ssl/private/signing_key.pem idp_entity_id=http://controller.cloud1.drdc-rddc.lan:5000/v3/OS-FEDERATION/saml2/idp idp_sso_endpoint=http://controller.cloud1.drdc-rddc.lan:5000/v3/OS-FEDERATION/saml2/sso idp_metadata_path=/etc/keystone/saml2_idp_metadata.xml

[auth] methods = password,token,oauth1,mapped

4. Generate IdP metadata After populating keystone.conf, you can run the following command to generate the IdP metadata wich is based on the conﬁg ﬁle. If you modify keystone.conf, you must regenerate the IdP metadata.

keystone-manage saml_idp_metadata > /etc/keystone/saml2_idp_metadata.xml

5. Restart httpd Keystone is a web service running under httpd, restarting httpd, restart keystone.

sudo service httpd restart

At this point, if you follow the following url, you should be able to receive the IdP metadata

curl http://controller.cloud1.drdc-rddc.lan:5000/v3/OS-FEDERATION/saml2/metadata

6. Add the Service Provider to OpenStack Every OpenStack service oﬀers a HTTP API to communicate with it. OpenStack community has developed a Python base client to interact with OpenStack services. You can provide credentials to the python client by populating the environment variable using the following command.

cd ~ source keystone_admin

note: The ﬁle keystone admin is generated at the end of the section 5.2.2.2 and should be in the home user directory. Once the ﬁle has been sourced, use the OpenStack python client to create a Service provider reference.

openstack service provider create --auth-url \ http://controller.cloud1.drdc-rddc.lan:5000/v3/OS-FEDERATION/identity_providers/myidp/protocols/mapped/auth \ --service-provider-url https://controller.cloud2.drdc-rddc.lan/Shibboleth.sso/SAML2/ECP mysp

note: myidp and mysp is the ID of instance. The ID should be consistent between The IdP and the Service Provider (SP)

39 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

5.3.3 Conﬁguration Service Provider (SP)

The controller.cloud2.drdc-rddc.lan host is the controller of the cloud 2.

Figure 5.3: Service Provider Conﬁguration

1. Install Shibboleth

curl http://download.opensuse.org/repositories/security://shibboleth/CentOS_7/security:shibboleth.repo -o \ /etc/yum.repos.d/shibboleth.repo

yum update -y yum install shibboleth -y

2. Generate Shibooleth keypair

cd /etc/shibboleth/ sudo /etc/shibboleth/keygen.sh -f -u shibd -h centos2.centos.lan -y 3 \ -e https://centos2.centos.lan/shibboleth -o /etc/shibboleth/

3. Enable shibboleth service

systemctl enable shibd systemctl restart shibd

4. Conﬁgure httpd virtual host Add the following lines at the end of the ﬁle /etc/httpd/conf.d/shib.conf

AuthType None Require all granted SetHandler shib

ShibRequestSetting requireSession 1 AuthType shibboleth

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 5. Installation Guide

ShibExportAssertion Off Require valid-user

5. Conﬁgure Shibboleth The following ﬁles are all located in /etc/shibboleth/

(a) attribute-map.xml Add the following lines at the end of the ﬁle /etc/shibboleth/attribute-map.xml (b) shibboleth2.xml SAML2 SAML1

(c) Testing Shibboleth metadata The following url should output the metadata corresponding with the information en- tered. curl https://controller.cloud2.drdc-rddc.lan/Shibboleth.sso/Metadata

6. Add the Identity Provider to openstack You should use the command source keystone admin before executing the openstack command.

openstack identity provider create --remote-id \ http://controller.cloud1.drdc-rddc.lan:5000/v3/OS-FEDERATION/saml2/idp myidp

7. Create the domain, project and group and assign roles

openstack --insecure domain create federated_domain openstack --insecure project create federated_project --domain federated_domain openstack --insecure group create federated_users openstack --insecure role add --group federated_users --domain federated_domain _member_ openstack --insecure role add --group federated_users --project federated_project _member_

8. Create mapping Create a json ﬁle containing the mapping to be loaded. The

cat > rules.json <

41 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

{ "user": { "name": "{0}" }, "group": { "domain": { "name": "Default" }, "name": "federated_users" } } ], "remote": [ { "type": "openstack_user" } ] } ] EOF

Load the mapping to openstack

openstack --insecure mapping create --rules rules.json myidp_mapping openstack --insecure federation protocol create saml2 --mapping myidp_mapping --identity-provider myidp

9. Restart Keystone

sudo service httpd restart

The table 5.1 oﬀer a reference of modiﬁcation done on each cloud controller.

Node Name controller.cloud1.drdc-rddc.lan controller.cloud2.drdc-rddc.lan

Role Identity Provider Service Provider

xmlsec Installation xmlsec1-openssl shibboleth python-pysaml2

/etc/keystone/ssl/private/signing key.pem /etc/shibboleth/sp-key.pem Files to create /etc/keystone/ssl/certs/signing cert.pem /etc/shibboleth/sp-cert.pem /etc/keystone/saml2 idp metadata.xml rules.json

/etc/httpd/conf.d/shib.conf Files to modify /etc/keystone/keystone.conf /etc/shibboleth/attribute-map.xml /etc/shibboleth/shibboleth2.xml

Table 5.1: Conﬁguration modiﬁcation for each cloud controller

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 6

Applications of Communication Between Federated OpenStack Cloud

This chapter describes the particular feature of OpenStack that can be exploited in a federation and present diﬀerent examples of intercloud interaction at the level of IaaS, PaaS and SaaS.

6.1 Federated OpenStack Features

The OCCI API interface oﬀers a standard way to interact with heterogeneous cloud. When using a homogeneous cloud federation, both clouds can communicate with the standard deﬁning their interaction. In the case of OpenStack, every component provides a web interface which eases the interaction interclouds. Federated OpenStack can augment the reliability and performance of a single cloud.

Some OpenStack components extend gracefully in a federated cloud network. The keystone service can be configured to trust other cloud Identity services enabling federated users to access the cloud resources. The Swift’s storage RESTful HTTP API can be used easily in different clouds to store or replicate data across the network. The Nova’s compute live migration features can be extended to federated projects and offer a greater load balancing enhancing the performance for the whole cloud.

6.2 IaaS application examples

Infrastructure as a service offers infrastructure to run and manage operating systems, storage and networking. The IaaS may also be the level that offers the most flexibility.

43 Final Report for RISOMIA Call-up 17

6.2.1 Workload transfer

One of the main uses of IaaS intercommunication is workload transfers. When several clouds are connected together, the pool of computing resources get augmented. If a cloud resource usage passes a deﬁned threshold, virtual machine can be migrated to a trusted cloud without interruption. This feature is a clear example of performance and reliability enabling a constant workload on the cloud. It also optimizes resource exploitation by using unused computing power.

The name cloud bursting is used when a cloud migrates some of its workload to another cloud. It is used mostly in a hybrid cloud1 context where the originator is a private cloud and the recipient is a public cloud. This process is designed to minimize the cost related to the constant usage of large public cloud service providers (e.g. Amazon AWS and EC2).

In the case of a homogeneous multicloud environment such as a federation of OpenStack, the term cloud bursting is less used but the same process can be applied2.

Currently, OpenStack did not yet implement an automatic scaling capability for doing cloud bursting within a OpenStack federation but it is under study.

6.3 PaaS application examples

Platform as a Service oﬀers the whole infrastructure to run an application. It abstracts the infrastructure and the operating system, but provide a runtime environment such as Java, Python, PHP, etc. PaaS is often targeted to software developers enabling them to concentrate their work on coding instead of installing infrastructure. However, some cloud interoperability still can be considered.

6.3.1 Database synchronization

PaaS providers often offer database instance. The databases offered are well known, stable and mature databases such as: mysql, Postgresql, Mongodb, etc. These databases offer some replication and synchronization services that could be used across multiple cloud.

6.3.2 Application provisioning

Applications running on PaaS rarely own a storage block. Applications can be easily replicated for load balancing a critical workload or even migrated to another cloud as instances in section 6.2.1. Application images can also be copied to other cloud services.

1 http://www.service-architecture.com/articles/cloud-computing/cloud_bursting.html 2 https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/ extending-openstack-to-allow-federation-between-clouds

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 6. Applications of Communication Between Federated OpenStack Cloud

6.4 SaaS application examples

Software as a service is the simplest architecture for intercloud communication. In a SaaS platform only application endpoint is exposed. The applications presented are usually web base services. When two clouds are connected through a federation, users can access available services.

6.4.1 Exchange of services

At the SaaS level, services can be exploited from diﬀerent clouds. If a vessel owns a unique detection hardware, an interface (i.e.: REST) could be implemented to use it. The access to the cloud services could be controlled by the cloud federation authentication.

45 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 7

At-sea Environment Limitation

This section describes the at-sea environment in terms of interoperability as well as information storage, discovery, distribution and access that may impact an at-sea cloud implementation.

The section 4.1 of RISOMIA call-up 11 report summarized the conclusions of the analysis per- formed regarding the current state-of-the-art for at-sea data exchange environment as follows:

1. There are a number of separate networks that support the exchange of information for diﬀerent purposes and between diﬀerent geopolitical subgroups.

2. There is information exchange at diﬀerent levels of security.

3. There are satellites as well as other radio communication systems that support the connectivity needs of at-sea vessels using various frequency channels.

4. There are US Military NATO standards that enforce how often and what type of information is exchanged.

Each one of these observations imposes limitations in terms of interoperability and information distribution and access. Observations 1 and 2 may impose restrictions for access of information by diﬀerent members of a task group. Hence, independently of any other technological limitations, there will likely be a need for a multitude of cloud categories and for a multitude of access and processing purposes. Observations 3 and 4 impact interoperability and data distribution which may become less limiting with technological enhancements over time. However, in cloud implementations, it is natural to assume that there will be less advanced task group members. The implementation designs should be able to accommodate various levels of technological maturity for interoperability and data distribution (standards for data exchange).

Section 4.2 of RISOMIA call-up 11 report provided an analysis of state-of-the-art information storage, discovery, distribution and access for on-board information sources. It sought to share the information between vessels and to establish the task force situational awareness through combination of on-board and oﬀ-board data. In the current state-of-the-art:

47 Final Report for RISOMIA Call-up 17

1. The information discovery services for on-board sensors are part of each platform Command and Control (C2), except for some US vessels that include the Cooperative Engagement Capability (CEC) which is a real-time sensor netting system that enables sharing and inte- grating the sensor raw reports of all ships enabled with CEC together.

2. Each vessel also includes services for combination and discovery of on-board and remote vessels.

3. Vessels may also have access to some capabilities and information products from the Global Command and Control System Maritime (GCCS-M), which includes its own information discovery capabilities supporting all of US maritime situational awareness.

Figure 7.1: DoD Enterprise Cloud Environment. Source: [15]

Figure 7.1 presents the US vision of Enterprise Cloud Environment where there is one central cloud-based C2. It contains all the necessary services that provide information storage, discovery, distribution and access capabilities. It also collects information from participating vessels and a variety of service providers via a secure communication link and it provides the required situational awareness to all the vessels and other decision centres. Ultimately, with technological advancements such a vision may be achieved within one nation in the future. Yet, it is hard to envisage this vision becoming a reality even within one nation very soon. This vision, as presented, also does not provide the necessary services to support multinational task force operations, which would need a number of separate networks that support the exchange of information for diﬀerent purposes and between diﬀerent geopolitical subgroups (data exchange observation 1 above).

While a fully cloud-based multinational operation can be envisaged into far enough future, each one of the at-sea data exchange environment observations impose constraints on the architecture

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 7. At-sea Environment Limitation design decisions of cloud implementations, of the information storage and of the discovery services. For example:

1. It is a recognized reality that Navies of diﬀerent nations and even various vessel types within the same nation do not evolve to the same technological maturity at the same time. Therefore the cloud architecture of any vessel will need to be designed to be able to accommodate information sharing with both cloud enabled vessels and cloud non-enabled vessels. It will necessitate the use of standards (observations 3 and 4) of various levels of technological maturity and to ensure maximal feasible situational awareness in every participating vessel.

2. Even in the case of most advanced connectivity and cloud capability environment (assuming all vessels having same technological maturity), as a result of limitations 1 and 2, there will be restrictions for sharing of information of certain types with certain vessels, and restrictions on certain vessels from using some external cloud-based information discovery and storage services. Consequently the architecture for cloud implementation in each vessel (based on country, roles, missions, etc.) will need to be designed to distribute information discovery and storage services between their own cloud and external clouds (on other vessels and global C2) to maximize situational awareness for each vessel.

The discussions above mention technological maturity for supporting cloud enabled naval vessels, including bandwidth, communication protocol, physical space / computer power, decoupled installation (ability to install as many clouds as necessary), security (encryption). Section 4.2.4 of the of RISOMIA call-up 11 report presents the details of the US defence messaging and communication technologies state-of-the-art of 2008. It also refers to the US efforts to evolve this to support the current connectivity needs1. It is realistic to expect that the technological advancements in supporting the connectivity needs will occur at a quicker pace than the efforts to upgrade the naval fleets of even most advanced nations.

In the near term, it would be valuable for the R&D eﬀorts to focus on analyzing and evaluating the cloud implementations in terms of:

• Trade-off between having dedicated clouds hosting specific information discovery services that receive information of a specific type, versus putting all information discovery services in each cloud, with each cloud processing information only pertinent to that vessel and then sharing the results

In the terminology of data fusion, having a central level cloud hosting the C2, which collects and processes all information and provides to each vessel whatever information they require for situational awareness, is optimal in terms of information processing performance. It is, however, too costly in terms of data transfer and connectivity. A distributed C2, sharing post-processed information products in each cloud, could lead to a somewhat lower quality information processing performance, but it has much lower data transfer costs. Experimentation with such alternative architectures will be valuable to help design the future naval vessel cloud architectures.

1 US Navy, C2oix, the Navy’s Newest Messaging System – Cost Eﬃcient and Simpler, November 2013, http: //www.navy.mil/submit/display.asp?story_id=74740

49 OODA Technologies Inc.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Final Report for RISOMIA Call-up 17

This page is intentionally left blank.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Part 8

Conclusion and Future Work

In this study, mechanisms and standards were found that allowed intercloud communication. A federation of two OpenStack implementations provided a concrete example of these communication functionalities. Intercloud interactions can be realized at diﬀerent levels: IaaS, PaaS and Saas. Usage and applicability will diﬀer in each of these levels.

If we answer the questions listed in the introduction:

• What is the state of these cloud framework environments? Answer: Evolving rapidly. Updated documentation sparse and erratic. Very little in-depth blogs or tutorials for helping the novice.

• Have they achieved a certain level of maturity? Are they stable? Answer: Not yet.

• Are they easy to use? Answer: Yes and no. Installation is still excruciatingly diﬃcult. Once in place, feature usage can be automatic or easy manageable through the OpenStack Dashboard or other means depending on the context.

• What can we do with it? And cannot do? Answer: The number of functionalities is increasing rapidly as new releases are coming out. Restrictions may apply depending on the level (IaaS, PaaS, SaaS), security and cloud standard protocols.

• Are they secured? Answer: Yes and it is partially part of the problem. Many things can go wrong during the installation and the level of security you want to achieve.

Some challenges were encountered during this project, notably :

• Very steep learning curve: It is no secret that learning about cloud technology requires a lot of eﬀort. It is related to many aspects of system administration, security, optimization, from hardware farm management, container technology and web services.

• Absence of a stable version: Because no stable release existed, we selected the latest version of OpenStack (named ocata) in order to minimize the number of deprecated features and maximize the number of new features.

51 Final Report for RISOMIA Call-up 17

• Lack of updated documentation: On many occasions, we found diﬀerent user guides with contradictory instructions mainly because they describe OpenStack at diﬀerent stages of its development. It took time to make sense of the information and to sort them out.

Based on the lessons learned during the development cycle, possible improvements are suggested for the next iteration of a intercloud application:

• Improve and update the ﬁndings of this study: As development continues on Open- Stack, new features will be implemented in future release and more examples of intercloud communication will be available. An update of the ﬁndings of this study may be useful in 6 months or more.

• Navy example: An example based on real-life restrictions of what would be a private cloud on a vessel could be interesting to investigate in order to identify the strengths and the weaknesses of such of construct and how it would apply in cloud communication between ships.

To summarize, although there were many hurdles and challenges in this investigation, this study successfully demonstrated the existence and the application of intercloud communication and its potential for maritime applications.

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Bibliography

[1] Yannick Allard, Michel Mayrand, Dan Radulescu, and Mathieu Lavall´ee.Command and Control Application Development: VOIR Server Design Details and Installation guide. Technical Report Contract W7707-145677/001/HAL, Call-up 13 ﬁnal report, Defence Research and Development - Atlantic, 2016.

[2] M.R.M. Assis and L.F. Bittencourt. A survey on cloud federation architectures: Identifying functional and non-functional properties. Journal of Network and Computer Applications, 72:51–71, 2016.

[3] J. Frahim, V. Josyula, M. Morrow, and K. Owens. Intercloud: Solving Interoperability and Communication in a Cloud of Clouds. 2016. ISBN 9780134189239. URL http: //ptgmedia.pearsoncmg.com/images/9781587144455/samplepages/9781587144455.pdf

[4] Jazib Frahim, Venkata Josyula, Monique J. Morrow, and Kenneth Owens. Intercloud: Solving interoperability and communication in a cloud of clouds. Technical report, Cisco, 2016. URL http: //ptgmedia.pearsoncmg.com/images/9781587144455/samplepages/9781587144455.pdf

[5] Craig A. Lee. A demonstration of federation management using the keyvoms prototype, 2016. URL http://gsaw.org/wp-content/uploads/2016/03/2016s11d_lee.pdf

[6] Geant Network Services People. Federated access to openstack, 2016. URL https://wiki.geant.org/download/attachments/53117373/20160122%20-% 20Federated%20access%20to%20Openstack.pdf

[7] F. Pop and M. Potop-Butucaru. Adaptive Resource Management and Scheduling for Cloud Computing: Second International Workshop, ARMS-CC 2015, Held in Conjunction with ACM Symposium on Principles of Distributed Computing, PODC 2015, Donostia-San Sebasti´an,Spain, July 20, 2015, Revised Selected Papers. Lecture Notes in Computer Science. Springer International Publishing, 2016. ISBN 9783319284484. URL https://books.google.ca/books?id=ERxaCwAAQBAJ

[8] K. Jackson, C. Bunch, and E. Sigler. OpenStack Cloud Computing Cookbook - Third Edition. Quick answers to common problems. Packt Publishing, 2015. ISBN 9781782174783. URL https://books.google.ca/books?id=850hswEACAAJ

53 Final Report for RISOMIA Call-up 17

[9] Fabio Alessandro Locati. OpenStack cloud security. Packt Publ., Birmingham, 2015. URL http://cds.cern.ch/record/2050420

[10] Steve Martinelli, Henry Nash, and Brad Topol. Identity, Authentication, and Access Management in OpenStack: Implementing and Deploying Keystone. O’Reilly Media, Inc., 1st edition, 2015. ISBN 1491941200, 9781491941201.

[11] D. Radez. Openstack Essentials. Community experience distilled. Packt Publishing, 2015. ISBN 9781783987085. URL http://ebook.konfigurasi.net/Openstack/OpenStack%20Essentials.pdf

[12] David W. Chadwick, Kristy W. S. Siu, Craig Lee, Yann Fouillat, and Damien Germonville. Adding federated identity management to openstack. J. Grid Comput., 12(1):3–27, 2014. doi:10.1007/s10723-013-9283-2. URL http://dx.doi.org/10.1007/s10723-013-9283-2

[13] Tom Fiﬁeld, Diane Fleming, Anne Gentle, Lorin Hochstein, Jonathan Proulx, Everett Toews, and Joe Topjian. OpenStack Operations Guide. O’Reilly Media, Inc., 1st edition, 2014. ISBN 1491946954, 9781491946954. URL http://www.stilson.net/documentation/OpenStack%20Operations%20Guide.pdf

[14] Luca Tartarini and Marek Denis. Federation of openstack clouds, 2014. doi:10.5281/zenodo.11982. URL https://zenodo.org/record/11982/files/CERN_openlab_Luca_Tartarini.pdf

[15] DoD. Cloud computing strategy, 2012. URL http://dodcio.defense.gov/Portals/0/Documents/Cloud/DoD%20Cloud% 20Computing%20Strategy%20Final%20with%20Memo%20-%20July%205%202012.pdf

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document. Appendix A

Installation Internet references

We present here a list of the web links that were helpful for the installation of OpenStack and the conﬁguration of a federation.

A.1 OpenStack

• https://www.rdoproject.org/install/quickstart/

• https://docs.openstack.org/

• See also section A.5

A.2 OpenStack Federation

• https://docs.openstack.org/developer/keystone/federation/federated_identity.html

• https://docs.openstack.org/ocata/config-reference/identity/federated-identity.html

• https://docs.openstack.org/developer/keystone/mitaka/configure_federation.html

• https://docs.openstack.org/developer/keystone/federation/configure_federation.html

• https://developer.openstack.org/api-ref/identity/v3-ext/index.html

• https://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure-federation-use-case. html

• https://docs.openstack.org/developer/keystone/federation/websso.html

• https://docs.openstack.org/developer/keystone/devref/api_curl_examples.html

• https://platform9.com/blog/openstack-keystone-federation/

• https://platform9.com/support/using-openstack-cli-saml-authentication/

• https://github.com/openstack/keystone-specs/blob/master/attic/v3/identity-api-v3-os-federation-ext. rst

• See also section A.5

A-1 Final Report for RISOMIA Call-up 17

A.3 Shibboleth

• https://www.switch.ch/aai/guides/sp/configuration/

• https://www.switch.ch/aai/support/presentations/shibboleth-training-2015/Shibboleth-Training-201509. pdf

• https://doit.missouri.edu/wp-content/uploads/2014/09/LinuxGuide.pdf

• http://iam.harvard.edu/resources/saml-shibboleth-integration

A.4 Keystone

• https://www.ibm.com/support/knowledgecenter/en/SST55W_4.3.0/liaca/liaca_configuring_keystone_ service_provider.html

• http://ibm-blue-box-help.github.io/help-documentation/keystone/k2k-federation/

A.5 Wiki and Blogs

• http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo/

• http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/

• http://shuquan.github.io/setting-up-keystone-to-keystone-federation

• https://github.com/shuquan/k2k-fed

• http://shuquan.github.io/

• http://xuctarine.blogspot.ca/2016/02/how-to-setup-keystone-with-shibboleth.html

• https://wiki.infn.it/progetti/cloud-areapd/aai_integration_with_keystone/integration_in_openstack_ kilo

• https://wiki.infn.it/progetti/cloud-areapd/aai_integration_with_keystone/aai_integrations_in_ openstack_ocata

A-2

The use or disclosure of the information on this sheet is subject to the restrictions on the title page of this document.