MUlti-cloud Secure Applications
Deliverable title Deliverable ID:
Final MUSA IDE for security-aware
design of multi-cloud applications
D2.4
Preparation date:
31/10/2017
Editor/Lead beneficiary (name/partner):
Maria Carmen Palacios, Gorka
Echevarría / Tecnalia
Internally reviewed by (name/partner):
Oscar Ripollés / CA
Balázs Somosköi / LHS
Abstract:
This deliverable presents the final version of the MUSA Modeller solution which supports the
modelling of multi-cloud applications taking into account their security concerns. The MUSA Modeller
enables: (a) the multi-cloud secure application components design and (b) declaring MUSA security
agents to use with the application components. The document is the technical report that accompanies
the final software prototype of the MUSA Modeller that has been designed and developed following
the architecture and implementation described herein. Note that the final version of the MUSA
Dashboard for the integrated MUSA Framework is described in deliverable D1.4 Final MUSA
framework specification and guide, and the final version of the SLA Generator that supports the
Security SLA specification and composition is described in deliverable D2.3 Final SbD methods for
multi-cloud applications.
Dissemination level
PU Public X
CO Confidential, only for members of the consortium and the Commission Services
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 2
MUSA consortium
Fundación Tecnalia Research &
Innovation
(TECNALIA, Spain)
www.tecnalia.com/en
Project manager: Erkuden Rios
+34 664 100 348
Centro Regionale Information e
Communication Technology
(CER ICT, Italy)
Contact: Massimiliano Rak
CA Technologies Development Spain
SAU (CA, Spain)
Contact: Victor Muntés
Montimage
(MI, France)
Contact: Edgardo Montes de Oca
edgardo.montesdeoca@montima
ge.com
AIMES Grid Services
(AIMES, UK)
Contact: Prof Dennis Kehoe
Lufthansa Systems GmbH & Co KG
(LHS, Germany)
Contact: Dirk Muthig
TTY-säätiö
(TUT, Finland)
Contact: José Luis Martínez
Lastra
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 3
Table of contents
MUSA consortium .................................................................................................................................. 2 Table of contents ..................................................................................................................................... 3 List of figures .......................................................................................................................................... 4 List of tables ............................................................................................................................................ 5 Executive summary ................................................................................................................................. 6 1 Introduction ..................................................................................................................................... 7
1.1 Objective of this document .................................................................................................... 7 1.2 Structure of this document ..................................................................................................... 7 1.3 Relationships with other deliverables .................................................................................... 7 1.4 Contributors ........................................................................................................................... 8 1.5 Acronyms and abbreviations .................................................................................................. 8 1.6 Revision history ..................................................................................................................... 8
2 Overview of revisions and additions since D2.2 ........................................................................... 10 3 MUSA requirements for security-aware design of multi-cloud applications ................................ 11 4 The MUSA modelling language for multi-cloud applications ...................................................... 15
4.1 Innovations for security behaviour specification ................................................................. 17 4.2 Innovations for multi-cloud deployment .............................................................................. 18 4.3 Innovations for self-healing capability of multi-cloud applications .................................... 20
5 MUSA Modeller Architecture ....................................................................................................... 21 5.1 Objective and overview ....................................................................................................... 21 5.2 Component model ................................................................................................................ 21
5.2.1 Web Component .............................................................................................................. 22 5.2.2 Server Component ........................................................................................................... 23 5.2.3 Database Component ....................................................................................................... 24
5.3 Data model ........................................................................................................................... 28
5.4 Collaboration model ............................................................................................................. 30 5.5 Interface specification .......................................................................................................... 37
5.5.1 Creation of a new multi-cloud application specification model ...................................... 37 5.5.2 Modification of a multi-cloud application specification model ....................................... 37 5.5.3 Recovery of a multi-cloud application specification model ............................................ 38 5.5.4 Recovery of the MACM format of a multi-cloud application specification model given
application identifier ...................................................................................................................... 38 5.5.5 Update of a multi-cloud application specification model with elements related to a security
agent 39 5.5.6 Recovery of the validation errors after parsing the multi-cloud application specification
model 40
6 MUSA Modeller final implementation ......................................................................................... 41 6.1 Prerequisites and installation ............................................................................................... 41
6.2 Usage guide .......................................................................................................................... 41 6.2.1 Model validation - Warnings and error messages ........................................................... 42
6.3 Source code repository ......................................................................................................... 43 7 Innovation ...................................................................................................................................... 44 8 Conclusion ..................................................................................................................................... 45 References ............................................................................................................................................. 46 Appendix A. MUSA motivation and background ................................................................................. 48 Appendix B. CAMEL meta-model extensions in MUSA ..................................................................... 49 Appendix C. Example of TSM application CPIM ................................................................................ 52
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 4
List of figures
Figure 1. MUSA Security DSL ............................................................................................................. 16 Figure 2. MUSA overall workflow ....................................................................................................... 21 Figure 3. MUSA Modeller architecture overview ................................................................................. 22
Figure 4. MUSA Modeller Web Component ........................................................................................ 23 Figure 5. MUSA Modeller Server Component. .................................................................................... 24 Figure 6. Configuration file on which the mapping is established. ....................................................... 26 Figure 7. Configuration file on which the database access is set. ......................................................... 27 Figure 8. MUSA Modeller Database Component ................................................................................. 27 Figure 9. MUSA IDE Editor mu_mcapp table definition ..................................................................... 28 Figure 10. MUSA IDE Editor mu_controls table definition ................................................................. 28 Figure 11. MUSA IDE Editor mu_agents table definition .................................................................... 29 Figure 12. MUSA IDE Editor mu_apps_components_agents table definition ..................................... 29 Figure 13. MUSA IDE Editor mu_app_component table definition ..................................................... 30
Figure 14. MUSA IDE Editor mu_security_capabilities table definition ............................................. 30 Figure 15. MUSA Modeller sequence diagram for creating a new multi-cloud application model. ..... 32 Figure 16. MUSA Modeller sequence diagram for updating a multi-cloud application model. ........... 33 Figure 17. MUSA Modeller sequence diagram for recovering a multi-cloud application model. ........ 34 Figure 18. MUSA Modeller sequence diagram for recovering a MACM model .................................. 35 Figure 19. MUSA Modeller sequence diagram for adding a MUSA Security Enforcement agent to a
multi-cloud application model ............................................................................................................... 36 Figure 20. Modeller GUI ....................................................................................................................... 41 Figure 21. Modeller checking for syntax correctness and integrity while editing ................................ 42 Figure 22. Modeller support the selection of MUSA Security enforcement agents .............................. 42
Figure 23. Validation report of a multi-cloud application model .......................................................... 43
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 5
List of tables
Table 1. Overview of updates since D2.2.............................................................................................. 10 Table 2. Requirements for the MUSA Modeller and coverage in final prototype ................................ 11 Table 3. Interface specification for creating a new multi-cloud application specification model ......... 37
Table 4. Interface specification for updating a multi-cloud application specification model ............... 37 Table 5. Interface specification for recovering a multi-cloud application specification model ............ 38 Table 6. Interface specification for recovery of the MACM format of a multi-cloud application
specification model................................................................................................................................ 38 Table 7. Interface specification for updating a multi-cloud application specification model with elements
related to a security agent ...................................................................................................................... 39 Table 8. Interface specification for recovering the validation errors after parsing the multi-cloud
application specification model ............................................................................................................. 40 Table 9. Overview of MUSA extended CloudML features .................................................................. 44
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 6
Executive summary
This deliverable presents the final version of the MUSA Integrated Development Environment (IDE)
for the security-aware design of multi-cloud applications. The MUSA IDE is composed of the MUSA
Modeller, the MUSA SLA Generator and their accompanying repositories, and is named Key Result
KR1 of MUSA project. Nevertheless, the MUSA SLA Generator that supports the SLA specification
and composition of security requirements is described in deliverable D2.3 Final SbD methods for multi-
cloud applications.
Therefore, this document describes the MUSA Modeller only, which supports the modelling of multi-
cloud applications taking into account their security concerns. The MUSA Modeller enables: (a) the
multi-cloud secure application components design and (b) declaring MUSA security agents to use with
the application components.
The document is the technical report that accompanies the final software prototype of the MUSA
Modeller that has been designed and developed following the architecture and implementation described
herein. The software is publicly available in MUSA bitbucket here:
https://bitbucket.org/account/user/musateam/projects/MUSA.
This final version of the prototype supersedes the initial version description included in previous
deliverable D2.2 Initial MUSA IDE for security-aware design of multi-cloud applications and includes
improvements done addressing initial evaluation feedback. Please note that the state-of-the-art in multi-
cloud modelling languages and the rationale for CAMEL selection as MUSA baseline, both provided in
deliverable D2.2, are 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.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 7
1 Introduction
1.1 Objective of this document
This document is the deliverable D2.4 Final MUSA IDE for security-aware design of multi-cloud
applications of MUSA project [1] (see Appendix A).
In order to address the project Objective SO2, the aim of this document is to describe the final version
of the methods for security-aware analysis and design of multi-cloud applications along with the tool
developed to support them. Although the MUSA IDE is composed of the SLA Generator along with the
Modeller tools, this document focuses only on the latter, i.e. the MUSA Modeller, which supports the
edition of the multi-cloud application models. Therefore, the document does not include the
specification of the final MUSA SLA Generator for the Service Level Agreement (SLA) creation and
composition which is described in deliverable D2.3 Final SbD methods for multi-cloud applications.
The modelling process starts with the analysis of the multi-cloud application and the specification of its
components together with their deployment and security requirements. Following the MUSA approach
described in D1.4 Final MUSA framework implementation, the DevOps Team will optionally use the
MUSA Modeller to specify also the MUSA security enforcement agents to use in order to assure a
number of security properties along the application lifecycle.
As other MUSA tools in the framework, this tool can be accessed from the MUSA framework
Dashboard (Kanban board like dashboard) that integrates the usage of the individual tools, for which a
detailed description is provided in deliverable D1.4.
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
IDE Modeller deliverable compared to the previous version.
• Section 3 presents the requirements related to the multi-cloud application modelling and
requirements specification activity among those presented in Deliverable D1.4, and discusses
their coverage by the final MUSA Modeller prototype application.
• Section 4 specifies the MUSA modelling language developed on top of CAMEL Domain
Specific Language for multi-cloud applications.
• Section 5 describes the architectural design of the final MUSA Modeller.
• Section 6 provides details on the final MUSA Modeller prototype implementation.
• Section 7 summarizes the main innovation brought by MUSA mechanisms and tools on multi-
cloud modelling.
• Section 8 concludes the document by summarising the contents of the document and the main
features and innovation in the MUSA Modeller.
• The Appendix A contextualizes the document by describing the MUSA motivation and
background.
• The Appendix B depicts the extensions to CAMEL developed in MUSA.
• Finally, Appendix C illustrates the meta-model through an example of the CPIM generated for
the Tampere Smart Mobility (TSM) application in Case Study B of MUSA.
1.3 Relationships with other deliverables
The D2.4 presented in this document relates to the following deliverables:
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 8
• D2.2 Initial MUSA IDE for security-aware design of multi-cloud applications, which detailed the
initial version of the MUSA Modeller presented herein. This document supersedes D2.2 because it
extends the previous version to describe all the innovations offered by the final MUSA modelling
language and the Modeller tool.
• D2.3 Final SbD methods for multi-cloud applications, which describes the final mechanisms and
tools that MUSA offers to define the security constraints of a multi-cloud application, in order to
support a security-by-design development process, focusing on the SLA Generation. The document
includes a detailed description of the final MUSA SLA Generator.
• D1.4 Final MUSA framework specification and guide, which details the final MUSA integrated
framework architecture, explaining also the final MUSA Dashboard tool. The document describes
how the MUSA Modeller fits in the complete MUSA architecture and how it relates to other MUSA
tools.
1.4 Contributors
The following partners have contributed to this deliverable:
• Tecnalia
• CERICT
• Montimage
1.5 Acronyms and abbreviations
API Application Programming Interface DST Decision Support Tool
CAMEL Cloud Application Modelling and
Execution Language
IDE Integrated Development Environment
CloudML Cloud Modelling Language QoS Quality of Service
CPIM Cloud Provider Independent Model SLA Service Level Agreement
CPSM Cloud Provider-Specific Model UML Unified Modelling Language
CSP Cloud Service Provider URL Uniform Resource Locator
DSL Domain-Specific Language VM Virtual Machine
1.6 Revision history
Version Date issued Author Organisation Description
1.0 11/09/2017 Maria Carmen
Palacios
Tecnalia TOC and initial draft.
2.0 20/09/2017 Maria Carmen
Palacios
Tecnalia Intermediate proposed
3.0 22/10/2017 Maria Carmen
Palacios
Tecnalia Final proposed with all sections
ready.
4.0 23/10/2017 Valentina Casola CERICT Version reviewed by CERICT
4.1 26/10/2017 Oscar Ripollés CA Version reviewed by CA
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 9
Version Date issued Author Organisation Description
4.2 27/10/2017 Balázs Somosköi LHS Version reviewed by LHS
5.0 30/10/2017 Erkuden Rios Tecnalia Revised version
6.0 31/10/2017 Erkuden Rios Tecnalia Final release
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 10
2 Overview of revisions and additions since D2.2
In this section, we provide the summary of the updates and additions included in this document, the final
MUSA IDE Modeller description, compared to the description of the initial version (deliverable D2.2
Initial MUSA IDE for security-aware design of multi-cloud applications). Please note that the state-of-
the-art in multi-cloud modelling languages provided in deliverable D2.2 (Section 3) and the rationale
for CAMEL selection as MUSA baseline (D2.2 Section 4) are not repeated in this document.
Table 1. Overview of updates since D2.2
Change Section in
D2.2
Section in
D2.4
Rationale
Updated of coverage of
requirements.
Section 2 Section 3 Updates in Final version compared to
Initial version of prototype.
Innovations for security
behaviour.
N/A Section 4.1 The section reflects all innovations in
the final modelling language.
Innovations for multi-cloud
deployment.
N/A Section 4.2 The section reflects all innovations in
the final modelling language.
Innovations for self-healing
capability.
N/A Section 4.3 The section reflects all innovations in
the final modelling language.
No change of high level
architecture.
Section 5.1 &
5.2
Section 5.1 &
5.2
High level architecture description left
in this document for the sake of
understandability of the document.
Changes in data model. Section 5.3 Section 5.3 Data model of final version described.
Changes in collaboration
model.
Section 5.4 Section 5.4 Collaboration model of final version
described.
Changes in prototype
interfaces.
Section 5.5 Section 5.5 Interfaces of final version described.
Changes to describe final
prototype usage.
Section 6 Section 6 Final implementation user manual and
pre-requisites described.
Changes in innovations of
the modelling language and
the supporting tool.
Section 7 Section 7 All the innovations offered by the final
version of the modelling language
formalisms and the tool prototype are
summarised.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 11
3 MUSA requirements for security-aware design of multi-cloud
applications
This section reports on the coverage of requirements elicited in the context of WP1 and described in
section 4 of MUSA deliverable D1.4 Final MUSA framework specification and guide [2]. In particular,
the considered requirements refer to MUSA Modeller that is the part of the MUSA IDE that supports
the creation of the multi-cloud application specification model. In addition to identifying its functional
and security requirements, the DevOps Team will optionally use the MUSA Modeller to specify also
the MUSA security enforcement agents to use in order to assure a number of security properties along
the application lifecycle.
In the following, we review the coverage of the requirements related to the MUSA Modeller by the final
version of the prototype. Therefore, Table 2 summarizes how the Modeller addresses the MUSA
requirements that are relevant to the modelling phase in MUSA.
Table 2. Requirements for the MUSA Modeller and coverage in final prototype
ReqID Title Description Prio
rity
Coverage status
in final prototype
S1.2-R2 Selection of security
controls provided by
the cloud service (by
the CSP)
The MUSA framework should provide
technical information regarding the
security controls offered by the cloud
services (by the CSPs) in the market, in
order they can be selected for the
application components to use them.
1 The initial
prototype allows
specifying the
security controls
required in the
components.
S1.4-R1 Multi-cloud app
modelling tool
The MUSA Framework should provide
a tool that support application architects
in the modelling of multi-cloud
applications.
1 The prototype
allows for
modelling multi-
cloud applications
in an enriched
version of
CAMEL
language.
S1.4-R2 Multi-cloud app
properties defining
tool
The MUSA Framework should provide
a tool that support application architects
in the definition of functional and
security properties of multi-cloud
applications.
1 The enriched
CAMEL used
allows for
specifying
deployment and
security
requirements.
S1.4-R3 Tool for defining the
requirements of the
cloud services
The MUSA Framework should provide
a tool that enables application architects
to model functional and security
requirements of the cloud services
where the multi-cloud application will
be deployed.
1 This part is
covered in MUSA
by MUSA SLA
Generator [3].
S2.1-R1 Support modelling of
multi-cloud
applications
The MUSA Framework should provide
a tool to support application architects
in the modelling of multi-cloud
applications, in order to identify their
architecture and deployment.
1 The enriched
CAMEL used
allows for
specifying
deployment and
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 12
ReqID Title Description Prio
rity
Coverage status
in final prototype
security
requirements.
S2.1-R2 Support defining
multi-facet
requirements
The MUSA Framework should provide
a tool that supports application
architects in the definition of
application security, functional and
business requirements. The tool should
enable the architect to specify complex
requirements related to the usage of the
cloud resources belonging to different
providers.
1 Partially covered
in the prototype,
the specification
of business
requirements is
missing.
S2.3.1-
R2
Coherent Interfaces
for user interaction
The MUSA Framework should provide
a mechanism that allows the user
defining security and functional
requirements of cloud resources to use.
1 The prototype
offers a web GUI
for the users to
create the multi-
cloud application
models. The tool
is also integrated
with the MUSA
Dashboard.
S5.1-R1 Information
Governance/ Best
Practice
accreditations –
Specification
The MUSA Framework should allow
for specifying the need of particular
security accreditations of CSP's (define
it in multi-cloud application
SLA/model through MUSA IDE and
then MUSA DST interprets and selects
cloud resources according to this).
Examples include but are not limited to
IS027001, EuCoC, Uptime Institute
Tier rating
2 This part is
covered in MUSA
by MUSA SLA
Generator [3].
S5.2-R1 The MUSA
framework should
support application
developer to specify
the country/region
where the data should
reside.
The MUSA framework should support
application developer in specifying the
country/region where the data should
reside.
1 The prototype
allows for
specifying the
location
requirement for
deployment.
S5.2-R2 The MUSA
framework should
support application
developer to specify
national security and
information
governance
requirements.
The MUSA framework should support
application developer in specifying
national security and information
governance requirements.
3 Not in MUSA
project lifetime.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 13
ReqID Title Description Prio
rity
Coverage status
in final prototype
S5.3-R1 Geo Redundant
Storage –
Specification
The MUSA framework should support
application developer in specifying the
need of geo redundant storage (in
MUSA IDE and DST interprets)
3 Not in MUSA
project lifetime.
S5.3-R4 CSP Resilience levels
- Specification
The MUSA Framework should support
application developer in specifying the
levels of resilience (up-time, overhead
in VPN compatibility) required from
the CSPs.
2 Not in MUSA
project lifetime.
S5.4-R1 Cloud setting type –
Specification
The MUSA Framework should allow
application developer specifying the
type of cloud setting (hybrid, public,
private, community) required for the
multi-cloud application.
3 Not in MUSA
project lifetime.
S5.4-R2 Cloud bursting –
Specification
The MUSA framework should support
application developer in specifying the
hybrid cloud for bursting functionality
under scalability settings of multi-cloud
application.
2 Not in MUSA
project lifetime,
though CAMEL is
prepared for
specifying
scalability
requirements.
S5.5-R1 Geolocation of
component –
Specification
The MUSA framework should support
application developer in specifying the
country/region where the application
component should be executed/reside.
1 The prototype
allows for
specifying the
location
requirement for
deployment.
S6.1-R3 Language for the
specification of
security properties in
app model
The MUSA framework provides a
modelling language which will be used
to define the multi-cloud application
security requirements. (App
architecture modelling language).
1 The enriched
CAMEL used
allows for
specifying
deployment and
security
requirements.
S6.2-R1 Extract/process
security requirements
from components
The MUSA framework provides
functionality to assist developer to
specify security requirements for
existing application components. This
can be the MUSA security definition
language source or a pre-compiled
version. Source can be file, http, git, jar
etc.
3 Not in MUSA
project lifetime.
In summary, the following requirements that were initially specified for the security-aware multi-cloud
application modelling language and supporting tool in MUSA were finally addressed in the project:
• The language should follow a component-based approach. Therefore, it is required to capture
components, their capabilities as well as component dependencies (such as, the relationships
of communication between components) in models in order to be possible to reason, for
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 14
instance, through effective multi-cloud deployment or security status monitoring. This
requirement is fully completed.
• In order to fully support multi-cloud provisioning, it is required to gather cloud infrastructure
descriptions through the modelling of the types of resources exposed by these infrastructures
and required by the multi-cloud application or its components. The final language fulfils this
requirement and includes even concepts for deployments using containers and PaaS elements.
• The language should support security requirement concept. Users require expressing security
properties and requirements in multi-cloud applications and their components. In a sustainable
partnership, the parties involved should agree on the minimum level of service quality (with
regard to system availability and speed) that is to be observed. In practice, however, the issue
of quality is frequently left open in the service level agreement. In addition to the quality of
service, the varied aspects of data protection and data security are also extremely important for
the cloud consumer when drawing up a full and complete agreement. The tool enables to
specify both security requirements and security properties (in form of security controls)
required and provided by the components of the multi-cloud application. Thus, the requirement
is successfully addressed by the prototype.
• The language should support security control concept. Users need to identify the security
controls required to guarantee security requirements are respected. A security control can be
defined as a safeguard or a countermeasure prescribed to protect a system and meet a set of
defined security requirement. The extended language not only allows for defining the required
controls but also the provided controls in those cases when the component is a security
mechanism itself. This is the case of MUSA Security Enforcement agents that are considered
security mechanisms providing certain security controls which are defined in the model in order
they can be considered in the following Risk Analysis step and SLA Generation step in MUSA
framework.
• The language should allow declarative expression of complex deployment requirements such
as formal, detailed resource requirements (e.g., resilience, bursting or geolocation). Location
specification was allowed already in CAMEL and is kept in MUSA. Addressing performance
requirements in the application life-cycle was not the main focus of MUSA, but security
requirements. Therefore, the prototype does not address the performance related requirements
because the functionality of the rest of the tools in the framework was also focused in security
requirements.
• The tool should help users to automatize the multi-cloud application lifecycle as much as
possible. Managing the lifecycle of applications is still a tedious task and what is worse the
speed at which applications change in the cloud affects their security. Therefore, it is vital to
allow users to explicitly define these processes. The tool has fully achieved this requirement as
it enables the creation of the application model that is the basis for the plan of automatic
deployment in MUSA and it also automates the generation of the Multi-cloud Application
Composition Model (MACM) (required for the automatic generation of the security Service
Level Agreement) and automates the specification in the model of the MUSA Security
Enforcement Agents in case the user decides to use them.
• The tool should be tightly integrated with the other tools in the framework for a seamless
management the multi-cloud application lifecycle, so the DevOps teams can work efficiently
and following agile practices. As it is explained in deliverable D1.4, this requirement is
successfully addressed in the Modeller prototype and in all tools in the framework, because all
the tools work smoothly together to support the security in multi-cloud applications through
the usage of a framework Dashboard.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 15
4 The MUSA modelling language for multi-cloud applications
As explained in deliverable D2.2, the MUSA Security Domain Specific Language (DSL) builds on top
of the CAMEL language and the main contributions are related to its expressiveness to define and
configure secure multi-cloud applications at design-time. Such a powerful definition can be used later
on by other MUSA tools to perform the risk analysis and to generate the individual components’ security
Service Level Agreement (SLA) templates and the application Composite Security SLA. Furthermore,
this allows deploying and monitoring the security properties of multi-cloud applications and its
components at run-time.
The state-of-the-art in multi-cloud application security modelling and rationale for CAMEL language
selection was already described in previous D2.2. In summary, CAMEL was selected as the baseline in
MUSA due to it is a powerful language that already addressed multi-cloud deployment specification and
included some security requirements specification features, easily extensible in MUSA
The MUSA Security DSL extends CAMEL as shown in Figure 1. In the following subsections we detail
the innovations brought by MUSA extensions.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 16
Figure 1. MUSA Security DSL
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 17
4.1 Innovations for security behaviour specification
The MUSA innovations to CAMEL language include the enhanced component security behaviour
characterization, which addresses concepts required to support both composition of components’
security Service Level Agreements (SLAs) and risk analysis. They are described in the following:
• Classification of components by their nature which allows describing what the component
does. This information is required by the MUSA SLA Generator to create the Composite
Security SLA of the multi-cloud application from individual components’ SLAs and by the
MUSA Risk Analysis tool in order to identify the security threats and risks at component level.
Our CAMEL extension allows specifying the type of the component; in fact, the component can
be classified by two features: WHAT and HOW. While WHAT indicates the type of the
functionality delivered by the component, HOW indicates the way the component is delivering
such functionality.
Currently, three types of HOW have been defined:
a. COTS, which refers to Commercial of-the-shelf software that the application uses.
b. SERVICE, meaning that the component is not a commercial package but developed by
the DevOps Team responsible for the multi-cloud application engineering.
c. AGENT, i.e. a MUSA Agent component provided by the MUSA framework and
available in the MUSA Security Agent Catalogue.
The types of WHAT include:
a. in case the component is COTS or SERVICE, the possible WHAT values are: Web,
Storage, IDM or Firewall. Web refers to any functionality provided through a Web
interface, Storage refers to data storage solutions (e.g. MySQL), IDM stays for Identity
Management and Firewall for any software solution that protects resources from
unauthorised access.
b. in case the component is AGENT, the possible values of WHAT come from the list of
the agents in the MUSA Security Agent Catalogue.
• Security Controls information that properly supports Security Control Framework families.
For example, name attribute has been updated to <Family>-<Number>(Number) format. In
addition, the subdomain attribute in the Security Control entity now is optional instead of
compulsory.
The CAMEL extension developed in MUSA allows specifying which security capabilities are
required and provided by each multi-cloud application component. The security capabilities are
defined in the model by selecting and grouping the security controls part of the capability. The
security controls of a Security Control Family are predefined and the list is offered to the user
by the MUSA Modeller to ease the selection of the ones included in the capability.
Currently, the security controls from the NIST SP 800-53 rev.4 [4] are supported. In the
following example two security capabilities CAP1 and CAP2 are defined, the first with three
security controls and the second with only two.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 18
Once the security capabilities are defined in the CAMEL (in the security model part of the
model), the user can specify what security capabilities the components require and/or provide.
In the following example, Comp1Cap is a provided capability and Comp1CapReq a requested
one.
When a component requires a specific security capability from another component (in the
example, Comp1CapReq) then the matching of the capability needs to be modelled as follows.
4.2 Innovations for multi-cloud deployment
Other MUSA innovations to CAMEL language address improvements for enhancing the expressiveness
of the deployment requirements, as follows:
• Explicit characterization of the nature of the IP address associated with virtual machines in
which the components will be deployed. At deployment phase, when acquiring new cloud
resources such as VMs, the system operator needs to indicate whether a public IP address is
required. The CAMEL extension allows specifying whether the IP address required for a VM
should be public or not by the IP public attribute on each component. The possible values for
this attribute are: true or false.
• Specification of the deployment order of the application components. Dealing with multi-
cloud environments, it is critical to identify the order in which each component should be
deployed and configured, since there are inter-dependencies among the components that are part
of the same application. For example, the start up of a component may require that another
component is up and running in advanced. The CAMEL extension allows specifying the order
provided security capability Comp1Cap {
security capability SEC.CAP2
}
required security capability Comp1CapReq
security model SEC {
security capability CAP1 {
controls [MUSASEC.AC-11(1), MUSASEC.AU-13(2),
MUSASEC.AC-17(6)]
}
security capability CAP2 {
controls [MUSASEC.AC-11(1), MUSASEC.AC-17(6)]
}
}
capability match Comp1ToComp2 {
from Comp1.Comp1CapReq to Comp2.Comp2Cap
}
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 19
in which the components are required to be deployed. This can be done by using the order
attribute for each component. The expected value for the order attribute is an integer number.
• Explicit definition of data exchange protocols. In the MUSA extended CAMEL, users can
model the communications between the components (e.g. by setting the IP addresses and ports
in the configuration of the components) and specify the need to use a specific data exchange
protocol (e.g. MySQL, OAuth, Other).
• Modelling of dynamic configurations of communications between components. In CAMEL,
users model the communications between the components in a static way (i.e. through specific
port numbers and operating system configuration variables). However, in MUSA, dynamic
characteristics have been introduced such as context paths (instead of IP addresses) and dynamic
port ranges.
Such new capabilities are useful, for instance, to configure explicitly inbound traffic when users
deploy components in Docker [5] containers.
• Modelling of deployment handlers. In CAMEL, the user can model components and associate
deployment instructions for installing, configuring, starting, and stopping the components on
virtual machines. However, such deployment instructions are restricted to scripted commands
and CAMEL lacks support to the specification of configuration management tools such as
Cloudify [6], Puppet [7], or Chef [8]. Therefore, in MUSA this gap between multi-cloud
application models and these advanced frameworks has been faced via the new Configuration
entity and its associated concepts (e.g. cookbooks and recipes in case of Chef).
• Modelling of PaaS layer elements. CAMEL lacks support to the description of architectures
where the application components are not directly deployed in Virtual Machines (VMs) but in
containers. Our extension allows specifying the container type that will be used in deployment
and defining the component allocation strategy it should follow, even in cases when the
container uses VM pools. The new elements in our extension include:
o pool: is a cluster of VMs, which will be used by a container.
o manager: the VM in a pool that will act as the manager in contrast to the rest that will
act as workers.
o container:
- type: the container solution to use, for example, Docker Swarm [9].
- allocationStrategy: defines 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:
• spread: balance containers across the VMs in a pool based on the available
CPU and RAM of the VMs.
• 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.
• random: choose a VM randomly.
• custom: the user defines the specific VMs in which the containers should
run.
• Refinement of security aspects in Organisation, User, Credentials and Role entities. A number
of enhancements to CAMEL have been made in order to manage the authorisation of different
roles in the DevOps Team to multi-cloud application deployment execution. For instance, in
MUSA the types of credentials available to authenticate a user have been extended. Moreover,
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 20
it has been added expiration dates to Credentials and the re-use of Role Assignments has been
improved by allowing an easy assignment of roles to multiple groups and users.
4.3 Innovations for self-healing capability of multi-cloud applications
Considering self-healing as the capability of a multi-cloud application of being able to self-control or
modify its security behaviour at runtime so as security incidents or attacks are corrected or mitigated,
self-healing is enabled in MUSA by the MUSA Enforcement Agents.
As their name suggests, the MUSA Security Enforcement Agents enforce multi-cloud application
security properties at runtime such as access control, security vulnerability scanning or Denial of service
mitigation mechanisms. For these mechanisms to work, they need to be deployed at the same time as
the application components are deployed. Some of these mechanisms require to be deployed together
with (in the same VM) the component that they will enforce the property on.
Therefore, the MUSA extended CAMEL allows the definition of MUSA Security Enforcement Agents
as Internal Components of the application, similarly to application components themselves, so as they
can be included in the deployment plan. Such agents are already pre-defined in the MUSA Security
Agent Catalogue so users are able to re-use and configure them in a friendly way. Some of these agents
are always on and some will be managed through the enforcement services in the MUSA Security
Assurance Platform.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 21
5 MUSA Modeller Architecture
This section contains the description of the final MUSA Modeller’s architecture.
The MUSA IDE was identified as KR1 and includes MUSA Modeller and MUSA SLA Generator. The
SLA Generator is explained in deliverable D2.3 Final SbD methods for multi-cloud applications and
this section focuses in the Modeller.
5.1 Objective and overview
The MUSA Modeller is a web editor that allows the creation and maintenance of CAMEL (extended)
models. Through these models it is possible to specify a complete specification of the requirements
needed by an application to be deployed in a secure multi-cloud environment.
Next figure shows the MUSA overall workflow and how the MUSA Modeller fits in it. As initial step
of the design phase, the DevOps Team creates the Cloud Provider Independent Model (CPIM) of the
multi-cloud application using the MUSA Modeller. The CPIM of the application is a specification done
in a level of abstraction independent from information of specific Cloud Services that the application
will use. The generated CPIM is used in the risk assessment and in the multi-cloud application
deployment as input. Please note that in the final version, the SLA generation process does not require
as input the generated CPIM, because it uses the MUSA Modeller created Multi-cloud Application
Composition Model (MACM) instead. The detailed MUSA workflow is described in D1.4 Final MUSA
framework specification and guide.
Figure 2. MUSA overall workflow
5.2 Component model
Even if the MUSA overall workflow has slightly changed from the initial version, being the Modeller
the first step in the workflow, its high level architecture has not changed.
Next are described the high level components in which the MUSA Modeller is structured:
• Web component: represents the interface from which the user accesses the Modeller and all
the logic necessary to access the services offered by the Server Component. It includes the Xtext
Web Editor framework [10] libraries that offer services for remote management of syntax
validation and auto completion
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 22
• Server component: contains the main logic of the Modeller. It offers a series of web services
that can be invoked from the Web component and that implement all the necessary
functionalities.
• Database component: contains all the logic through which database operations are performed.
It uses the Hibernate framework [11], which allows abstracting from the database engine by
using a declarative specification (in configuration files) of the connection data.
In the following sections a detailed explanation of each of these components is made.
Figure 3 illustrates a high level overview of the full architecture.
Figure 3. MUSA Modeller architecture overview
5.2.1 Web Component
5.2.1.1 Overview
The Web Component represents the interface through which the DevOps Team accesses the Modeller.
It invokes services deployed on the Server Component.
5.2.1.2 Component diagram
As it can be seen in next figure, the Web Component is mainly composed of three sub-components:
• Modeller Web Page: Interface through which the DevOps Team accesses the Modeller and
models the CPIM of the multi-cloud application. It consists of html code with controls that allow
the user to interact with the system and stylesheets and javascript files provided by the Xtext
Web Editor framework [10]. The javascript files contain code used to invoke the Xtext services,
allowing this way the creation of a (extended) CAMEL language´s syntax editor within a web
browser.
• CAMEL DSL (Domain Specific Language): Library containing the specification of the
extended CAMEL meta-model (official library + extension made to meet MUSA project´s
specific needs). This library is used by Xtext to validate the syntax and to handle the auto
completion functionality of the elements belonging to the models written in the editor of the
Modeler by the DevOps Team members.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 23
• Xtext Web Services: Xtext library that contains a series of REST services capable of providing
the tool's full functionalities within a web environment. Until the appearance of Xtext version
2.9 in December 2015, the framework had provided the functions of creating and validating
syntax of domain dependent languages only in stand-alone environments (mainly within the
Eclipse ecosystem), but in version 2.9 Xtext included a series of REST web services together
with javascript files and style sheets in order to facilitate the use of the framework in web
environments.
Figure 4. MUSA Modeller Web Component
5.2.2 Server Component
5.2.2.1 Overview
The Server Component acts as an intermediary between the Web Component and the Database
Component. It implements web services through which maintenance operations (creation, consultation
and modification) of the CAMEL models are offered. These services send the corresponding request to
the Database Component to execute the operation on the database.
Moreover, this component implements the REST service that transforms a multi-cloud application
model in CAMEL format to Multi-cloud Application Composition Model (MACM) format that will be
used by the MUSA SLA Generator (see Section 7).
5.2.2.2 Component diagram
The Server Component is composed of two sub-components.
• Maintenance Web Services: Web services exposed through a REST interface that are invoked
from the Web Component to create, modify or query a (extended) CAMEL model given an
application identifier. These services delegate all necessary processing to classes contained in
the Maintenance Core, which are responsible of processing the data that is sent and retrieved
from the database through the Data Component.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 24
• Maintenance Core: A package containing a series of java classes in which web services
delegate all data processing and access to the database.
Figure 5. MUSA Modeller Server Component.
5.2.3 Database Component
5.2.3.1 Overview
This component encapsulates all the accesses to the database in which the (extended) CAMEL models
are stored.
This component makes use of Hibernate [11], the object-relational mapping framework for the Java
language. Hibernate's primary feature is mapping from Java classes to database tables; and mapping
from Java data types to SQL data types. Hibernate also provides data query and retrieval facilities. It
generates SQL calls and relieves the developer from manual handling and object conversion of the result
set.
Apart from this, Hibernate allows to make an abstraction of the database engine used, by specifying the
database configuration data declaratively, so that in case of a change of database engine, it would not be
necessary to modify the code to access to it.
5.2.3.2 Component diagram
The Database Component is composed of two sub-components.
• Database Manager: A component that contains all the operations that can be performed against
the database tables. Please note that the database tables are described in Section 5.3.
It is based on a java class that implements the following methods:
o addMCApp (String mcApplication, String version, String camel)
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 25
Method through which a new record is inserted into the mu_mcapp table. It receives as
parameters the application ID, the application version and the camel model that is
wanted to be stored for the application.
o getMCApps( )
Returns all the applications with their associated CAMEL models.
o getMCApp(String mcApplication)
Retrieves the data of a certain application from its identifier.
o updateMCApp(String mcApplication, String camel)
Updates the model associated to an application given its identifier and the new version
of the model.
o deleteMCApp(String mcApplication)
It deletes all the data corresponding to an application given its identification.
o addDomain (String id, String domain)
Method through which a new record is inserted into the mu_controls table. It receives
as parameters the ID and name of the domain to be stored.
o getDomains( )
Returns all the security domains stored on the database.
o addSC (String id, String name, String specification, String domain)
Method through which a new record is inserted into the mu_controls table. It receives
as parameters the ID, name, specification and domain of the security control to be
stored.
o getSCs( )
Returns all the security controls stored on the database.
o checkIfAppAgentRelationExists(String, String, String)
Checks if a security agent is related to an application.
o checkIfAppComponentAgentRelationExistsIfNotExecuteInsert(String, String,
String)
Checks if a security agent is related to an application´s component. If not, it establishes
the relation in the database.
o checkIfAppExists(Long)
Checks if an application exists in the database.
o deleteNonExistingComponents(Long, ArrayList<Integer>)
Deletes components from the mu_app_component table that no longer exist.
o getAgents()
Recovers the existing security agents from the database.
o getAppCamel(Long)
Returns a multi-cloud application model in CAMEL format stored in the database given
its id.
o getAppCamelXML(Long)
Returns a multi-cloud application model in XMI format stored in the database given its
id.
o getAppValidationReport(Long)
Returns a list containing all the validation errors stored in the database after parsing the
model.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 26
o getComponentsByApplication(Long)
Returns a list of all the components related to an application given its id.
o getSecurityAgentCamelModel(String)
Recovers the security agent model from the mu_agents table given the agent id.
o getSecurityCapabilityByAgentId(String)
Recovers the security capability from mu_security_capabilities table given the
capability id.
o updateCamelAndXMIofMCApp(Long, String, String)
Updates the multi-cloud application model in both CAMEL and XMI format by storing
them in the database.
• Hibernate Configuration: Set of configuration files and classes through which declarative
access to the database is managed via Hibernate. It is also established an automatic mapping of
java objects with database tables (in this case we only have one). This automatic mapping even
allows the database to be created when the server is started, without the need to launch a script
or to access a client to access the particular database engine.
Next, we show the content of the two configuration files that are used:
Figure 6. Configuration file on which the mapping is established.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 27
Figure 7. Configuration file on which the database access is set.
In the next figure, the component diagram of the MUSA Modeller Database Component is depicted.
Figure 8. MUSA Modeller Database Component
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 28
5.3 Data model
This section presents the data model used by the Modeller Editor.
The data model consists of several tables: mu_mcapp, mu_controls, mu_agents,
mu_apps_components_agents, mu_app_component and mu_security_capabilities.
Next it is included a description of the tables contained in the modeller database.
mu_mcap stores all information related to multi-cloud applications.
Figure 9. MUSA IDE Editor mu_mcapp table definition
Where:
• Id: application identifier (auto-incremental value).
• Date: date on which a record is inserted or modified.
• MCApplication: descriptive name of the application.
• MCAVersion: version of the (ext.) CAMEL model for the application.
• Camel: CAMEL model.
• CamelXMI: CAMEL model in XMI format.
• CamelReport: Validation report of the CAMEL model.
mu_controls, like mu_mcap has a direct correspondence with the structure of the classes shown in the
previous section related to the Hibernate Configuration and stores all information related to security
controls.
Figure 10. MUSA IDE Editor mu_controls table definition
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 29
Where:
• Id: internal security control identifier (auto-incremental value).
• Control: group of the family to which the security control belongs to (e.g., “2”).
• Control_description: textual specification of the security control provided by the different
service providers.
• Control_id: security control identifier known by the service providers, security bodies and
authorities (e.g., “AC-2(1)”).
• Control_name: short name used to identify the security control (e.g., “Access Control Policy
and Procedures”).
• Enhancement: for internal use.
• Family_id: abbreviation of the family name (e.g., “AC”).
• Family_name: represents the family associated with the security control (e.g., “Access
Control”) and allows grouping security controls. It can represent a security domain or sub-
domain.
mu_agents stores all information related to security agents.
Figure 11. MUSA IDE Editor mu_agents table definition
Where:
• id: agent identifier.
• name: agent name.
• description: agent description.
• cook_book: cook book associated to the agent.
• camel_model: CAMEL model associated to the agent to be included in the multi-cloud
application model when the agent is added to a component of a specific application.
• security_capability_id: foreign key referring the security capability related to the agent in the
mu_security_capabilities table.
• avalilable: indicator to know if the agent is available to be included or not.
mu_apps_components_agents relates application controls with security agents.
Figure 12. MUSA IDE Editor mu_apps_components_agents table definition
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 30
Where:
• app_id: application id.
• component_id: component id.
• agent_id: agent id.
mu_app_component stores the relation between applications and components.
Figure 13. MUSA IDE Editor mu_app_component table definition
Where:
• app_id: application id.
• component_id: component id.
• component_name: component name.
mu_security_capabilities stores data related to the security capabilities associated to the security agents.
Figure 14. MUSA IDE Editor mu_security_capabilities table definition
Where:
• id: capability id.
• name: capability name.
• value: capability value.
5.4 Collaboration model
The collaboration model below describes the three main operations that can be executed through the
MUSA Modeller, which capture all the functionalities offered by the module:
• creation of a new multi-cloud application specification model (extended camel)
• update of a multi-cloud application specification model.
• recovery of a multi-cloud application specification model given application identifier.
• recovery of the MACM format of a multi-cloud application specification model given
application identifier.
• selection and insertion of a MUSA Security Enforcement Agent into a multi-cloud application
specification model.
Figure 15 shows the process followed to create a new multi-cloud application specification model.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 31
First, the DevOps Team accesses the Modeller Web Page with the aim of creating a new multi-cloud
application specification model. This page contains an editor through which the engineer can specify
the deployment features of the application by following the extended CAMEL grammar. As the engineer
edits the model, the syntax of the model is validated by invoking a series of REST web services offered
by the Xtext Web Editor framework.
Once the model has been written by the DevOps Team, he can make a request to save it associated with
an application by invoking the createMcApp operation of the Maintenance Web Services. This service
delegates the management of the insertion to the database to the Maintenance Core component, which
in turn will use the Database Manager to finally perform the insertion.
Figure 16 shows the process followed to perform the modification of a multi-cloud application
specification model.
The process is practically the same as in the previous case. As it can be seen in the sequence diagram,
the only two differences are as follows: in this case, first the DevOps Team has to select the application
and the version of which he wants to get the model for later editing. Once he has the model loaded in
the web page editor, he can edit it. When the model has been edited and by selecting the "save" option,
the updateMcApp service of Maintenance Web Services will be invoked, and the corresponding update
will be made in the database. This service requires the application id and the modified camel to be passed
as parameters.
Figure 17 shows the process that is executed to retrieve a multi-cloud application specification model
by giving the id of the application to which it belongs to.
In this case, a REST client calls the getCamel service exposed by the Maintenance Web Services
component. As in the previous cases, the web service delegates all the management of the request to the
Maintenance Core, which at the same time uses the Database Manager to perform the operation in the
database. Once the query has been executed, the recovered CAMEL model is returned as a string in case
it has been found and, if it is not found, an error message indicating this situation is returned.
Figure 18 shows the steps executed when it is necessary to retrieve the Multi-cloud Application
Composition Model (MACM) format of the CAMEL model, i.e. when this is required by the MUSA
Dashboard to make it available to: (i) the SLA Generator that will use the information in the MACM for
the Service Level Agreement composition process (see deliverable D2.3 for further information of the
SLA composition process), and (ii) the DST (both Risk Analysis and Decision) that will use the
information for the risk analysis and cloud service selection processes. In this case, the getCamel service
is used with MACM value in Format parameter, so the Maintenance Web Services knows that it has to
retrieve the model in MACM format.
Figure 19 shows the process for adding a MUSA Security Enforcement agent to a multi-cloud
application model. The REST client uses the putAgent service exposed by the Maintenance Web
Services component, and the Maintenance Core is called to store the agent information in the database
and check whether the relationship between the Agent and the Component is already defined, and if not,
the relationship is created automatically in the database.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 32
Figure 15. MUSA Modeller sequence diagram for creating a new multi-cloud application model.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 33
Figure 16. MUSA Modeller sequence diagram for updating a multi-cloud application model.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 34
Figure 17. MUSA Modeller sequence diagram for recovering a multi-cloud application model.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 35
Figure 18. MUSA Modeller sequence diagram for recovering a MACM model
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 36
Figure 19. MUSA Modeller sequence diagram for adding a MUSA Security Enforcement agent to a multi-cloud application model
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 37
5.5 Interface specification
The REST API interfaces offered by the MUSA Modeller to perform the operations described in the
previous section are described below:
• creation of a new multi-cloud application specification model (extended camel)
• update of a multi-cloud application specification model.
• recovery of a multi-cloud application specification model given application identifier.
• generation of the MACM format of a multi-cloud application specification model given
application identifier.
• update of a multi-cloud application specification model with elements related to a security agent,
given data related to the application and component to which the agent is added and data related
to the agent itself.
• recovery of the validation errors after parsing the multi-cloud application specification model.
5.5.1 Creation of a new multi-cloud application specification model
The following table presents the set of REST calls associated with the creation of a new model. For each
call, it is detailed the URI (i.e. the call path) and the HTTP method used, along with the request and
response header/bodies.
Table 3. Interface specification for creating a new multi-cloud application specification model
Resource URI /createMcApp
POST Description It requests for the creation of a new multi-cloud
application specification model.
Request body Multi-cloud application (McApplication) id, version and
extended camel document in json format.
Response body Media type: Application/json
Response code
semantics
200 (OK) if the model has been created correctly.
Diverse 400 type messages depending on the error.
5.5.2 Modification of a multi-cloud application specification model
The following table presents the set of REST calls associated with the update of a model. For each call,
it is detailed the URI (i.e. the call path) and the HTTP method used, along with the request and response
header/bodies.
Table 4. Interface specification for updating a multi-cloud application specification model
Resource URI /updateMcApp
POST Description It requests for the update of multi-cloud application
specification model.
Request body Multi-cloud application (McApplication) id and extended
camel document in json format.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 38
Response body Media type: Application/json
Response code
semantics
200 (OK) if the model has been updated correctly.
Diverse 400 type messages depending on the error.
5.5.3 Recovery of a multi-cloud application specification model
The following table presents the set of REST calls associated with the recovery of a model given the
application id to which it belongs to. For each call, it is detailed the URI (i.e. the call path) and the HTTP
method used, along with the request and response header/bodies.
Table 5. Interface specification for recovering a multi-cloud application specification model
Resource URI /getCamel/{is}/CAMEL
GET Description It requests the retrieval of a multi-cloud application
specification model given an application id.
Request body Empty
Response body Media type: Text/plain
Response code
semantics
A string containing the model if it can be recovered.
Diverse 400 type messages depending on the error.
5.5.4 Recovery of the MACM format of a multi-cloud application specification
model given application identifier
The following table presents the set of REST calls associated with the recovery of the Multi-cloud
Application Composition Model (MACM) format of a model given the application id to which it belongs
to. For each call, it is detailed the URI (i.e. the call path) and the HTTP method used, along with the
request and response header/bodies.
Table 6. Interface specification for recovery of the MACM format of a multi-cloud application
specification model
Resource URI /getCamel/{is}/MACM
GET Description It requests the retrieval of a multi-cloud application
specification model in MACM format given an
application id.
Request body Empty
Response body Media type: Text/plain
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 39
Response code
semantics
A string containing the model if it can be recovered.
Diverse 400 type messages depending on the error.
5.5.5 Update of a multi-cloud application specification model with elements
related to a security agent
The following table presents the set of REST calls associated with the update of a multi-cloud
application specification when a security agent is associated to an application component. For each call,
it is detailed the URI (i.e. the call path) and the HTTP method used, along with the request and response
header/bodies.
Table 7. Interface specification for updating a multi-cloud application specification model with
elements related to a security agent
Resource URI /getAgents
GET Description It requests the retrieval of information related to the
security agents
Request body Empty
Response body Media type: Text/plain
Response code
semantics
Data related to agents recovered from the database in json
format.
Diverse 400 type messages depending on the error.
Resource URI /getComponentsByApplication/{appId}
GET Description It requests the retrieval of the components related to an
application id
Request body Empty
Response body Media type: Text/plain
Response code
semantics
Data related to components recovered from the database
in json format.
Diverse 400 type messages depending on the error.
Resource URI /putAgent/{appId}/{appName}/{agentId}/{agentName}/{componentId}/{com
ponentName}
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 40
PUT Description It requests the update of the model and the database
given the ids and names of the application, component
and agent.
Request body Empty
Response body Media type: Text/plain
Response code
semantics
200 (OK) if the model has been updated correctly.
Diverse 400 type messages depending on the error.
5.5.6 Recovery of the validation errors after parsing the multi-cloud application
specification model
The following table presents the set of REST calls associated with the recovery of the validation errors
after parsing the multi-cloud application specification model. For each call, it is detailed the URI (i.e.
the call path) and the HTTP method used, along with the request and response header/bodies.
Table 8. Interface specification for recovering the validation errors after parsing the multi-cloud
application specification model
Resource URI /getValidationErrorsByApplication/{appId}
GET Description It requests the retrieval of the validation errors after
parsing an application model given its id.
Request body Empty
Response body Media type: Text/plain
Response code
semantics
A string containing the validation errors if any.
Diverse 400 type messages depending on the error.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 41
6 MUSA Modeller final implementation
In this section, we describe the final version of the MUSA Modeller that was produced in the project.
6.1 Prerequisites and installation
The MUSA Modeller requires the installation of a MySQL database manager that is used by the
Database Component.
All other libraries required are included in the java Eclipse project itself.
6.2 Usage guide
The current version of the MUSA Modeller is available in the MUSA website under Tools menu,
www.musa-project.eu. The final MUSA Modeller prototype software is also available in the public
bitbucket of MUSA as explained in next section.
The use of the MUSA Modeller will be integrated within the complete MUSA framework usage flow,
which will be explained in detail in deliverable D1.3 Initial MUSA framework implementation.
The Modeller has a simple Graphical User Interface (see Figure 20) that allows:
• Editing and saving the application models (SAVE button). The application models are stored in
the Database component for future reuse.
• Model checking for syntax correctness and integrity while editing. The tool provides messages
of warnings and errors whenever non-conformances are identified in the model (see Figure 15).
• selecting MUSA Security enforcement agents (see Figure 22). The presented agents are those
stored in the MUSA Security Agent Catalogue.
Figure 20. Modeller GUI
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 42
Figure 21. Modeller checking for syntax correctness and integrity while editing
Figure 22. Modeller support the selection of MUSA Security enforcement agents
A video explaining the usage of the Modeller can be seen in the video named “MUSA Modeller”
available at the MUSA youtube channel “MUSA project eu” here:
https://www.youtube.com/channel/UCA7mR0pU82yKPhF5jkPSlPw
The video is also available at the MUSA public website www.musa-project.eu within the Tools menu.
6.2.1 Model validation - Warnings and error messages
Model validation analysis is one of the most interesting aspects of the MUSA Modeller since end-users
get informative feedback about the validity (e.g. grammar, scoping) of the multi-cloud application
models. In this tool there are basically three different kinds of validation:
• The syntactical correctness of any textual input is validated automatically according to the
MUSA extended CAMEL DSL definition.
• Any broken crosslink or reference to other model entities is checked and resolved as well.
Similarly to syntax errors, any unresolvable crosslink is reported.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 43
• All constraints that are implied by the MUSA extended CAMEL are validated. Meeting these
constraints for a model is mandatory to be serialized. Specifically, in MUSA Modeller the
following validation checks are the most relevant:
o Duplicated entities are not allowed, that is, have entities with the same URI/name.
o In a Container, it is a must to choose a Virtual Machine (VM) belonging to the defined
Pool as manager.
o In an Internal Component to be deployed on a Container with a custom allocation
strategy, it is a must to choose a VM belonging to the defined Pool as container host.
o To ensure the completeness of the semantic model, it is a must that the necessary
Communications, Hostings and Capability Matches are properly defined and none is
missing.
Such validations are performed as users type and the corresponding error messages are shown
graphically with a red cross ( ) on the left column by the line number. Additionally, whenever a user
saves the created or updated multi-cloud application model, the Validation results report appears in a
pop-up window as it is shown in the next figure.
Figure 23. Validation report of a multi-cloud application model
6.3 Source code repository
The open source projects that implement the MUSA Modeller described above can be found in the
following MUSA bitbucket public repository:
https://bitbucket.org/account/user/musateam/projects/MUSA
Specifically, these are the five repositories that compose the MUSA Modeller:
• eu.musa.modeller.utils
• eu.musa.modeller.web-tomcat
• eu.musa.modeller.ws
• org.camel_dsl
• org.camel_dsl.dsl.parent
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 44
7 Innovation
The main innovations achieved in MUSA on secure multi-cloud application modelling mechanisms are
related to both results: the MUSA extended CAMEL language and the supporting modelling tool named
MUSA Modeller.
Regarding the improvements to the CAMEL language, as detailed in Section 4, we extended the
metamodel to improve the expressiveness of security aspects of multi-cloud applications that will be
relevant for the SLA composition afterwards. Moreover, we also provided extensions for enhancing the
expressiveness of the deployment planning itself. The deployment extensions include concepts required,
for example, in those situations when a Configuration Management tool will be used for deployment
execution and when application components will not be deployed on top of Virtual Machines but in
containers.
Regarding the innovation brought by the MUSA Modeller, as detailed in Sections 5 and 6, the major
innovation brought by the tool is that it enables the on-line edition of MUSA extended CAMEL models
by means of a Web service based on Xtext Web. Besides model edition support features, the tool
executes also model semantics verification rules and model correctness verification rules, providing
warnings and error messages to the user which facilities the model creation. Last but not least, the tool
is able to produce the Multi-cloud Application Composition Model (MACM) required by the SLA
Generation step in the MUSA workflow. This model synthesizes the application components’ type and
their relationships, together with the components relationships with the required cloud resources types
that have been expressed in the MUSA extended CAMEL model.
The following table summarises the features offered in our extended CloudML and the rationale for
including them.
Table 9. Overview of MUSA extended CloudML features
Feature Rationale
Modelling of component nature Required by the SLA Composition process within the SLA-
based Security-by-Design approach of MUSA.
Modelling of Security controls provided by
components properly supporting Security
control families.
Required by the SLA Composition process within the SLA-
based Security-by-Design approach of MUSA.
Modelling of nature of the IP address. Required in virtual machines provisioning phase.
Modelling of components deployment order. Required by deployment phase.
Modelling of data exchange protocols. Required by deployment phase.
Modelling of dynamic configurations of
communications between components.
Required in deployment where components may have
dynamic configurations.
Modelling of deployment handlers. Required in deployments managed by deployment handlers.
Modelling of PaaS layer elements. Required in deployments that use clusters of containers.
Supporting tool Web GUI Enables DevOps team to work on-line from multiple
platforms and enhances maintainability of the tool.
Supporting tool - MACM generation Required by the DST and SLA Generation process within
MUSA workflow.
Supporting tool – model correctness
validation
Ensures created CPIM model will be a correct input for the
rest of the tools in MUSA workflow.
Supporting tool – model completeness
validation
Ensures created CPIM model will be a correct input for the
rest of the tools in MUSA workflow.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 45
8 Conclusion
This document provides a description of the final security-aware multi-cloud application modelling
mechanisms and supporting prototype developed in MUSA.
The aim of this document is to explain the further extensions of CAMEL model since the initial version
described in D2.2 along with the description of the final prototype architecture and implementation
details.
The CAMEL extensions developed are related to address the concepts required to support composition
of components’ SLAs in MUSA. Other updates are related to a better definition of Security Controls
information, to properly support Security Control Framework families as different families may be used
in the SLA specification. The specification of Security controls in MUSA is needed when application
components do provide security capabilities or require them from other components. This is the case of
MUSA security enforcement agents (see deliverable D4.3). Note that, in MUSA, when components do
require security capabilities from cloud service providers this information is not captured in the
Modelling step but in the Risk Analysis.
In addition, in order to address the deployment requirements of MUSA’s use case applications, we have
extended CAMEL to enable the specification of deployments over PaaS solutions and deployments that
use Configuration Management tools like Chef.
The final prototype supporting the extended CAMEL is a Web tool integrated with the MUSA
Dashboard and available in the MUSA website and in the MUSA bitbucket repository. The tool is easily
adaptable to a standalone version that can be used as application modelling service in other frameworks
too.
One of the possibilities that was studied to increase the reusability of the created CAMEL models was
the design of the tool in a way that it could support composability of component level CAMEL models
for creating the overall multi-cloud application CAMEL model by referring to individual components’
CAMEL models. This was discarded in the end because CAMEL integrates several metamodels
(Location, Requirements, Deployment, etc.) and many cross-references would be needed between these
models at both component and application levels which would drastically reduce the usability of the
tool. Moreover, splitting CAMEL models at component level would mean completely losing
compatibility with other existing CAMEL variants.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 46
References
[1] MUSA H2020 Project, Multi-cloud Secure Applications. 2015-2017. Available at: www.musa-
project.eu
[2] MUSA H2020 Project. D1.4 Final MUSA framework specification and guide – Final version.
December 2017. Available at: www.musa-project.eu
[3] MUSA H2020 Project. D2.3 Final SbD methods for multi-cloud applications. October 2017.
Available at: www.musa-project.eu.
[4] NIST Joint Task Force and Transformation Initiative. Security and privacy controls for federal
information systems and organizations. NIST Special Publication 800, 53 (2013), 8–13.
[5] Docker Inc. Docker. Available at: https://www.docker.com/ (Retrieved October 2017)
[6] Cloudify Platform Ltd. Cloudify. Available at: http://cloudify.co/ (Retrieved October 2017)
[7] Puppet Labs: IT Automation Software for System Administrators. Puppet documentation.
Available at: https://docs.puppet.com/puppet/ (Retrieved October 2017).
[8] Chef Software Inc. Chef technology. Available at: https://www.chef.io/chef/ (Retrieved
October 2017).
[9] Docker Inc. Docker Swarm. Available at: https://docs.docker.com/swarm/ (Retrieved October
2017).
[10] Eclipse Foundation Inc. 2017. Xtext Web Editor. Available at:
http://www.eclipse.org/Xtext/documentation/330_web_support.html (Retrieved October
2017).
[11] Red Hat Inc. 2017. Hibernate framework. Available at: http://hibernate.org/ (Retrieved
October 2017).
[12] PaaSage consortium. D2.1.2 CloudML Implementation Documentation. April 2014.
Available at: http://www.paasage.eu/images/documents/paasage_d2.1.2_final.pdf (Retrieved
October 2017)
[13] PaaSage EU FP7 project. Available at: http://www.paasage.eu/ (Retrieved October
2017)
[14] CAMEL Documentation v2015.9 by PaaSage EU Project. Available at: http://camel-
dsl.org/documentation/ (Retrieved October 2017)
[15] Model-based provisioning and deployment of cloud-based systems. CloudML project.
Available at: http://cloudml.org (Retrieved October 2017)
[16] FERRY, Nicolas, et al. Towards model-driven provisioning, deployment, monitoring,
and adaptation of multi-cloud systems. En CLOUD 2013: IEEE 6th International Conference
on Cloud Computing. 2013. p. 887-894.
[17] Clément Quinton, Daniel Romero and Laurence Duchien. ‘Cardinality-based feature
models with constraints: a pragmatic approach’. In: SPLC 2013: 17th International Software
Product Line Conference. Ed. by Tomoji Kishi, Stan Jarzabek and Stefania Gnesi. ACM, 2013,
pp. 162–166. ISBN: 978-1-4503-1968-3. DOI: 10.1145/2491627.2491638.
[18] Kyriakos Kritikos, Jörg Domaschka and Alessandro Rossini. “SRL: A Scalability Rule
Language for Multi-Cloud Environments”. In: Cloud-Com 2014: 6th IEEE International
Conference on Cloud Computing Technology and Science. Ed. by Juan E. Guerrero. IEEE
Computer Society, 2014, pp. 1–9. ISBN: 978-1-4799-4093-6. DOI:
10.1109/CloudCom.2014.170.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 47
[19] Alessandro Rossini. ‘Cloud Application Modelling and Execution Language (CAMEL)
and the PaaSage Workflow’. In: Advances in Service-Oriented and Cloud Computing—
Workshops of ESOCC 2015. Ed. by Antonio Celesti and Philipp Leitner. Vol. 567.
Communications in Computer and Information Science. Springer, 2016, pp. 437–439. isbn:
978-3-319-33313-7. doi: 10.1007/978-3-319-33313-7.
[20] ARTIST project. Advanced software-based service provisioning and migration of
legacy software. Available at: www.artist-project.eu/ (Retrieved October 2017)
[21] MODAClouds consortium. D4.2.2 MODACloudML development – Final version.
September 2014. Available at: http://www.modaclouds.eu/wp-
content/uploads/2012/09/MODAClouds_D4.2.2_-
MODACloudMLDevelopmentFinalVersion.pdf (Retrieved October 2017)
[22] Creator4Clouds. Available at: http://forge.modelio.org/projects/creator-
4clouds/wiki/Creator4Clouds-Introduction (Retrieved October 2017)
[23] MODAClouds consortium. D4.3.3 MODACloudML IDE – Final Version. Available at:
http://www.modaclouds.eu/wp-
content/uploads/2012/09/MODAClouds_D4.3.3_MODACloudMLIDEFinalVersion.pdf
(Retrieved October 2017)
[24] Modelio Constellation. Available at:
https://www.modeliosoft.com/en/products/modelio-constellation.html (Retrieved October
2017)
[25] Bergmayr, A., Rossini, A., Ferry, N., Horn, G., Orue-Echevarria, L., Solberg, A., &
Wimmer, M. (2015). The Evolution of CloudML and its Manifestations. In Proceedings of the
3rd International Workshop on Model-Driven Engineering on and for the Cloud (CloudMDE)
(pp. 1-6).
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 48
Appendix A. MUSA motivation and background
The main goal of MUSA project 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.
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 49
Appendix B. CAMEL meta-model extensions in MUSA
Figure B.1: MUSA overall meta-model
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 50
Figure B.2: MUSA Deployment meta-model
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 51
Figure B.3: MUSA Organisation and Security meta-models
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 52
Appendix C. Example of TSM application CPIM
camel model TSMModel {
security model TSMSecurity{
security capability CAP_ENF_AC {
controls [MUSASEC.AC-1, MUSASEC.AC-3]
}
}
application TSMApplication {
version: 'v2.0'
owner: TUTOrganisation.test_user1
deployment models [TSMModel.TSMDeployment]
} // application TSMApplication
location model TSMLocation {
region EU {
name: Europe
}
country IE {
name: Ireland
parent regions [TSMLocation.EU]
}
country UK {
name: UnitedKingdom
parent regions [TSMLocation.EU]
}
} // TSMLocation Model
requirement model TSMRequirement {
quantitative hardware HW_2CPU_4RAM {
core: 2..4 // min and max number of CPU cores
ram: 4096..8196 // size of RAM
}
os Ubuntu {os: Ubuntu 64os}
location requirement UKReq {
locations [TSMLocation.UK]
}
location requirement IrelandReq {
locations [TSMLocation.IE]
}
} // requirement model TSMRequirement
organisation model TUTOrganisation {
organisation TUT {
www: 'http://www.tut.fi/en/home'
postal address: 'Korkeakoulunkatu 10, 33720 Tampere, Finland'
email: '[email protected]'
}
user test_user1 {
first name: test_name
last name: test_surname
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 53
email: '[email protected]'
musa credentials {
end time: 2017-12-31
username: 'mcp'
password: ''
}
}
user test_user2 {
first name: user2_name
last name: user2_surname
email: 'its email'
musa credentials {
username: 'user2'
password: ''
}
}
user group test_group {
users [TUTOrganisation.test_user1, TUTOrganisation.test_user2]
}
role devop
role assignment test_nameDevop {
start: 2016-02-26
end: 2017-12-31
assigned on: 2016-02-25
users: [TUTOrganisation.test_user1, TUTOrganisation.test_user2]
role: devop
}
role assignment test_groupDevop {
start: 2016-02-01
end: 2017-12-31
assigned on: 2016-02-25
role: devop
user groups: [TUTOrganisation.test_group]
}
security level: HIGH
} // organisation model TUTOrganisation
deployment model TSMDeployment {
// example of VMRequirementSet only applicable to a specific Component
// ------------------------------------------------
// Requirements
// ------------------------------------------------
requirement set JourneyPlannerHostRS {
os: TSMRequirement.Ubuntu
quantitative hardware: TSMRequirement.HW_2CPU_4RAM
location: TSMRequirement.IrelandReq
}
requirement set TSMEngineHostRS {
os: TSMRequirement.Ubuntu
quantitative hardware: TSMRequirement.HW_2CPU_4RAM
location: TSMRequirement.UKReq
}
requirement set ConsumptionEstimatorRS {
os: TSMRequirement.Ubuntu
quantitative hardware: TSMRequirement.HW_2CPU_4RAM
location: TSMRequirement.UKReq
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 54
}
requirement set JourneyDatabaseRS {
os: TSMRequirement.Ubuntu
quantitative hardware: TSMRequirement.HW_2CPU_4RAM
location: TSMRequirement.UKReq
}
// ------------------------------------------------
// VMs
// ------------------------------------------------
vm JourneyPlannerVM {
requirement set JourneyPlannerHostRS
provided host JourneyPlannerHost
}
vm TSMEngineHostVM {
requirement set TSMEngineHostRS
provided host TSMEngineHost
}
vm ConsumptionEstimatorVM {
requirement set ConsumptionEstimatorRS
provided host ConsumptionEstimator
}
vm JourneyDatabaseVM {
requirement set JourneyDatabaseRS
provided host JourneyDatabaseHost
}
// ------------------------------------------------
// Components
// ------------------------------------------------
internal component TSMEngine {
type: MUSACONF.SERVICE.Web
order: 4
IP public: true
required security capability CAP_AC_Req
provided communication TSMEnginePort { port: 8080 }
// COMMUNICATION with JourneyPlanner
required communication TSMEngineToJourneyPlanner { port: 8085 }
// COMMUNICATION with CEC
required communication TSMEngineToCEC { port: 9090 }
// COMMUNICATION with Database
required communication TSMEngineToDatabase { port: 5432 }
required host TSMEngineHostReq
configuration TSMEngineConfigurationCHEF {
CHEF configuration manager C1 { //Configuration Management tool
cookbook: 'tut'
recipe: 'musa_tsme'
}
}
}
internal component ACAgentForTSMEngine {
type: MUSACONF.AGENT.MUSA_AccessControl
order: 5
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 55
IP public: true
provided security capability CAP_AC {
security capability TSMSecurity.CAP_ENF_AC
}
provided communication TSMEnginePortThroughACAgent { port: 80 }
required communication MUSAMessageBrokerPortReq1 {port: 9092 mandatory}
required communication MUSAMessageBrokerPortReq2 {port: 2181 mandatory}
required host ACAgentForTSMEngineHostReq
configuration ACAgentForTSMEngineConfigurationCHEF {
CHEF configuration manager C1 { //Configuration Management tool
cookbook: 'enforcement_agents'
recipe: 'ac'
}
}
}
internal component JourneyPlanner {
type: MUSACONF.SERVICE.Web
order: 2
IP public: true
provided communication JourneyPlannerPort { port: 8085 }
required host JournayPlannerHostReq
configuration JourneyPlannerConfiguration{
CHEF configuration manager C1 {
cookbook: 'tut'
recipe: 'musa_mjp'
}
}
}
internal component ConsumptionEstimator {
type: MUSACONF.SERVICE.Web
order: 3
IP public: false
provided communication ConsumptionEstimatorPort {port: 9090}
required host ConsumptionEstimatorHostReq
configuration ConsumptionEstimatorConfiguration{
CHEF configuration manager C1 {
cookbook: 'tut'
recipe: 'musa_cec'
}
}
}
internal component JourneyDatabase {
type: MUSACONF.SERVICE.Storage
order: 1
IP public: false
provided communication DatabasePort {port: 5432}
required host JourneyDatabaseHostReq
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 56
configuration DatabaseManualConfiguration{
CHEF configuration manager C1 { //Configuration Management tool
cookbook: 'tut'
recipe: 'musa_db'
}
}
}
// ------------------------------------------------
// HOSTING
// ------------------------------------------------
hosting TSMEngineHost {
from TSMEngine.TSMEngineHostReq to TSMEngineHostVM.TSMEngineHost
}
hosting JourneyPlannerHost {
from JourneyPlanner.JournayPlannerHostReq to
JourneyPlannerVM.JourneyPlannerHost
}
hosting ConsumptionEstimatorHost {
from ConsumptionEstimator.ConsumptionEstimatorHostReq to
ConsumptionEstimatorVM.ConsumptionEstimator
}
hosting DatabaseHost {
from JourneyDatabase.JourneyDatabaseHostReq to
JourneyDatabaseVM.JourneyDatabaseHost
}
hosting ACAgentForTSMEngineHost {
from ACAgentForTSMEngine.ACAgentForTSMEngineHostReq to
TSMEngineHostVM.TSMEngineHost
}
// ------------------------------------------------
// Communication
// ------------------------------------------------
communication TSMtoJourneyPlanner {
type: ANY
from TSMEngine.TSMEngineToJourneyPlanner to
JourneyPlanner.JourneyPlannerPort
}
communication TSMeToCEC {
type: ANY
from TSMEngine.TSMEngineToCEC to
ConsumptionEstimator.ConsumptionEstimatorPort
}
communication TSMeToDatabase {
type: ANY
from TSMEngine.TSMEngineToDatabase to JourneyDatabase.DatabasePort
}
// ------------------------------------------------
// Security Capability Matching
// ------------------------------------------------
capability match TSMEngineToMUSAAgentAC1 {
from TSMEngine.CAP_AC_Req to ACAgentForTSMEngine.CAP_AC
}
D2.4: Final MUSA IDE for security-aware design of multi-cloud applications 57
} // deployment model TSMDeployment
}