multi-cloud secure applications › sites › musa3.drupal.pulsartecnalia.co… · possible...

This project has received funding from the European Union’s Horizon 2020 research and innovation

programme under grant agreement No 644429

MUlti-cloud Secure Applications

Deliverable title Deliverable ID:

Final secure multi-cloud deployment

mechanisms and tools

D3.4

Preparation date:

30/11/2017

Editor/Lead beneficiary (name/partner):

Erkuden Rios / Tecnalia

Angel Rego / Tecnalia

Internally reviewed by (name/partner):

Wissam Mallouli / MI, Valentina Casola

/ CERICT

Abstract:

This deliverable includes the final technical specification of the mechanisms and tools that MUSA

offers to support the distributed deployment of multi-cloud application components, included in the

final MUSA Deployer prototype tool developed in the project. The document describes both the

mechanisms and the final prototype architecture and implementation. The prototype is built on top of

state-of-the-art open source solutions and offers innovation for multi-cloud deployments as described

in the document. The deliverable supersedes the initial version with additional features to support the

redeployment of application components in other cloud services if required, and also the reaction to

possible violations of the application Security Service Level Agreement.

Dissemination level

PU Public X

CO Confidential, only for members of the consortium and the Commission Services

D3.4 Final secure multi-cloud deployment mechanisms and tools 3

MUSA consortium

Fundación Tecnalia Research &

Innovation

(TECNALIA, Spain)

www.tecnalia.com/en

Project manager: Erkuden Rios

[email protected]

+34 664 100 348

Centro Regionale Information e

Communication Technology

(CERICT, Italy)

Contact: Massimiliano Rak

[email protected]

CA Technologies Development

Spain SAU (CA, Spain)

Contact: Victor Muntés

[email protected]

Montimage

(MI, France)

Contact: Edgardo Montes de Oca

edgardo.montesdeoca@montimage

.com

AIMES Grid Services

(AIMES, UK)

Contact: Prof Dennis Kehoe

[email protected]

Lufthansa Systems

(LHS, Germany)

Contact: Dirk Muthig

[email protected]

TTY-säätiö

(TUT, Finland)

Contact: José Luis Martínez Lastra

[email protected]

http://www.tecnalia.com/en

mailto:[email protected]









Table of contents

MUSA consortium .................................................................................................................................. 3 Table of contents ..................................................................................................................................... 4 List of figures .......................................................................................................................................... 5 List of tables ............................................................................................................................................ 6 Executive summary ................................................................................................................................. 7 1 Introduction ..................................................................................................................................... 8

1.1 Objective of this document .................................................................................................... 8 1.2 Structure of this document ..................................................................................................... 8 1.3 Relationships with other deliverables .................................................................................... 8

1.4 Contributors ........................................................................................................................... 9 1.5 Acronyms and abbreviations .................................................................................................. 9 1.6 Revision history ..................................................................................................................... 9

2 Overview of revisions and additions since D3.2 ........................................................................... 11 3 MUSA deployment requirements from WP1 ................................................................................ 12

3.1 Multi-cloud application deployment scenarios .................................................................... 14 3.2 Multi-cloud application redeployment scenarios ................................................................. 15

4 MUSA Deployer architecture ........................................................................................................ 16 4.1 Component model ................................................................................................................ 16

4.1.1 Deployer Core.................................................................................................................. 19 4.1.2 Deployer Planner ............................................................................................................. 21 4.1.3 Deployer Broker .............................................................................................................. 22

4.2 Data model ........................................................................................................................... 24 4.3 Collaboration model ............................................................................................................. 29 4.4 Interface specification .......................................................................................................... 33

4.4.1 Planning the deployment of a multi-cloud application .................................................... 33 4.4.2 Deploying/un-deploying a multi-cloud application ......................................................... 35

5 MUSA Deployer implementation.................................................................................................. 38 5.1 Prerequisites and installation ............................................................................................... 38

5.1.1 Deployer Planner installation .......................................................................................... 38 5.1.2 Deployer Broker installation ........................................................................................... 38

5.2 Usage guide .......................................................................................................................... 39 5.2.1 Deployer Planner usage .................................................................................................. 39 5.2.2 Deployer Broker usage .................................................................................................... 41

5.3 Source code repository ......................................................................................................... 42 6 Innovation in final secure multi-cloud deployment mechanisms and tools .................................. 43 7 Conclusion and further work ......................................................................................................... 44 References ............................................................................................................................................. 45 Appendix A. MUSA motivation and background ................................................................................. 47 Appendix B. MUSA Implementation plan schema ............................................................................... 48 Appendix C. MUSA Implementation plan example ............................................................................. 67


List of figures

Figure 1. MUSA Deployer architecture overview ................................................................................ 17 Figure 2. MUSA overall workflow ....................................................................................................... 19 Figure 3. MUSA Deployer Core component diagram ........................................................................... 20

Figure 4. MUSA Deployer Planner component diagram ...................................................................... 22 Figure 5. MUSA Deployer Broker component diagram ....................................................................... 24 Figure 6. Implementation plan overall structure ................................................................................... 25 Figure 7. Implementation plan’s csps and iaas elements example ........................................................ 25 Figure 8. Implementation plan’s paas element example ....................................................................... 27 Figure 9. Implementation plan’s pools element example ...................................................................... 28 Figure 10. Implementation plan’s component element example ........................................................... 29 Figure 11. MUSA Deployer sequence diagram for generating an Implementation plan ...................... 31 Figure 12. MUSA Deployer sequence diagram for deploying a multi-cloud application ..................... 32 Figure 13. Deployment planning - Deployer GUI ................................................................................. 40

Figure 14. Deployment Execution - Deployer GUI .............................................................................. 40


List of tables

Table 1. Overview of updates since D3.2.............................................................................................. 11 Table 2. Requirements for the MUSA Deployer and coverage ............................................................. 12 Table 3. Interface specification for planning the deployment of a multi-cloud application .................. 33

Table 4. Interface specification for deploying/un-deploying a multi-cloud application ....................... 35


Executive summary

This document is the technical specification report of the final mechanisms and tools that MUSA

offers to support deployment of multi-cloud applications. This report, together with the accompanying

software prototypes that implement the tools within MUSA Deployer, constitutes the deliverable D3.4

Final secure multi-cloud deployment mechanisms and tools of the MUSA Project.

In particular, the document focuses on the deployment planning and deployment execution phases of

the MUSA multi-cloud application life-cycle. The deployment planning involves the creation of the

deployment scripts for deploying multi-cloud application components, while deployment execution

refers to the cloud resources acquisition and initialization in the selected cloud providers, as well as

the installation of the multi-cloud application artefacts and/or MUSA agents in the corresponding

cloud resources.

First, the document identifies the requirements posed in WP1 Multi-Cloud security requirements and

MUSA Framework for the deployment support and describes the coverage of such requirements by the

final prototype of MUSA Deployer (Key Result KR4 of MUSA).

The document then describes in detail the final design of the MUSA Deployer and the final status of

its implementation and its integration with other tools in the MUSA Framework. The links to the

corresponding software prototypes are referred along the description.

The document includes in Appendix B the deployment Implementation plan schema adopted in

MUSA and in Appendix C an example Implementation plan from Case Study B – Smart Mobility

multi-cloud application in MUSA.

This final version of the prototype supersedes the initial version included in previous deliverable D3.2

Initial secure multi-cloud deployment mechanisms and tools and offers improvements addressing

initial evaluation feedback as well as additions to finalise the mechanisms and support the overall

application life-cycle with the redeployment mechanisms.

Please note that the state-of-the-art in multi-cloud deployment provided in deliverable D3.2 is not

repeated in this document.

It is important to note that the final version of the MUSA Dashboard for the integrated framework is

described in deliverable D1.4 Final MUSA framework specification and guide, which includes the

architectural specification of the integrated framework.


1 Introduction

1.1 Objective of this document

This document is the technical specification report included in deliverable entitled D3.4 Final secure

multi-cloud deployment mechanisms and tools of the MUSA Project.

The document provides a description of the final mechanisms and tools that MUSA offers to support

the distributed deployment of multi-cloud applications in heterogeneous cloud services.

Therefore, the main objective of this document is to describe the final prototype of the MUSA

Deployer tool. The document addresses the project Objective SO4, i.e. the provision of an automated

deployment environment that, based on an intelligent decision support system, will allow for the

dynamic distribution of multi-cloud application components across the combination of cloud resources

that best matches the optimum trade-off between functional and security requirements of the overall

application.

The document is accompanied by the actual implementation of the mechanisms in form of a software

prototype which is available as explained in Section 5.

1.2 Structure of this document

After this introductory section, the document is structured as follows:

• Section 2 provides an overview of the revisions and additions of this final version of the

MUSA Deployer deliverable compared to the previous version.

• Section 3 explains the MUSA project requirements on secure multi-cloud deployment and the

status of the requirements coverage by the final mechanisms and tool developed.

• Section 4 focuses on final MUSA Deployer tool architecture design description.

• Section 5 provides details on the final MUSA Deployer prototype implementation.

• Section 6 summarizes the main innovation brought by MUSA mechanisms and tools on multi-

cloud deployment.

• Section 7 concludes the document by summarising the contents of the document and the main

features and innovation in the MUSA Deployer.

• The Appendix A contextualizes the document by describing the MUSA motivation and

background.

• In the Appendix B we include the complete deployment Implementation plan schema adopted

in MUSA.

• Finally, the Appendix C illustrates the deployment Implementation plan format through an

example of the Implementation plan generated for the Case Study B of MUSA.

1.3 Relationships with other deliverables

This deliverable contains the final methods and tools for multi-cloud deployment developed in the

context of the MUSA project.

It assumes as an input the requirement analysis and the architecture defined in D1.4 Final MUSA

framework specification and guide and refines such results mainly with respect to the deployment

process step of MUSA workflow.

The description of the final methods and tools builds on top of the previous deliverable D3.2 Initial

secure multi-cloud deployment mechanisms and tools that is revised and completed in this document.

This document supersedes D3.2 because it extends the previous version to describe all the innovations

offered by the final MUSA Deployer. Nevertheless, please note that the state-of-the-art in multi-cloud

deployment provided in deliverable D3.2 did not change much and it is not repeated in this document.


With respect to the integration of the deployment implementation in the MUSA Framework, this

deliverable is also related to other two deliverables:

• D2.3 Final SbD methods for multi-cloud applications presents the SLA-based security-by-design

process in MUSA, including the Security SLA Template generation and the Security SLA

composition, which are previous steps before deployment phase and the Security SLAs are the

inputs to the MUSA Deployer.

• D2.4 Final MUSA IDE for security-aware design of multi-cloud applications, which includes the

implementation and description of the final version of the MUSA Integrated Development

Environment for multi-cloud application security-aware design, particularly the MUSA Modeller.

This is the initial step in MUSA to define the multi-cloud deployment requirements of the multi-

cloud application, which output is essential for the MUSA deployment step.

• D3.3 Final security based discovery and composition mechanisms and tools, which includes the

implementation and description of the final version of the cloud services discovery and match-

making processes supported by the Decision Support Tool (DST) in MUSA. These are previous

steps to multi-cloud deployment described in the present document.

• D4.3 Final security assurance mechanisms and tools, which describes the final version of the

security assurance process supported by the MUSA Security Assurance Platform in MUSA. This

is the following step to multi-cloud deployment.

1.4 Contributors

The following partners have mainly contributed to this deliverable:

• Tecnalia: multi-cloud application deployment model definition, alignment with overall

architecture and workflow (deliverables D1.4 and D1.5), and design and implementation of final

prototype of Deployer Planner.

• CERICT: multi-cloud application deployment scenarios, alignment with multi-cloud application

Security by Design mechanisms (WP2), as well as design and implementation of final prototype of

Deployer Broker with multiple CSPs.

1.5 Acronyms and abbreviations

API Application Programming Interface PaaS Platform-as-a-Service

CPIM Cloud Provider Independent Model SaaS Software-as-a-Service

CSP Cloud Service Provider SLA Service Level Agreement

DST Decision Support Tool SLO Service Level Objective

IaaS Infrastructure-as-a-Service VM Virtual Machine

1.6 Revision history

Version Date issued Author Organisation Description

0.1 03/10/2017 Erkuden Rios Tecnalia TOC and initial draft.

0.2 14/11/2017 Erkuden Rios &

Angel Rego

Tecnalia Intermediate version.

0.3 21/11/2017 Massimiliano

Rak &

Valentina

CERICT Broker description updated.


Version Date issued Author Organisation Description

Casola

0.3.1 22/11/2017 Eider Iturbe Tecnalia Sections 4.2 and 4.3 updated.

0.4 23/11/2017 Erkuden Rios Tecnalia Final version to review.

0.5 27/11/2017 Valentina

Casola

CERICT Reviewed version.

0.6 28/11/2017 Erkuden Rios Tecnalia Revised after CERICT review.

0.6.1 29/11/2017 Wissam

Mallouli

MI Reviewed version.

0.8 30/11/2017 Erkuden Rios Tecnalia Final revised.

1.0 30/11/2017 Erkuden Rios Tecnalia Final release.


2 Overview of revisions and additions since D3.2

In this section, we provide the summary of the updates and additions included in this document, the

final MUSA Deployer description, compared to the description of the initial version (deliverable D3.2

Initial secure multi-cloud deployment mechanisms and tools). Please note that the state-of-the-art in

multi-cloud deployment provided in deliverable D3.2 (Section 2) is not changed and not repeated in

this document.

Table 1. Overview of updates since D3.2

Change Section in

D3.2

Section in

D3.4

Rationale

Updates in the coverage of

requirements.

Section 3 Section 3 Updates in Final version of prototype

compared to Initial version.

Minor changes in high level

architecture.

Section 4.1 Section 4.1 Minor updates in high level architecture

description.

Changes in data model. Section 4.2 Section 4.2 Data model of final version described.

Changes in collaboration

model.

Section 4.3 Section 4.3 Collaboration model of final version

described.

Changes in prototype

interfaces.

Section 4.4 Section 4.4 Interfaces of final version described.

Changes to describe final

prototype usage.

Section 5 Section 5 Final implementation user manual and

pre-requisites described.

Changes in innovations of

the deployment

mechanisms and tools

Section 6 Section 6 All the innovations offered by the final

version of the deployment tool

prototype are summarised.


3 MUSA deployment requirements from WP1

As described in deliverable D1.1, MUSA Framework requirements were derived through the analysis

of relevant usage scenarios envisaged for the framework. Next table shows the requirements

corresponding to the Key Result KR4, that is the MUSA Deployer, and summarizes the main required

functionalities and how they have been addressed in the final prototype of the tool.

Table 2. Requirements for the MUSA Deployer and coverage

ReqID Title Description Prio

rity

Coverage status in final

prototype

S1.3-R2 Deployment

tool

The MUSA Framework should

provide a tool to support the

configuration of the

deployment script of

distributed parts of the multi-

cloud application.

1 The final prototype of

MUSA Deployer includes a

planner component that

allows the specification of

the deployment configuration

(implementation plan) of the

multi-cloud application

components in distributed

cloud services, and a Broker

to effectively execute such

implementation plan.

S1.3-R3 Integrated

representatio

n of security

properties in

design and

operation


provide the mapping between

design phase representation of

security properties over a

multi-cloud application and

operation phase representation.


MUSA Deployer is able to

create the deployment

Implementation plan that

details the deployment

scenario by enriching the

information from: a) the


CPIM model (created by

using the MUSA IDE

Modeller) and b) its SLA

(created by using MUSA

SLA Generator) defined at

design time, and therefore

the alignment between both

phases is ensured.

S4.2-R4 Redeployme

nt capability


provide a tool to support the

reconfiguration of the

deployment script of

distributed application

components.


MUSA Deployer supports

the edition of the

implementation plan through

a GUI. This way, the

DevOps Team is able to

update the plan in case of

reconfigurations are needed.

S4.2-R6 Redeployme

nt decision

model


provide a Redeployment

decision model that describes

when a Redeployment is

needed.


MUSA Deployer supports

redeployments.

Redeployment of application

component(s) in MUSA is a

process performed as part of

a reaction measure


recommended by the MUSA

Security Assurance Platform

(see D4.4). In all cases the

redeployment is executed

after the necessary changes

are done in the design phase

(Modelling, Risk Assessment

and/or Cloud Service

Selection).

S5.4-R3 Cloud setting

type -

Deployment


support application developer

in deploying the multi-cloud

application in the type of cloud

setting specified.

3 The MUSA Deployer can

deploy components in

hybrid, public, private and

community clouds. The

minimum requirement is that

the access credentials to

access the Cloud Service are

known by the Deployer

Broker component. Currently

the prototype is able to

deploy in Eucalyptus,

Openstack and Amazon

services.

S6.2-R2 Deployment

scripts

The MUSA Framework

creates the necessary scripts to

invoke the deployment tool for

the chosen security

configuration. (They may be

created partially and

completed by the system

operator afterwards.)

1 The Deployer Planner

component of the final

prototype of MUSA

Deployer creates in a semi-

automatic way the

specification of the

deployment configuration

(Implementation plan) of the


components. The

Implementation plan is

automatically created first

and then can be manually

edited by the DevOps Team

in order to include some

deployment specifics of the

particular organization and

network (e.g. firewall rules,

VPN configuration, etc.)

S6.3-R2 Redeploy

application (-

components)

The MUSA Framework

provides functionality to

invoke the deployment tool for

the changed configuration and

redeploys necessary

application (-components).

1 The final prototype of the

MUSA Deployer allows the

application components to be

redeployed. When the

redeployment implies the

replacement of one or more

Cloud Services, a new

discovery and selection of

Cloud Services would be

needed and the Decision

Support Tool in the MUSA

Framework should also be

part in the redeployment


process prior to the use of the

MUSA Deployer.

S7.1-R1 Distributed

multi-cloud

deployment

The MUSA Framework is able

to deploy the application

components in a specified

distributed set of services that

satisfies communication and

security requirements.

1 The final prototype of the

MUSA Deployer achieves

this requirement by acquiring

cloud services from different

cloud service providers and

deploying the components on

them. The final MUSA

Deployer also sets all

security rules so the

communication between the

components is secure.

As it can be seen in the table, the considered requirements refer to the following aspects: (i) the

specification of the deployment configuration, (ii) the deployment execution itself, (iii) the

deployment re-configuration and (iv) the redeployment model.

As explained in the coverage column, the MUSA Deployer final prototype addresses the support to all

these aspects. In particular, the specification of deployment configuration is done by generating

automatically the deployment Implementation plan from the application CPIM and the deployment

execution consists in executing the plan. Therefore, deployment (re-)configuration features and the

deployment execution features are provided in two different components, the Deployer Planner and

the Deployer Broker respectively, that will be explained later.

The final prototype offers re-configuration and redeployment mechanisms. Both re-configuration and

redeployment imply modifying the Implementation plan, but before and after to deployment

execution, respectively. A re-configuration is possible by automatically generating a new

Implementation plan when a new iteration of the MUSA workflow is performed (from a new CPIM or

when a new Cloud service selection is made). A redeployment is possible by executing a new

Implementation plan, which will usually be needed after a new iteration of the MUSA workflow is

performed too. The initial step of the redeployment is the undeployment of all the resources deployed

in the old Implementation plan.

3.1 Multi-cloud application deployment scenarios

In parallel to the work in WP1, in the Case studies of MUSA project we have identified four different

deployment scenarios, which represent possible deployment and usage configurations for the multi-

cloud application components (See deliverable D2.1 for more details):

• All application components are deployed in different IaaS resources belonging to a single

Cloud Service Provider (CSP) and one component uses SaaS services offered by different

CSPs. In this scenario, all the multi-cloud application components are deployed on a single

virtual machine offered by an IaaS CSP, while multiple SaaS providers are used to acquire

the services needed by one of the components.

• The multi-cloud application components are distributed among multiple IaaS resources

belonging to different CSPs (i.e. virtual machines acquired from different IaaS CSPs), and no

SaaS services are involved.

• The multi-cloud application components are distributed on a PaaS created configuring

multiple IaaS resources belonging to a single CSP or different CSPs (i.e. virtual machines

acquired from different IaaS CSPs). The PaaS is managed using the Docker Swarm mode,

that creates an overlay network through which all components can communicate each other,

even if they are physically installed on different VMs.


• The multi-cloud application uses multiple IaaS CSPs to host its components and relies upon

SaaS services offered by multiple CSPs.

The deployment tools in MUSA were designed to be able to support the types of deployments above

from the project case studies.

3.2 Multi-cloud application redeployment scenarios

As identified in Table 2 above, the MUSA multi-cloud deployment mechanisms need to support

redeployment.

The most common cases for requiring a redeployment is when the Implementation plan contains a

mistake or when a failure happens during the deployment (e.g. an issue with the Internet connection).

Other situations include the need of deploying the multi-cloud application components in different

cloud services. For example, in case the bad security performance of a selected cloud service causes a

violation of a security service level objective stated in the multi-cloud application SLA, the DevOps

Team may need to replace the failing cloud service with some “equivalent” service that can provide

similar functionality and security properties. In general, a redeployment process is needed in all those

cases when changes in the cloud providers SLAs affect the multi-cloud application SLA fulfilment.

Note that in MUSA, the redeployment of a multi-cloud application component in a different location

of the same Cloud Service Provider is considered a redeployment in a different Cloud Service, as the

location is one of the attributes that characterize the Cloud Services.

The security assurance services at runtime (developed in WP4) monitor the fulfilment of the multi-

cloud application Security SLA and trigger new redeployments by using notification services. The

main challenge of redeployment resides in minimizing its impact on the maintenance of functional and

security parameters of the multi-cloud application while it is being executed.

In MUSA, redeployment is not a fully automated process as it requires that the DevOps Team uses the

Cloud Services selection Decision Support Tool (see deliverable D3.3) in order to look for a new

Cloud Services combination to use for one or more multi-cloud application components (for example,

at least for the component that used the failing cloud service). This is needed in order to make sure the

new Cloud Services combination with the Cloud Service replacement still holds the multi-cloud

application security requirements. The Cloud Services selection is not an automated decision in

MUSA as it involves the balancing of a multitude of factors on the Cloud Service offers, and requires

consensus of different points of view of the diverse roles in the DevOps Team (Security Architect,

Service Business Manager, System Administrator, etc.).

Another big challenge of redeployment is the ability for migration (physical relocation) not only of the

application components (VMs) but also their data from one environment to another while keeping

access to the data. The data migration is not the focus of MUSA and MUSA redeployment mechanism

relies on DevOps Team, MUSA Deployer users, to decide on when execute the redeployment so as

first they have agreed on a data migration mechanism and executed it.


4 MUSA Deployer architecture

In this section we describe the automated deployment module, named MUSA Deployer, which has

been developed in MUSA project on top of existing open source tools, as explained in next section.

The MUSA Framework offers a distributed deployment service based on the selection of the cloud

service providers that best match with the application security requirements obtained in the risk

analysis. This includes support to:

• Cloud services categorization based on security properties offered and extracted from self-

assessment information by cloud service providers. This feature is included in the MUSA

Decision Support Tool - Decision (KR3). See deliverable D3.3 Final security based discovery

and composition for more information.

• Selection of the cloud resources which combination is compliant with the security

requirements obtained from the multi-cloud application risk assessment process. The decision

support tool includes intelligent rules to present to the DevOps Team options of candidate

combinations of cloud services which SLAs best match with the application component

requirements. This feature is included in the MUSA Decision Support Tool - Decision (KR3).

See deliverable D3.3 Final security based discovery and composition for more information.

• Automated deployment of the multi-cloud application, distributing each of the application

components’ packages (artefacts) in the matched cloud service. This feature is included in the

MUSA Deployer (KR4) described herein and involves a number of operations grouped in two

logical components, as explained below.

Therefore, the MUSA Deployer (KR4) is the main responsible for the automated deployment of the

multi-cloud applications and it mainly performs the following operations:

• Prepare and implement the Implementation plan:

The Deployer must be able to prepare and configure the deployment plan, named

“Implementation plan”, on the basis of the application architecture and description, the SLA

and the service selection, by orchestrating the acquisition of the needed resources, their

configuration and the activation of involved services.

• Acquire resources:

The Deployer must be able to acquire all the resources needed, based on the Implementation

plan created.

• Deploy and configure:

The Deployer must be able to deploy and configure all the resources according to what has

been specified in the Implementation plan.

• Start cloud services:

The Deployer must be able to properly start the needed cloud services on top of the acquired

resources, in order to execute the Implementation plan.

4.1 Component model

The operations explained in the previous section are offered by three different architectural

components:

• Core component: it is responsible for invoking the other two components the Deployer

Planner and the Deployer Broker when needed. This component is the one that exposes the

REST API interface and is in charge of the persistence of the created files.

• Planner component: it collects information about the multi-cloud application and generates a

deployment Implementation plan according to it. The multi-cloud application information

includes: (i) the CPIM (Cloud Provider Independent Model) coded in MUSA-extended


CAMEL format that represents multi-cloud components deployment specifics (including

MUSA security components), (ii) the Service Level Agreements (SLAs) of the multi-cloud

application components, which include information about the selected cloud services for

deploying the multi-cloud application components.

• Broker component: Once the Implementation plan is completed, the broker component

deploys and configures the different cloud components of the plan into the appropriate cloud

providers.

Figure 1 illustrates a high level overview of the full architecture.

Figure 1. MUSA Deployer architecture overview

The MUSA Deployer Core is the one exposing the REST API of the tool and in charge of invoking the

Planner and Broker components explained below. The invocation of these tools is performed via Java

API.

The Planner component is in charge of building the Implementation plan. It takes as input the

following items:

1. the application formal description which is the CPIM in MUSA-extended CAMEL format.

This input is retrieved by invoking a REST API offered by the MUSA Modeller (see

deliverable D2.4 Final MUSA IDE for security-aware design of multi-cloud applications).

2. the Security Service Level Agreements, which are retrieved from the MUSA SLA Repository

by invoking a REST API. The SLAs of the multi-cloud application already includes the data

about the selected cloud services by the DevOps Team though the Decision Support Tool

(DST) usage.

Then the Planner generates the Implementation plan. This Implementation plan can be reviewed and

optionally updated by the DevOps Team though the MUSA Framework Dashboard in those cases that

is necessary to include information that was not specified in the CPIM.

Once the plan is completed, the Deployer Core invokes the MUSA SLA Generator in order to trigger

the generation of the Composite Security SLA of the multi-cloud application.

Afterwards, the Broker component is invoked by the Deployer Core, which is invoked by the DevOps

Team, in order to actually execute the plan. When the deployment is completed, the MUSA Security


Assurance Platform will be informed by the Deployer Core about the components of the multi-cloud

application that have been deployed, so the MUSA Security Assurance Platform can start monitoring

the multi-cloud application components.

All calls between MUSA tools will be performed by invoking the REST APIs published by the

corresponding MUSA tools.

The Broker component is in charge of deploying the application components on the different selected

CSP. It takes as input the Implementation plan and, according to the plan, it acquires resources and

deploys the software components, not only components of the application but also the specified

MUSA security enforcement agents. As explained later, the Broker implementation relies on the well-

known open source Chef technology [34] and SPECS European Project’s [34] deployment support

tool by CERICT, which is open source too.

The output of the MUSA Deployer is the multi-cloud application components deployed and running in

the multi-cloud environment.

Figure 2 shows the MUSA overall workflow and the how the MUSA Deployer fits in it.

During the first phase Modellig, the DevOps Team models the application describing the constituent

components together with their high-level requirements. This phase is supported by the MUSA

Modeller tool and it relies on a specific application modeling language (MUSA extended CAMEL see

deliverable D2.4 Final MUSA IDE for security-aware design of multi-cloud applications), which

allows describing, at a high-level of abstraction, both the application architecture and the deployment

requirements, independently of the specific providers that will be actually used by the components.

The created model is therefore a Cloud Provider Independent Model (CPIM) of the multi-cloud

application which will be the basis for the deployment later.

The next phase is the Risk Assessment phase, where the DevOps Team uses the MUSA Risk

Assessment tool to carry out an early risk assessment process in order to identify the security

requirements of the multi-cloud application in form of the security controls and the security Service

Level Objectives (SLOs) required by the application components [34][36]. The risk assessment is

done by considering one by one the threats against each of the components, evaluating their potential

impact and specifying the desired countermeasures (security controls) to minimize the risks.

The subsequent Cloud Service Selection phase entails the selection of the cloud services to be used to

implement and deploy the application components. This step is supported by the MUSA Decision

Support Tool (DST), which is aids the DevOps Team in identifying the cloud services that best match

the requirements specified in the Risk assessment phase.

Once the security requirements of the application are defined and the actual cloud services to use are

selected, the DevOps Team can generate the Composite Security Service Level Agreement (SLA) of

the multi-cloud application by means of the MUSA SLA Generator tool SLA Generation phase (refer

to deliverable D2.3 Final SbD methods for multi-cloud applications for the complete description of the

SLA Generation process).

The generated Composite Security SLA will include the security guarantees associated with the multi-

cloud application. It is built by properly combining the Security SLA templates of the application

components and the Security SLAs published by involved cloud service providers, by taking into

account the relationships among the components and the underlying cloud services and the impact that

they may have on involved security controls. In case any security requirement in the components'

Security SLA templates cannot be satisfied in the Composite Security SLA, a new cloud services

selection iteration may be required, a new risk profile may be needed (for example, by relaxing the

unsatisfied requirement), or even a new re-design of the multi-cloud application may be the solution

(for example, by adding a MUSA enforcement agent - security mechanism, or by adding, replacing or

updating components).


In the Deployment phase, focus of the present deliverable, the MUSA Deployer is used by the DevOps

Team to both automatically create the deployment plan and effectively deploy the multi-cloud

application components by following the deployment plan.

The Deployment phase is therefore split into two sub-phases, namely Deployment planning and

Deployment execution. In the Deployment planning sub-phase, the deployment plan is generated, the

so-called Implementation plan, which includes the low-level information needed to acquire the cloud

services selected in the Cloud Service Selection phase, and to configure them in order to run the

application components.

In this phase, the components’ Security SLAs, stored in the SLA Repository, will be retrieved by the

MUSA Deployer via REST API, so it can generate the Implementation plan for the multi-cloud

application. The MUSA Deployer also needs the CPIM which will be retrieved via REST API from

the MUSA Modeller. The Deployer automatically generates the Implementation plan corresponding to

the CPIM so as the DevOps Team can deploy the multi-cloud application (by following the

Implementation plan).

The actual deployment in Deployment execution sub-phase involves the acquisition and configuration

of the cloud services as well as the installation of the application components’ software artefacts to

guarantee the created Composite Security SLA.

Finally, once all the application components are up and running, the security SLA of the application

will be continuously monitored in the Continuous Assurance phase. The MUSA Security Assurance

Platform starts monitoring it based on the final Composite Security SLA and on the deployment plan.

Whenever any violation of the security SLA is detected, a notification is sent to the DevOps Team and

the appropriate reactions are launched, such as the activation of an enforcement agent (a security

mechanism offered by MUSA Framework), the replacement of a failing cloud service or even a re-

design iteration of the multi-cloud application.

Figure 2. MUSA overall workflow

The final MUSA Deployer architecture is composed of the three modules explained below.

4.1.1 Deployer Core

4.1.1.1 Overview

The Deployer Core is the main component of the Deployer, in charge of invoking the other two

components the Deployer Planner and the Deployer Broker when needed. This component is the one

that exposes the REST API interface and is in charge of the persistence of the created files.


4.1.1.2 Component diagram

As it can be seen in next figure, the Deployer Core is mainly composed of four sub-components:

1. Deployer Core – REST: It manages the REST request capturing and response mechanism.

For that purpose, it publishes a REST API which is described in detail in Section 4.4. This

REST API is used by the MUSA Dashboard in order to invoke the MUSA Deployer for two

main purposes: (i) building the Implementation plan of a multi-cloud application, and (ii)

deploying all components that are part of the multi-cloud application. This last operation

includes acquiring cloud resources, deploying multi-cloud application components and

starting the cloud services and the multi-cloud application.

2. Deployer Core – Engine: According to the operation ordered to the MUSA Deployer though

the Deployer REST API, this subcomponent controls the invocation of both the MUSA

Planner and the MUSA Broker. In addition, this subcomponent also invokes the SLA

Generator in order to trigger the generation of the Composite Security SLA of the multi-cloud

application once the Implementation plan is completed. And it will also invoke the MUSA

Security Assurance Platform to inform that the application is deployed and is in execution, so

the MUSA Security Assurance Platform can start monitoring it.

3. Deployer Core – Persistence: It is in charge of storing the output results from the execution

of operations explained before. In case that the building of an Implementation plan is

requested, the output item is the Implementation plan itself (the data model is described in

Section 4.2). In case that deploying of a multi-cloud application is requested, the generated

output item is a deployment report that includes log traces about the execution of the

deployment.

4. Deployer – Database: It is the database used by the MUSA Deployer, specifically by the

Deployer Core – Persistence subcomponent, in order to store all output data generated by the

MUSA Deployer operations. The first version of this sub-component is a file system based

database, which will be improved for the last version of the MUSA Deployer at the end of the

project.

Figure 3. MUSA Deployer Core component diagram


4.1.2 Deployer Planner

4.1.2.1 Overview

The Deployer Planner component is the responsible for the creation of the needed multi-cloud

deployment configuration information aligned with: i) the application cloud requirements specified in

the application architecture model, i.e. the MUSA-extended CAMEL model representing the Cloud

Provider Independent Model (CPIM), ii) the security requirements stated in the application Security

SLAs that include the selected cloud service combination to use decided by the DevOps Team.

The Deployer Planner therefore requires two inputs: i) the application CPIM from MUSA IDE

Modeller, ii) the Security SLAs of the application components from the MUSA SLA Generator. The

SLAs already include the decision result from the MUSA DST-Decision on which cloud service will

be used for deploying (or in the case the service is PaaS or SaaS, to be used by) each of the application

components.

The output generated by the Deployer Planner is the deployment Implementation plan that describes

the detailed instructions for the deployment in selected cloud services.

The creation of the Implementation plan is done in two steps.

First, the Deployer Planner produces an initial Implementation plan by parsing and processing the

information in the application CPIM and the application components’ SLAs. This Implementation

plan is shown by the MUSA Framework Dashboard to the DevOps Team in order they can review it

and if necessary complete it with the inter-component network configuration settings, specification of

the location of the multi-cloud application components’ artefacts, and other details that were not

included in the CPIM. The MUSA Deployer through the MUSA Dashboard gives support to the

edition of the Implementation plan by checking the correct syntax of the updates and rising error

messages when mistakes are made.

Once the Implementation plan is completed, it is sent back to the MUSA Deployer for its execution.

The Implementation plan’s reference model adopted in MUSA was originally defined in the context of

the SPECS European Project [35] and some of the fields of the original structure are no longer

relevant and will be simply ignored and not used. Besides, additional fields have been included in

order to address the deployment needs in MUSA such as the inclusion of MUSA agents and the

support for PaaS. Please refer to Section 4.2 for more details on the Implementation plan structure and

contents.

Please refer to Appendix C for an example of Implementation plan created for the Case study B in

MUSA, the Tampere Smart Mobility application. And please refer to deliverable D5.4 Final MUSA

case studies implementation for a complete description of the application.


As shown in the figure below, the Deployer Planner is the one that includes all the necessary parsers

and processing actions for creating the Implementation plan. The subcomponents include:

• the Planner subcomponent is in charge of the creation of the Implementation plan itself and

invoking the rest of the parsers. In addition, it invokes the different MUSA components in

order to retrieve the required inputs for the creation of the Implementation plan; i.e.:

o It invokes the MUSA Modeller in order to retrieve the CPIM associated with a multi-

cloud application in camel format.

o It invokes the SLA Repository in order to retrieve the SLAs associated with a multi-

cloud application.

• the MUSA-extended CAMEL parser for the multi-cloud application CPIM,

• the SLA parser for the SLA of the multi-cloud application components.


Figure 4. MUSA Deployer Planner component diagram

4.1.3 Deployer Broker

4.1.3.1 Overview

The Deployer Broker component has been developed to handle the whole process of acquiring and

configuring cloud resources on one or more external Cloud Service Providers (CSPs). The Deployer

Broker accepts as an input the Implementation plan, which contains both the description of the

services to acquire (e.g. virtual machines) and CSPs. At state of the art, the Deployer Broker supports

different technologies (e.g. Openstack, Amazon AWS EC2) and was tested against different CSPs

(Amazon, private and public Openstack and eucalyptus instances, etc.)

For what regard compute services (e.g. virtual machines and /or pool of virtual machines) it is possible

to define in detail the system requirements, i.e., the operating system to install, the CPU type and the

Ram size and the location. Once the services have been acquired it is possible to configure each of

them through a Configuration Management tool (e.g. Chef). According to such an approach, the multi-

cloud application components can be automatically deployed and configured on the services acquired

in cloud.

As anticipated, the Configuration Management tool is Chef, which relies on a client-server model. The

Chef Server is the centralized store for configuration data in the infrastructure. It stores and indexes

cookbooks, environments, templates, metadata, files and distribution policies. The Chef Server is

aware of all the machines it manages, and in this way, it also acts as an inventory management system.

Each generic node to configure needs to host a Chef Client.

The node that hosts the Chef Client, also called Chef Node, contains a chef-client agent (i.e., an agent

that runs locally on every node, and it is managed by Chef) and performs various automation tasks.

The nodes use the chef-client to ask the Chef Server for configurations (recipes, templates), and the

chef-client then makes the configuration work on the nodes.

The Chef Workstation is the latest element in the Chef architecture: it uploads the “configurations” on

the Chef Server: The administrator uses the workstation in order to control the Chef Server. In

particular, it is possible to author cookbooks and recipes, to define policy data (i.e., recipes,

cookbooks), to synchronize with the chef-repo (the location in which the cookbooks, recipes, etc., are

stored) and to upload data in the Chef Server.

It is worth noticing that the Deployer Broker automates the role of the chef workstation, so, the main

functionalities it provides are:


(i) enable the access of an external CSPs and its usage,

(ii) acquire or delete a cluster of VMs on one of the enabled external CSPs and

(iii) execute scripts (or more in general install services) on a cluster of VMs.

In summary, the Provision and Deploy step in Figure 12 (sequence diagram) involves mainly:

• Acquiring the needed VMs

• Registering the VMs in the Chef Server.

• Configure network and firewall rules

• Deploy the components software artefacts in the provisioned VMs.

• Undeploy (if required).

In order to support the deployment scenario that allows to distribute components on a PaaS, the

Implementation plan needs a section that defines the way the PaaS has to be setup, and that contains

all the components that have to be deployed on the PaaS. The final prototype of Deployer Broker

supports the PaaS creation using the Docker Swarm mode.

The Implementation plan is also necessary in order to perform a modification of the deployment (i.e.

the user wants to remove a VM or want to acquire resources on another CSP). The final version of the

Deployer Broker allows performing the redeployment phase, which consists in terminating all the

resources previously acquired and acquiring all the resources reported in the new Implementation plan.

It is worth noticing that the redeployment does not acquire only the differences between the initial plan

and the new one, but acquires all resources from scratch. An incremental adaptation of the plan was

left for future version of the Broker after MUSA project, because it needs an explicit support even

from the cloud application to be redeployed, which is not the case for the MUSA case studies.

Moreover, in order to correctly manage the transition from the old plan to the new one, the broker first

tries to acquire and configure all the resources on top of the CSPs defined in the Implementation plan

and only when the acquisition and configuration phase is done properly (i.e. the resources acquired

and configured) the old resources are terminated and removed from the CSPs and from the Chef

Server (undeploy phase).


In order to meet all requirements related to the deployment of Cloud Resource, the Deployer Broker

component has seen designed with three main components that interact to complete the deployment

tasks, in particular:

• Orchestrator: represents the entry point through which it is possible to acquire and configure

CSPs’ resources through the orchestration of the other two components;

• Cloud Resources Provisioner: acquires and manages external CSPs’ resources;

• Configuration Manager: configures the acquired resources through the adoption of the Chef

Server component.

Note that the Chef Server component is used by the Configuration Manager and invoked through a set

of dedicated APIs offered by Chef.

In order to execute its tasks, the Deployer Broker needs specific inputs that come from the Planner

component: in particular, it is mandatory to provide the Implementation plan that is a JSON file

representing all the resources that have to be acquired and configured. The data model of the

Implementation plan is explained in Section 4.2. In addition, the MUSA DevOps Team needs to

provide the credentials to access the acquired CSP.


Figure 5. MUSA Deployer Broker component diagram

Since the Deployer Broker component is used to acquire and configure resources from a CSP, it has

been developed as a library, so anyone can import and use it.

The Broker API allows uploading an Implementation plan, update/delete an Implementation plan,

specify one or two formats for acquiring resources from Cloud Service Providers.

4.2 Data model

This section describes the structure of the Implementation plan, which contains the data required by

the MUSA Deployer in order to be able to deploy the components part of a multi-cloud application,

including the security agents.

The Implementation plan is used as input by the MUSA Broker in order to execute the deployment

operations; i.e., acquire cloud services, configure networks, deploy all multi-cloud application

components throughout different heterogeneous cloud services (acquired beforehand) and start all the

cloud services and the application. The Implementation plan is generated by the MUSA Deployer

Planner.

Therefore, the Implementation plan is aimed to automate the acquisition of cloud resources from a set

of Cloud Service Providers and the deployment and configuration, on such resources, of the software

components needed to implement a multi-cloud application.

Since the Implementation plan is represented in JSON format, the data model of the Implementation

plan is formalized by following the IETF specification JSON Schema: A Media Type for Describing

JSON Documents [37] in Appendix B.

The Implementation plan schema adopted in MUSA has been originally defined in the context of the

SPECS European project. That schema has been updated and optimised for MUSA in order to support

the deployment into multiple cloud providers. The MUSA Implementation plan also has been

extended in order to support the deployment of the multi-cloud components over PaaS layer, which is

provided by MUSA by using Docker Swarm technology.

The main elements of the Implementation plan are explained below.

The relevant elements of an Implementation plan are (see Figure 6):

• plan_id: The unique identifier of the multi-cloud application to which the plan is associated.

• sla_id: The unique identifier of the multi-cloud application to which the plan is associated.

• creation_time: The timestamp at the time of the creation of the Implementation plan.

• csps: An array of Cloud Service Providers to acquire cloud resources (i.e., Virtual Machines)

from and where the multi-cloud application components will be deployed; this field is more

explained below.


Next fields are not used in this version of the MUSA Deployer: slos, measurements and annotations.

Figure 6. Implementation plan overall structure

Each element on the array csps includes two sub elements:

• iaas: It contains the information about the IaaS provider used during the deployment.

• paas: It contains the information about the cluster of containers required for the deployment.

This cluster of containers is deployed and managed by the MUSA Deployer using Docker

Swarm technology. This element is included in the Implementation Plan in case the PaaS

feature is required by the DevOps Team; it is optional for the deployment.

• pools: It represents a logical set of cloud resources to acquire.

The IaaS providers supported by MUSA are the following: AIMES, AWS and the clusters from

University of Sannio and from a Rumanian cluster of West University of Timisoara (maintained by the

IeAT research center). Note that every CSP that uses OpenStack and/or an AWS-like interface can be

supported with a minimal effort.

Figure 7. Implementation plan’s csps and iaas elements example

The iaas element is structured as follows:

• provider: It contains the identifier that represents the IaaS provider.

• zone: It indicates the region in which the cloud resources have to be acquired.

• user: It indicates the account that can be used to log-in into the IaaS provider in order to

acquire cloud services.

• network: It represents the network identifier from the cloud service provider used to connect

the different VMs.


The paas element is structured as follows:

• paasAgent: It identifies the type of paas service required by the DevOps Team. The MUSA

Deployer supports one type of paas called docker and it provides the management of cluster of

containers with Docker swarm.

• allocationStrategy: It indicates the allocation strategy of the containers on top of the acquired

VMs for resource optimization (e.g. automatically scheduling container workloads). It

supports the following four values:

o spread: balance containers across the VMs in a pool based on the available CPU and

RAM of the VMs.

o binpak: schedule containers to fully use each VM capacity. Once the full VM capacity

has been used, the container moves on to the next one in the pool.

o random: choose a VM randomly.

o custom: the user defines the specific VMs in which the containers should run.

• components: It indicates the list of components that will be deployed in the layer of paas

provided by MUSA, following previously defined allocation strategy. Each component in the

list is structured as follows:

o vm_id: It identifies the VM in which the component will be deployed by the Docker

swarm. This indication only is possible when the allocation strategy is custom.

o component_id: It is an explanatory name of the component.

o cookbook: It is the name of the considered Chef cookbook, stored inside the chef-

server.

o recipe: It represents the name of the recipe for the component’s installation and

configuration, stored inside the above cookbook.

o implementation_step: It represents the global ordering used for component

installation. All the components with the same implementation_step will be installed

in parallel.

o acquire_public_ip: It indicates whether a public IP needs to be acquired for the

component.

o firewall: It contains all the information useful to configure the security group; its

details are described below.

o private_ips: The private IPs assigned to the component. It is automatically filled by

the MUSA Deployer.


Figure 8. Implementation plan’s paas element example

The pools element is structured as follows:

• pool_seq_num: It represents the order of acquisition of the pools.

• vms:

o vm_id: It represents the identifier of the VM.

o vm_seq_num: It represents the order of acquisition of the VMs in the list.

o appliance: It indicates the identifier of the image that has to be used as Operating

System of the VM.

o hardware: It represents the hardware type of the VM.

o public_ip: It represents the public IP assigned to the VM; it is automatically filled by

the MUSA Deployer.

o components: It defines the list of components that have to be configured on the current

VM. A component can be considered as a “service”. For each component, the

following information must be specified:

▪ component_id: It is an explanatory name of the component.

▪ cookbook: It is the name of the considered Chef cookbook, stored inside the

chef-server.

▪ recipe: It represents the name of the recipe for the component’s installation

and configuration, stored inside the above cookbook.


▪ implementation_step: It represents the global ordering used for component

installation. All the components with the same implementation_step will be

installed in parallel.

▪ acquire_public_ip: It indicates whether a public IP needs to be acquired for

the component.

▪ firewall: It contains all the information useful to configure the security group;

its details are described below.

▪ private_ips: The private IPs assigned to the component. It is automatically

filled by the MUSA Deployer.

Figure 9. Implementation plan’s pools element example


Figure 10. Implementation plan’s component element example

The firewall element contains the following sub elements as well:

• incoming: It contains all the incoming rules that have to be set in the security group;

o proto: It contains the network protocol. Note that, at the moment, all the rules are

always associated to TCP.

o port_list: It is the list of ports that have to be opened in the security group.

• outcoming: The same structure as incoming element.

The sub elements interface is internally used by the MUSA Deployer Broker.

The complete schema of the Implementation plan is included in Appendix B.

4.3 Collaboration model

The collaboration models shown below describe the two main operations performed by the MUSA

Deployer:

1. building the Implementation plan of a multi-cloud application,

2. deploying all components that are part of the multi-cloud application.

Figure 11 shows the process followed by the MUSA Framework, including the MUSA Deployer and

the rest of the MUSA tools, to generate an Implementation plan for the deployment of a multi-cloud

application. First, the DevOps Team triggers the generation of the Implementation plan for a multi-

cloud application through the MUSA Dashboard (more explanation about the MUSA Dashboard is

available in deliverable D1.5 Final MUSA framework implementation). Then, the MUSA Dashboard

calls the MUSA Deployer Core via REST API and this component calls the MUSA Deployer Planner,

since the MUSA Deployer Planner is responsible for handling the requests related with

Implementation plans. For the generation of the Implementation plan, the MUSA Deployer Planner

needs two inputs: (i) the CPIM of the multi-cloud application from the MUSA Modeller, and (ii) the


SLAs of the multi-cloud application from the SLA Repository. Once these two inputs are retrieved,

the MUSA Deployer Planner processes them and generates the Implementation plan, which is sent to

the MUSA Deployer Core to store it in the repository and send it the MUSA Deployer front-end, so

this tool can show it to the DevOps Team.

Figure 12 shows the process followed by the MUSA Framework to deploy a multi-cloud application

by following the Implementation plan previously generated. This process is also started by the

DevOps Team through the MUSA Dashboard. The MUSA Dashboard calls the MUSA Deployer Core

to start the deployment. Afterwards, the MUSA Deployer Core retrieves the Implementation plan

associated with the multi-cloud application and sends it to the MUSA Deployer Broker. The MUSA

Deployer Broker then starts provisioning cloud resources and deploying the components part of the

multi-cloud application (all this is well defined in the Implementation plan). During the deployment

process, the MUSA Deployer Broker sends log traces back to the MUSA Deployer Core, which

creates a deployment reports by using the deployment log traces. Finally, the deployment report can be

checked by the DevOps Team through the MUSA Deployer front-end.

Note that the redeployment process is very similar to deployment but considering that the cloud

infrastructure to use may be different and may need to be terminated previously.


Figure 11. MUSA Deployer sequence diagram for generating an Implementation plan


Figure 12. MUSA Deployer sequence diagram for deploying a multi-cloud application


4.4 Interface specification

The REST API interface provided by the MUSA Deployer allows creating Implementation plans and

executing real deployments and un-deployments.

The MUSA Framework Dashboard includes a security mechanism that controls that only authorised

users can execute deployment operations. Please refer to deliverable D1.4 Final MUSA framework

specification and guide for details of the Identity management and authorisation control in MUSA

Framework.

4.4.1 Planning the deployment of a multi-cloud application

The following table presents the set of REST calls associated with the MUSA Deployer in order to

handle the requests related with the Implementation plan. For each call, it is detailed the URI (i.e. the

call path), the HTTP method used, along with the request and response header/bodies.

Table 3. Interface specification for planning the deployment of a multi-cloud application

Resource URI /plans

GET Description It requests for all ids of all available Implementation plans.

Request body Empty.

Response body Media type: Application/json

The JSON response includes a list of identifiers of the

existing Implementation plans.

Response code

semantics

200 (OK), even if there are no Implementation plans.

401 (unauthorized) if Authorization header is missing.

403 (forbidden) The Authorization token has not enough

permissions to execute the operation.

Resource URI /plans/{id}

GET Description It returns the Implementation plan of a multi-cloud

application identified by the id parameter in the call.

Request body Empty

Response header It includes a field Location which indicates the URL of the

Implementation plan created. E.g.: Location: /plans/4

Response code

semantics

200 (OK) resource found and sent.

201 resource created (the Implementation plan was not

found, but it is created and returned).

404 resource not found.






POST Description It generates the Implementation plan of a multi-cloud


Request body Empty

Response body Media type: Application/json

The data model is described in Section 4.2.

Response code

semantics

201 resource created successfully.

409 resource id already exists.

401 (unauthorized) If Authorization header is missing.




PUT Description It updates the Implementation plan of a multi-cloud


Request body Media type: Application/json

The data model is described in Section 4.2

Response body Empty

Response code

semantics

204 resource updated (no content in response).

404 resource not found.





DELETE Description It deletes the Implementation plan. Note that this operation

does not remove the infrastructure created when the plan

was executed previously.

Request body Empty

Response body Empty

Response code 202 accepted.


semantics 404 resource not found.




4.4.2 Deploying/un-deploying a multi-cloud application

The following table presents the set of REST calls associated with the MUSA Deployer in order to

handle the requests related with the deployment and un-deployment of components in a multi-cloud

application. For each call, it is detailed the URI (i.e. the call path), the HTTP method used, along with

the request and response header/bodies.

Table 4. Interface specification for deploying/un-deploying a multi-cloud application

Resource URI /deployments

GET Description It requests for the list of all ids of multi-cloud

applications that have available deployment reports

associated with them.

Request body Empty.

Response body Media type: Application/json.

The JSON response includes a list of identifiers of the

existing deployment reports.

Response code

semantics

200 (OK), even if there are no deployment reports.

401 (unauthorized) if Authorization header is missing


permissions to execute the operation

Resource URI /deployments/{id}

GET Description It returns the deployment report of a multi-cloud


Request body Empty

Response body Media type: Application/json.

The JSON response format deployment reports includes a

list of log traces from the execution of the deployment.

Response code

semantics

404 (not found) if not executed yet.

206 (partial content) if deployment has started.

200 (OK) if deployment has finished.






POST Description It executes an Implementation plan associated with a

multi-cloud application identified by the id parameter in

the call; i.e. initiates the deployment of the multi-cloud

application.

Request body Empty

Response header It includes a field Location which indicates the URL of

the deployment report. The deployment report only is

available after the deployment is finished.

Headers:Location:uri.

Response body Empty

Response code

semantics

204 (no content) The deployment execution has started

(check status by using GET method).

404 (not found) the Implementation plan to be executed

is missing.





PUT Description It executes a redeployment of an Implementation plan

associated with a multi-cloud application identified by

the id parameter in the call i.e. executes the redeployment

of the multi-cloud application.

Request body Empty

Response body Empty

Response code

semantics

204 (no content) The deployment execution has started

(check status by using GET method).

404 (not found) the Implementation plan to be executed

is missing.






DELETE Description It deletes all components in an Implementation plan

associated with a multi-cloud application identified by

the id parameter in the call i.e. executes the un-

deployment of the multi-cloud application, including all

the infrastructure that was created when the

Implementation plan was executed.

Request body Empty

Response body Empty

Response code

semantics

202 (accepted) to start deleting.

206 (partial content) if un-deployment is running.

200 (ok) if un-deployment has finished.





5 MUSA Deployer implementation

In this section we describe the final version of the MUSA Deployer.

5.1 Prerequisites and installation

In the following subsections there is an installation guide for the two MUSA Deployer components. In

the two subsections, the pre-requisites and installation steps are illustrated in detail.

5.1.1 Deployer Planner installation

In order to install the MUSA Deployer Planner, the following prerequisites are needed:

• Git client

• Maven

• Java 8+

In order to install the Deployer Planner, here are the general steps:

• clone the git repository;

• convert it into a Maven project;

• Build the project. If the user is using a terminal, in order to execute tests and to generate the

artefact, he/she needs to execute the following command: ‘maven install’.

Once the artefact is generated, i.e. the jar library, in the folder where is generated and all dependencies

are it needs to be executed as follows:

cp ../musa-deployer/target/*.jar .

java -cp ./*:lib/* eu.musa.deployer.Deployer

sleep 200

5.1.2 Deployer Broker installation

In order to install the Broker, there is the need of installing a machine that hosts a Chef Server: It can

be either a custom installation (On-Premise) or the Hosted solution provided by Chef itself. In both

cases, each Chef Server is identified by an IP address, a username and a password.

For a complete guide on how to install and configure Chef, please refer to the official guide available

at [34].

Once the Chef Server has been properly configured, it is necessary to create or update the Chef

cookbooks that describe the deployment instructions of the particular services that will be deployed

using the Chef Server. The cookbooks are configuration and policy distribution files. A cookbook

defines a scenario and contains everything that is required to support it.

The Deployer Broker in MUSA assumes that the DevOps Team has already created and stored all the

needed cookbooks of the multi-cloud application components. Besides, the MUSA Framework will

have stored the cookbooks of the MUSA agents themselves (the monitoring agents and enforcement

agents for the security assurance at runtime, see deliverable D4.3 for more information). In case a

multi-cloud application component uses MUSA agents, the agents’ cookbooks should be referred to.

When this preliminary procedure has been completed, it is possible to use the Deployer Broker

component in all its functionalities.

Prerequisites needed on the Deployer Broker machine:

• Git client

• Maven

• Java 8+


Another prerequisite for the Deployer Broker is related to the ownership of the following information:

• Private key of the organization defined in the Chef Server;

• Private key of the user defined in the Chef Server;

• CSP endpoint, that is the address the CSP (that offer its Resource Management API);

• Private key that has to be used to acquire resources on the CSP;

• A valid Implementation plan, produced by the Deployer Planner, which describes the

resources to be acquired and configured.

In order to install the Deployer Broker, here are the general steps:

• clone the git repository;

• convert it into a Maven project;

• create the files in the “credentials” folder that has to be put in the src/main/resources folder of

the project, to be able to deploy in the CSP, as explained in Section 5.2.2. It must be noted that

MUSA assumes that credentials are explicitly given by the DevOps Team each time the

deployer runs, alternative solutions for credential management can be adopted (see as an

example SPECS Credential manager [38]), but they are out of the scope of this project.

For security reasons, all the credentials files to use the Deployer Broker with the CSPs are not

stored in the public bitbucket repository. To test the Deployer, the user can ask all credentials

to the MUSA consortium and he/she will be provided with the “credentials” folder.

If the user is using a terminal, in order to execute tests and to generate the artefact, he/she needs to

execute the following command: ‘maven install’.

If the user is using Eclipse as IDE, here is a detailed list of the steps the user has to follow to install

both projects:

• Import project from git as a “general project”;

• right click on the project, click on “configure”, then click on “Convert to Maven Project”;

• right click on the project, click on “Run as”, then click on “Maven install”.

5.2 Usage guide

In the following subsections there is a usage guide for the two MUSA Deployer components.

5.2.1 Deployer Planner usage

The final version of the MUSA Deployer is available in the MUSA website under Tools menu,

www.musa-project.eu. The final MUSA Deployer prototype software is also available in the public

bitbucket as explained in next section.

The use of the MUSA Deployer will be integrated within the complete MUSA Framework usage flow,

which will be explained in detail in deliverable D1.5 Initial MUSA framework implementation.

The MUSA Deployer has a simple Graphical User Interface that allows editing in the Deployer

Planner the Implementation plan that has been automatically created. This is needed in those cases

where the MUSA extended CAMEL model of the multi-cloud application did not specify all the

required deployment information, e.g. in case the deployment instructions or the cookbook to use for a

particular component was not specified.

Other information that always needs to be added in the Implementation plan is the following: user

accounts to log into the VMs, IDs of the networks to which the VMs need to be attached and firewall

rules.

The editor provides model syntax support by showing error warnings similar to the one in figure

below (“Expected ‘,’ instead of ‘.’”) whenever the syntax of the model does not comply with the

required format.

http://www.musa-project.eu/


The button Save Plan allows saving the plan after it has been updated. If no updates were made, then

the button is not activated. When saving the plan, it is stored in the Deployer Core persistence

repository.

The button Regenerate Plan automatically generates the Implementation plan from a new CPIM

and/or new Security SLAs available in MUSA Framework for the application under study.

Figure 13. Deployment planning - Deployer GUI

Once the Implementation plan is saved, the execution of the plan, i.e. the actual deployment of the

application artefacts, is possible. To this aim, the user needs to click on the Deploy button in MUSA

Framework Dashboard (see D1.5) and the Deployment execution will start and the following screen

will appear in the GUI.

Figure 14. Deployment Execution - Deployer GUI


The Re-deploy button allows the deployment of the newly updated or re-generated Implementation

plan. The button will not be activated the first time the user tries to the deploy the application.

The Undeploy button allows the removal of all the components previously deployed for the

application. The button will not be activated unless a first deployment has been executed, was it

successful or not.

A manual of the Deployer Planner and Core usage can be seen in the video named “MUSA

Deployment Plan and Execution” available at the MUSA youtube channel here:

https://www.youtube.com/channel/UCA7mR0pU82yKPhF5jkPSlPw

The video is also available at the MUSA public website www.musa-project.eu within Tools menu.

5.2.2 Deployer Broker usage

Once the Deployer Broker is running, it is possible to use it in two different ways:

• as a dependency of another project;

• as a standalone application, that means using the scripts available in the folder

“src/main/resources/scripts”.

In both cases, the user needs to create a folder named “credentials” in the path src/main/resources/ and

he/she needs to create the following files:

• chefServerUser.txt

o this file represents the private key generated on the Chef Server when a new user is

created;

• musa-validator.txt

o this file represents the private key generated on the Chef Server when a new

organization is created;

• provider_cerictkpProviderName.txt

o this file represents the private ssh key the user wants to use in order to connect to the

VMs acquired on top of CSP named ProviderName;

• def_public_key.txt

o this file represents the public ssh key the user wants to enable on the VMs (acquired

on top of CSPs), in order to allow the Deployer Broker to access the VMs and

configure them.

In case the user wants to use the Deployer Broker as a dependency, the “maven install” process

generates an artefact (a jar file) that can be used by any project that wants to use the functionalities

provided by the Deployer itself. In order to use it, it is just necessary to add the jar file as a

dependency in the pom file of the project that wants to use it.

In case the user wants to use the Deployer Broker as a standalone application, in the folder

“src/main/resources/scripts” one can find two scripts:

1. start_deployer.sh: it allows acquiring new resources form external CSPs. This script can be

executed by any Linux terminal, and it is able to handle the following inputs:

First, the script accepts 4 or 7 parameters.

If only 4 parameters are provided:

o The first one has to be the provider endpoint;

o The second one has to be the provider username;

o The third one has to be the provider password;

o The last one has to be the path to the implementation plan that has

to be used.


http://www.musa-project.eu/


If the 7 parameters are provided:

o The first one has to be the FIRST provider endpoint;

o The second one has to be the FIRST provider username;

o The third one has to be the FIRST provider password;

o The fourth one has to be the SECOND provider endpoint;

o The fifth one has to be the SECOND provider username;

o The sixth one has to be the SECOND provider password;

o The last one has to be the path to the Implementation plan that has

to be used.

Please consider that "FIRST" refers to the first provider that is defined in the Implementation

plan, and "SECOND" refers to the second provider that is defined in the Implementation plan.

2. deleteVMs.sh: it allows to delete the VMs acquired, the security group associated and the

subnetwork (if it exists) starting from the identifier used to acquire those resources; usually

this identifier is the field "sla_id" defined inside the Implementation plan.

This script accepts 4 or 7 parameters:

• If 4 parameters are provided: the parameters have to be passed according to the

following order [identifier, provider endpoint, provider username,

provider password];

• If the 7 parameters are provided:

▪ The first one has to be the identifier;

▪ The second one has to be the FIRST provider endpoint;

▪ The third one has to be the FIRST provider username;

▪ The fourth one has to be the FIRST provider password;

▪ The fifth one has to be the SECOND provider endpoint;

▪ The sixth one has to be the SECOND provider username;

▪ The seventh one has to be the SECOND provider password;

▪ The last one has to be the path to the Implementation plan that has

to be used.

• If no parameter is provided an error is generated;

Please note that the scripts have to be placed in the same folder containing the Deployer Broker jar file

and the lib folder.

An example of usage of the Deployer Broker can be seen in the video named “MUSA Broker”

available at the MUSA youtube channel here:


The video is also available at the MUSA public website www.musa-project.eu within Tools menu.

5.3 Source code repository

The URL links to the final open source projects that implement the MUSA Deployer described above

are the following:

• Link to the Deployer Planner and Core: https://bitbucket.org/musateam/musa-deployer

• Link to the Deployer Broker: https://bitbucket.org/cerict/musa-deployer


https://bitbucket.org/musateam/musa-deployer

https://bitbucket.org/cerict/musa-deployer


6 Innovation in final secure multi-cloud deployment mechanisms

and tools

The provisioning of multiple heterogeneous cloud resources in multi-cloud is a challenging task due to

the lack of widely adopted standards. Most Cloud Service Providers usually offer proprietary APIs to

operate and access their resources, which results in vendor-locked in solutions. Interoperability

standardisation efforts seem not to be mature enough and there is no predominant open standard in the

market yet.

There are open source deployment tools in the market that help the deployment of cloud applications

such as Puppet [15] and Cloud Pier [16] but they lack the main required features in order to deploy

multi-cloud secure applications. MUSA deployment support goes forward in the state-of-the-art and

provides the automation of the provisioning and deployment scripts for the multi-cloud applications

based on the modelling of cloud services at multiple cloud layers (IaaS, PaaS) and of multiple cloud

providers.

The final MUSA Deployer prototype is open-source and vendor independent, as it is based on open

source solutions (e.g. Chef) and background technology provided by MUSA partners (SPECS

deployment support tool by CERICT). While SPECS deployer was designed to be used with SPECS

platform as target cloud, the MUSA Deployer is a multi-cloud oriented deployer, allowing deployment

in multiple cloud providers. Besides supporting multiple cloud providers in the deployment, the

MUSA Deployer can deploy Docker technology based applications and components into cloud

services.

One of the major novelties is that the MUSA deployment methods and tools are devised to address the

DevOps oriented deployment that is a novel approach for the agile alignment of deployment needs

with application requirements and design specification. In this line, the deployment planning is split

from the multi-cloud resources provisioning and deployment execution itself. This way the planning

can be a straightforward result from the application design information and the Security SLAs of its

components, while the deployment execution is an independent process.

The prototype also provides innovative redeployment mechanisms that enable the undeployment,

termination of cloud resources that are not needed anymore, and the redeployment in the new required

cloud resources. The redeployment is part of the reaction mechanisms proposed by the MUSA

Security Assurance Platform which reasons over non-compliance of security controls in the security-

aware SLAs of the multi-cloud application and recommends diverse reaction mechanisms, depending

on the type of non-compliant security control(s) and metric(s).


7 Conclusion and further work

The document provided a description of the final mechanisms and tools offered by MUSA to support

the deployment of multi-cloud applications.

The document builds on previous deliverable D3.2 Initial secure multi-cloud deployment mechanisms

and tools and identifies the coverage of the final prototype with respect to the project requirements

related to multi-cloud deployment.

The mechanisms are based in the parsing of multiple information files around the multi-cloud

application (CPIM in CAMEL, components’ SLA templates in wsag, selected cloud services

information) in order to generate the needed deployment instruction plan, the so-called

Implementation plan. The MUSA deployment Implementation plan model is based on SPECS

Implementation plan and similarly to SPECS, the Chef Configuration Management tool is used to

support the plan execution.

The document also includes a detailed description of the final prototype application named MUSA

Deployer that has been developed in the context of MUSA to implement the mechanisms described.

The description includes the tool architectural design and implementation details.

In the Appendix C, an example of execution of the final prototype application for the MUSA case

study B application, i.e. Tampere Smart Mobility application;

The innovation aspects that have been addressed in the final version of the MUSA Deployer with

respect to the initial version are:

• The capability to deploy multi-cloud applications which components need to be deployed in

PaaS type of clouds, e.g. in Docker containers or in VM pools.

• The capability to deploy in simple Docker containers and in containers managed by Docker

Swarm.

• The capability to support Configuration Management tools like Chef to ease the automation of

the deployment.

• The model and mechanisms to support in MUSA the redeployments and undeployments of

application components.

• The full integration of the MUSA Deployer in the final MUSA workflow through the MUSA

Framework Dashboard.

This report is accompanied by the final version of the software prototypes that implement the MUSA

Deployer tool, which are available in public bitbucket as explained in Section 5.3.


References

[1] Model-based provisioning and deployment of cloud-based systems. CloudML project.

Available at http://cloudml.org. (Retrieved November 2016)

[2] FERRY, Nicolas, et al. Managing multi-cloud systems with CloudMF. Proceedings of the

Second Nordic Symposium on Cloud Computing & Internet Technologies. ACM, 2013. p. 38-

45.

[3] PaaSage project. Model Based Cloud Platform Upperware. FP7- ICT-2011.1.2. 2012-2016.

www.paasage.eu/

[4] MODAClouds project - MOdel-Driven Approach for design and execution of applications on

multiple Clouds. FP7- ICT-2011.1.2. 2012-2015. www.modaclouds.eu/project/

[5] ARTIST project. Advanced software-based service provisioning and migration of legacy

software. FP7- ICT-2011.1.2, 2012-2015. www.artist-project.eu/

[6] Topology and Orchestration Specification for Cloud Applications Standard. TOSCA standard

by OASIS. Available at www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca

(Cited April 2014)

[7] PAHL, Claus; ZHANG, Li; FOWLEY, Frank. A Look at Cloud Architecture Interoperability

through Standards. In CLOUD COMPUTING 2013, The Fourth International Conference on

Cloud Computing, GRIDs, and Virtualization. 2013. p. 7-12.

[8] JUVE, Gideon; DEELMAN, Ewa. Automating application deployment in infrastructure

clouds. In Cloud Computing Technology and Science (CloudCom), 2011 IEEE Third

International Conference on. IEEE, 2011. p. 658-665.

[9] FERRY, Nicolas, et al. Towards model-driven provisioning, deployment, monitoring, and

adaptation of multi-cloud systems. In CLOUD 2013: IEEE 6th International Conference on

Cloud Computing. 2013. p. 887-894.

[10] Cloud Infrastructure Management Interface. CIMI Standards. Available at:

http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.1.0.pdf (Retrieved April

2014)

[11] Open Cloud Computing Interface. OCCI Standards. Available at: http://occi-wg.org/.

[12] Amazon Machine Image. Documentation available at:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html. (Retrieved April 2014)

[13] Google App Engine SDK. Available at:

https://developers.google.com/appengine/downloads (Retrieved April 2014).

[14] Microssoft Azure SDK. Available at: http://azure.microsoft.com/en-

us/downloads/?fb=us-en (Retrieved April 2014).

[15] Puppet Labs: IT Automation Software for System Administrators. Available at

http://puppetlabs.com/ (Retrieved April 2014).

[16] Open Cloud Pier. Available at: www.opencloudpier.org (Retrieved April 2014)

[17] Cloud4SOA project - A cloud interoperability framework and platform for user-

centric, semantically-enhanced service-oriented applications design, deployment and

distributed execution. FP7- ICT-2009.1.2. 2010-2013. Available at: http://cloud4soa.eu/

(Retrieved April 2014)

[18] AWS Elastic Beanstalk. Available at: https://aws.amazon.com/elasticbeanstalk/

[19] Cloudbees. Available at: https://www.cloudbees.com/

http://cloudml.org/

http://www.paasage.eu/

http://www.modaclouds.eu/project/

http://www.artist-project.eu/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca

http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.1.0.pdf

http://occi-wg.org/

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html

https://developers.google.com/appengine/downloads

http://azure.microsoft.com/en-us/downloads/?fb=us-en

http://azure.microsoft.com/en-us/downloads/?fb=us-en

http://puppetlabs.com/

http://www.opencloudpier.org/

http://cloud4soa.eu/

https://aws.amazon.com/elasticbeanstalk/

https://www.cloudbees.com/


[20] Heroku. Available at: https://www.heroku.com/

[21] CloudControl is not available any more. The company went bankrupt in February

2016, as reported in https://en.wikipedia.org/wiki/CloudControl.

[22] CloudFoundry. Available at: https://www.cloudfoundry.org/

[23] OpenShift. Available at: https://www.openshift.com/

[24] Grozev, N. and Buyya, R. “Inter-Cloud architectures and application brokering:

taxonomy and survey”. Software - Practice and Experience, 44(3):369|-390, 2012.

[25] Apache jclouds. Available at: http://jclouds.apache.org/ (Retrieved April 2014)

[26] Apache Libcloud. Available at: https://libcloud.apache.org/ (Retrieved April 2014)

[27] The Ruby cloud services library. Available at: http://fog.io/ (Retrieved November

2016)

[28] Pkgcloud. Available at: https://github.com/pkgcloud/pkgcloud (Retrieved November

2016)

[29] Elibcloud. Available at: https://github.com/esl/elibcloud (Retrieved November 2016)

[30] The MOSAIC project website. Available at: http://www.mosaic-cloud.eu/

[31] Yangui, S., Marshall, IJ., Laisne, JP. et al. J Grid Computing (2014) 12: 93.

doi:10.1007/s10723-013-9285-0

[32] Apache Deltacloud. Available at: https://deltacloud.apache.org/ (Retrieved November

2016)

[33] OW2 Sirocco project. Available at: https://sirocco.ow2.org/bin/view/Main/ (Retrieved

November 2016)

[34] Chef technology, documentation available at https://www.chef.io/chef/

[35] SPECS Project. Secure Provisioning of Cloud Services based on SLA management.

FP7- ICT-2013.1.5, 2013-2016. http://specs-project.eu/

[36] Valentina Casola, Alessandra De Benedictis, Massimiliano Rak, Erkuden Rios:

Security-by-design in Clouds: A Security-SLA Driven Methodology to Build Secure Cloud

Applications. Cloud Forward 2016, Procedia Computers Science Series.

[37] IETF “JSON Schema: A Media Type for Describing JSON Documents”. Available at:

https://tools.ietf.org/html/draft-zyp-json-schema-04 (Retrieved November 2016)

[38] SPECS Project - D4.4.2 Credential Service Components, documentation available at

www.specs-project.eu

https://www.heroku.com/

https://en.wikipedia.org/wiki/CloudControl

https://www.cloudfoundry.org/

https://www.openshift.com/

http://jclouds.apache.org/

https://libcloud.apache.org/

http://fog.io/

https://github.com/pkgcloud/pkgcloud

https://github.com/esl/elibcloud

http://www.mosaic-cloud.eu/

https://deltacloud.apache.org/

https://sirocco.ow2.org/bin/view/Main/

http://specs-project.eu/

http://dblp.uni-trier.de/pers/hd/b/Benedictis:Alessandra_De

http://dblp.uni-trier.de/pers/hd/r/Rak:Massimiliano

http://dblp.uni-trier.de/pers/hd/r/Rios:Erkuden

http://dblp.uni-trier.de/db/conf/cloudforward/cloudforward2016.html#CasolaBRR16

https://tools.ietf.org/html/draft-zyp-json-schema-04

http://www.specs-project.eu/


Appendix A. MUSA motivation and background

The main goal of MUSA is to support the security-intelligent lifecycle management of distributed

applications over heterogeneous cloud resources, through a security framework that includes: a)

security-by-design mechanisms to allow application self-protection at runtime, and b) methods and

tools for the integrated security assurance in both the engineering and operation of multi-cloud

applications.

MUSA overall concept is depicted in the figure below.

Figure A.1: MUSA overall concept

MUSA Framework combines 1) a preventive security approach, promoting Security by Design

practices in the development and embedding security mechanisms in the application, and 2) a reactive

security approach, monitoring application runtime to mitigate security incidents, so multi-cloud

application providers can be informed and react to them without losing end-user trust in the multi-

cloud application. An integrated coordination of all phases in the application lifecycle management is

needed in order to ensure the preventive oriented security to be embedded and aligned with reactive

security measures.


Appendix B. MUSA Implementation plan schema

{ {

"definitions": {},

"$schema": "http://json-schema.org/draft-06/schema#",

"$id": "/",

"description": "MUSA Implementation plan schema.",

"type": "object",

"properties": {

"plan_id": {

"$id": "/properties/plan_id",

"type": "string",

"title": "The Plan_id Schema.",

"description": "The unique identifier of the Implementation plan"

},

"sla_id": {

"$id": "/properties/sla_id",

"type": "string",

"title": "The Sla_id Schema.",

"description": "An unique identifies used internally by the MUSA Deployer."

},

"creation_time": {

"$id": "/properties/creation_time",

"type": "integer",

"title": "The Creation_time Schema.",

"description": "The timestamp at the time of the creation of the Implementation plan."

},

"csps": {

"$id": "/properties/csps",

"type": "array",

"items": {


"$id": "/properties/csps/items",

"type": "object",

"properties": {

"iaas": {

"$id": "/properties/csps/items/properties/iaas",

"type": "object",

"properties": {

"provider": {

"$id": "/properties/csps/items/properties/iaas/properties/provider",

"type": "string",

"title": "The Provider Schema.",

"description": "It contains the identifier that represents the IaaS provider."

},

"zone": {

"$id": "/properties/csps/items/properties/iaas/properties/zone",

"type": "string",

"title": "The Zone Schema.",

"description": "It indicates the region in which the cloud resources have to be acquired."

},

"user": {

"$id": "/properties/csps/items/properties/iaas/properties/user",

"type": "string",

"title": "The User Schema.",

"description": "It indicates the account that can be used to log-in into the IaaS provider in order to

acquire cloud services."

},

"network": {

"$id": "/properties/csps/items/properties/iaas/properties/network",

"type": "string",

"title": "The Network Schema.",

"description": "It represents the network identifier from the cloud service provider used to connect the

different VMs."


}

}

},

"paas": {

"$id": "/properties/csps/items/properties/paas",

"type": "object",

"properties": {

"paasAgent": {

"$id": "/properties/csps/items/properties/paas/properties/paasAgent",

"type": "string",

"title": "The Paasagent Schema.",

"description": "It identifies the type of paas service required by the DevOps Team. The MUSA Deployer

supports one type of paas called docker and it provides the management of cluster of containers with Docker swarm.",

"default": "docker",

"examples": [

"docker"

]

},

"allocationStrategy": {

"$id": "/properties/csps/items/properties/paas/properties/allocationStrategy",

"type": "string",

"title": "The Allocationstrategy Schema.",

"description": "It indicates the allocation strategy of the containers on top of the acquired VMs for

resource optimization. There are 4 options: spread, binpak, random and custom."

},

"components": {

"$id": "/properties/csps/items/properties/paas/properties/components",

"type": "array",

"items": {

"$id": "/properties/csps/items/properties/paas/properties/components/items",

"type": "object",

"properties": {


"vm_id": {

"$id": "/properties/csps/items/properties/paas/properties/components/items/properties/vm_id",

"type": "string",

"title": "The Vm_id Schema.",

"description": "It identifies the VM in which the component will be deployed by the Docker swarm.

This indication only is possible when the allocation strategy is custom."

},

"component_id": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/component_id",

"type": "string",

"title": "The Component_id Schema.",

"description": "It is an explanatory name of the component."

},

"cookbook": {

"$id": "/properties/csps/items/properties/paas/properties/components/items/properties/cookbook",

"type": "string",

"title": "The Cookbook Schema.",

"description": ": It is the name of the considered Chef cookbook, stored inside the chef-server."

},

"recipe": {

"$id": "/properties/csps/items/properties/paas/properties/components/items/properties/recipe",

"type": "string",

"title": "The Recipe Schema.",

"description": "It represents the name of the recipe for the component’s installation and

configuration, stored inside the above cookbook."

},

"implementation_step": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/implementation_step",

"type": "integer",

"title": "The Implementation_step Schema.",


"description": "It represents the global ordering used for component installation. All the

components with the same implementation_step will be installed in parallel.."

},

"acquire_public_ip": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/acquire_public_ip",

"type": "boolean",

"title": "The Acquire_public_ip Schema.",

"description": "It indicates whether a public IP needs to be acquired for the component."

},

"firewall": {

"$id": "/properties/csps/items/properties/paas/properties/components/items/properties/firewall",

"type": "object",

"properties": {

"incoming": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/incoming",

"type": "object",

"properties": {

"source_ips": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/incoming/properties/so

urce_ips",

"type": "array",

"description": "Array list of source IPs.",

"items": {

"type": "string"

}

},

"source_nodes": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/incoming/properties/so

urce_nodes",


"type": "array",

"description": "Array list of source nodes.",

"items": {

"type": "string"

}

},

"interface": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/incoming/properties/in

terface",

"type": "string",

"title": "The Interface Schema.",

"description": "Internally used by the MUSA Deployer Broker."

},

"proto": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/incoming/properties/pr

oto",

"type": "array",

"items": {

"$id":


oto/items",

"type": "object",

"properties": {

"type": {

"$id":


oto/items/properties/type",

"type": "string",

"title": "The Type Schema.",

"description": "It contains the network protocol. Note that, at the moment, all the

rules are always associated to TCP."

},


"port_list": {

"$id":


oto/items/properties/port_list",

"type": "array",

"items": {

"$id":


oto/items/properties/port_list/items",

"type": "string",

"title": "The port_list Schema.",

"description": "It is the list of ports that have to be opened in the security

group."

}

}

}

}

}

}

},

"outcoming": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/outcoming",

"type": "object",

"properties": {

"destination_ips": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/outcoming/properties/d

estination_ips",

"type": "array",

"description": "Array list of destination IPs.",

"items": {

"type": "string"


}

},

"destination_nodes": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/outcoming/properties/d

estination_nodes",

"type": "array",

"description": "Array list of destination nodes.",

"items": {

"type": "string"

}

},

"interface": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/outcoming/properties/i

nterface",

"type": "string",



},

"proto": {

"$id":

"/properties/csps/items/properties/paas/properties/components/items/properties/firewall/properties/outcoming/properties/p

roto",

"type": "array",

"items": {

"$id":


roto/items",

"type": "object",

"properties": {

"type": {


"$id":


roto/items/properties/type",

"type": "string",


"description": "It contains the network protocol. Note that, at the moment, all the

rules are always associated to TCP."

},

"port_list": {

"$id":


roto/items/properties/port_list",

"type": "array",

"items": {

"$id":


roto/items/properties/port_list/items",

"type": "string",


"description": "It is the list of ports that have to be opened in the security

group."

}

}

}

}

}

}

}

}

},

"private_ips": {

"$id": "/properties/csps/items/properties/paas/properties/components/items/properties/private_ips",

"type": "array",


"description": "The private IPs assigned to the component. It is automatically filled by the MUSA

Deployer."

}

}

}

}

}

},

"pools": {

"$id": "/properties/csps/items/properties/pools",

"type": "array",

"items": {

"$id": "/properties/csps/items/properties/pools/items",

"type": "object",

"properties": {

"pool_seq_num": {

"$id": "/properties/csps/items/properties/pools/items/properties/pool_seq_num",

"type": "integer",

"title": "The Pool_seq_num Schema.",

"description": "It represents the order of acquisition of the pools."

},

"vms": {

"$id": "/properties/csps/items/properties/pools/items/properties/vms",

"type": "array",

"items": {

"$id": "/properties/csps/items/properties/pools/items/properties/vms/items",

"type": "object",

"properties": {

"vm_id": {

"$id": "/properties/csps/items/properties/pools/items/properties/vms/items/properties/vm_id",

"type": "string",

"title": "The Vm_id Schema.",


"description": "It represents the identifier of the VM."

},

"vm_seq_num": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/vm_seq_num",

"type": "integer",

"title": "The Vm_seq_num Schema.",

"description": "It represents the order of acquisition of the VMs in the list."

},

"appliance": {

"$id": "/properties/csps/items/properties/pools/items/properties/vms/items/properties/appliance",

"type": "string",

"title": "The Appliance Schema.",

"description": "It indicates the identifier of the image that has to be used as Operating System

of the VM."

},

"hardware": {

"$id": "/properties/csps/items/properties/pools/items/properties/vms/items/properties/hardware",

"type": "string",

"title": "The Hardware Schema.",

"description": "It represents the hardware type of the VM."

},

"public_ip": {

"$id": "/properties/csps/items/properties/pools/items/properties/vms/items/properties/public_ip",

"type": "string",

"title": "The Public_ip Schema.",

"description": "It represents the public IP assigned to the VM; it is automatically filled by the

MUSA Deployer."

},

"components": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components",

"type": "array",


"items": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items",

"type": "object",

"properties": {

"component_id": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/component_id",

"type": "string",

"title": "The Component_id Schema.",

"description": "It is an explanatory name of the component."

},

"implementation_step": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/implementation

_step",

"type": "integer",

"title": "The Implementation_step Schema.",

"description": "It represents the global ordering used for component installation. All the

components with the same implementation_step will be installed in parallel."

},

"cookbook": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/cookbook",

"type": "string",

"title": "The Cookbook Schema.",

"description": "It is the name of the considered Chef cookbook, stored inside the chef-

server."

},

"recipe": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/recipe",

"type": "string",


"title": "The Recipe Schema.",

"description": "It represents the name of the recipe for the component’s installation and

configuration, stored inside the above cookbook."

},

"acquire_public_ip": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/acquire_public

_ip",

"type": "boolean",

"title": "The Acquire_public_ip Schema.",

"description": "It indicates whether a public IP needs to be acquired for the component."

},

"firewall": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/firewall",

"type": "object",

"properties": {

"incoming": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/firewall/prope

rties/incoming",

"type": "object",

"properties": {

"source_ips": {

"$id":


rties/incoming/properties/source_ips",

"type": "array",

"description": "Array list of source IPs.",

"items": {

"type": "string"

}

},


"source_nodes": {

"$id":


rties/incoming/properties/source_nodes",

"type": "array",

"description": "Array list of source nodes.",

"items": {

"type": "string"

}

},

"interface": {

"$id":


rties/incoming/properties/interface",

"type": "string",



},

"proto": {

"$id":


rties/incoming/properties/proto",

"type": "array",

"items": {

"$id":


rties/incoming/properties/proto/items",

"type": "object",

"properties": {

"type": {

"$id":


rties/incoming/properties/proto/items/properties/type",

"type": "string",



"description": "It contains the network protocol. Note that, at the moment,

all the rules are always associated to TCP."

},

"port_list": {

"$id":


rties/incoming/properties/proto/items/properties/port_list",

"type": "array",

"items": {

"$id":


rties/incoming/properties/proto/items/properties/port_list/items",

"type": "string",


"description": "It is the list of ports that have to be opened in the

security group."

}

}

}

}

}

}

},

"outcoming": {

"$id":


rties/outcoming",

"type": "object",

"properties": {

"destination_ips": {

"$id":


rties/outcoming/properties/destination_ips",


"type": "array",

"description": "Array list of destination IPs.",

"items": {

"type": "string"

}

},

"destination_nodes": {

"$id":


rties/outcoming/properties/destination_nodes",

"type": "array",

"description": "Array list of destination nodes.",

"items": {

"type": "string"

}

},

"interface": {

"$id":


rties/outcoming/properties/interface",

"type": "string",



},

"proto": {

"$id":


rties/outcoming/properties/proto",

"type": "array",

"items": {

"$id":


rties/outcoming/properties/proto/items",


"type": "object",

"properties": {

"type": {

"$id":


rties/outcoming/properties/proto/items/properties/type",

"type": "string",


"description": "t contains the network protocol. Note that, at the moment,

all the rules are always associated to TCP."

},

"port_list": {

"$id":


rties/outcoming/properties/proto/items/properties/port_list",

"type": "array",


"description": "It is the list of ports that have to be opened in the

security group."

}

}

}

}

}

}

}

},

"private_ips": {

"$id":

"/properties/csps/items/properties/pools/items/properties/vms/items/properties/components/items/properties/private_ips",

"type": "array",

"description": "The private IPs assigned to the component. It is automatically filled by

the MUSA Deployer."


}

}

}

},

"nic": {

"$id": "/properties/csps/items/properties/pools/items/properties/vms/items/properties/nic",

"type": "string",

"title": "The Nic Schema.",

"description": "Network Interface Controller information filled by the MUSA Deployer."

}

}

}

}

}

}

}

}

}

},

"slos": {

"$id": "/properties/slos",

"type": "array",

"description": "Not used."

},

"measurements": {

"$id": "/properties/measurements",

"type": "array",


},

"annotations": {

"$id": "/properties/annotations",

"type": "array",



}

}

}


Appendix C. MUSA Implementation plan example

In the following we provide an example Implementation plan from the Tampere Smart Mobility

application of the Case Study B in MUSA project. See more details of the application in deliverable

D5.4 Final MUSA case studies implementation of the project.

{

"plan_id" : "6ca7331f-7bf4-4db3-a55c-9cb6e4eef735",

"sla_id" : "prod311eizapptut",

"creation_time" : 1509014657477,

"csps" : [ {

"iaas" : {

"provider" : "OpenStack",

"zone" : "RegionOne",

"user" : "ubuntu",

"network" : " ERASED FOR PRIVACY ISSUES "

},

"pools" : [ {

"pool_seq_num" : 0,

"vms" : [ {

"vm_seq_num" : 0,

"appliance" : " ERASED FOR PRIVACY ISSUES ",

"hardware" : "ERASED FOR PRIVACY ISSUES",

"public_ip" : "",

"components" : [ {

"component_id" : "secAP-install",

"cookbook" : "install-mmt-network",

"recipe" : "default",

"implementation_step" : 0,

"acquire_public_ip" : false,

"firewall" : {

"incoming" : {

"source_ips" : [ ],

"source_nodes" : [ ],

"interface" : "private:1",

"proto" : [ {

"port_list" : [ "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {

"destination_ips" : [ ],

"destination_nodes" : [ ],


"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},


"private_ips" : [ ]

}, {

"component_id" : "secAP-start",

"cookbook" : "start-mmt-network",




"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

}, {

"component_id" : "JourneyDatabase",

"cookbook" : "tut",

"recipe" : "musa_db",



"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ "5432", "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],


"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

} ],

"nic" : "eth0"

}, {

"vm_seq_num" : 1,


"hardware" : " ERASED FOR PRIVACY ISSUES ",

"public_ip" : "",

"components" : [ {






"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

}, {






"firewall" : {

"incoming" : {

"source_ips" : [ ],




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

}, {

"component_id" : "JourneyPlanner",

"cookbook" : "tut",

"recipe" : "musa_mjp",



"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ "8085", "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

} ],

"nic" : "eth0"

}, {

"vm_seq_num" : 2,



"public_ip" : "",


"components" : [ {






"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

}, {






"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"


} ]

}

},

"private_ips" : [ ]

}, {

"component_id" : "ConsumptionEstimator",

"cookbook" : "tut",

"recipe" : "musa_cec",



"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ "9090", "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

} ],

"nic" : "eth0"

}, {

"vm_seq_num" : 3,



"public_ip" : "",

"components" : [ {





"acquire_public_ip" : true,

"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {


"port_list" : [ "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

}, {






"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

}, {

"component_id" : "TSMEngine",

"cookbook" : "tut",

"recipe" : "musa_tsme",



"firewall" : {

"incoming" : {


"source_ips" : [ ],



"proto" : [ {

"port_list" : [ "8080", "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ "8085", "9090", "5432" ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

}, {

"component_id" : "MUSAAgentAC1",

"cookbook" : "enforcement_agents",

"recipe" : "ac",



"firewall" : {

"incoming" : {

"source_ips" : [ ],



"proto" : [ {

"port_list" : [ "80", "22" ],

"type" : "TCP"

} ]

},

"outcoming" : {




"proto" : [ {

"port_list" : [ "9092", "2181" ],

"type" : "TCP"

} ]

}

},

"private_ips" : [ ]

} ],

"nic" : "eth0"

} ]

} ]


} ],

"slos" : [ ],

"measurements" : [ ],

"annotations" : [ ]

}