Policing autonomic clouds

Andrea Margheri Francesco Tiezzi

Irfan Khan Tanoli Vitaly BuravlevYuriy Zacchia Lun Alessandro Maggi

ASCENS Spring School on Engineering Collective Autonomic Systems

Lucca, March 27, 2015

www.ascens-ist.eu

The case study: Autonomic Cloud

LMU Munich

SCPi

SCPi

SCPi

MunichEnglish Garden

SCPi

IMT Lucca

SCPi

SCPi

SCPi

PaaS volunteer cloud that provides aruntime platform for applications

Realised as collection of notebooks,desktops, servers, or VMs runninginstances of Science Cloud Platform

It relies on autonomic nodes todeal with leaving and joining nodes,fluctuating load, hw/sw requirements

ASCENS Spring School 2

Autonomic Cloud: issues

In this project we had to face the following issues:

Authorisation: checking principal’scapabilities

Confidentiality of Data: avoidingviolation of the confidentiality model

Resource Management:allocating applications correctly

Adaptation Mechanism:self-adaptation to ensure SLAs

ASCENS Spring School 3

Goal of the Project

create some FACPL policies thought of asbeing deployed on every Science CloudPlatform instances

manage the following aspects of the platform:

the level of trust of each componentplatform actions, resources, and applicationsuser credentials and profileself-adaptation to ensure application SLAs

pass (possibly all) tests that have been defined

ASCENS Spring School 4

FACPL ToolChain

ASCENS Spring School 5

FACPL Eclipse IDE

ASCENS Spring School 6

FACPL Evaluation Process

ASCENS Spring School 7

The FACPL Policy Language

Language elements

Rule: positive (or negative) basic authorisation controls

Policy: list of rules

PolicySet: list of policies

Obligation: additional action calculated by policies

Rules specify

effect: permit (or deny) consequence of the rule

target: condition indicating the applicability of the rule

obligations

Obligations are run-time generated actions used foracting on the policed system and enforcing adaptation strategies

ASCENS Spring School 8

The FACPL Policy Language

Language elements

Rule: positive (or negative) basic authorisation controls

Policy: list of rules

PolicySet: list of policies

Obligation: additional action calculated by policies

Rules specify

effect: permit (or deny) consequence of the rule

target: condition indicating the applicability of the rule

obligations

Obligations are run-time generated actions used foracting on the policed system and enforcing adaptation strategies

ASCENS Spring School 8

The FACPL Policy Language

Language elements

Rule: positive (or negative) basic authorisation controls

Policy: list of rules

PolicySet: list of policies

Obligation: additional action calculated by policies

Rules specify

effect: permit (or deny) consequence of the rule

target: condition indicating the applicability of the rule

obligations

Obligations are run-time generated actions used foracting on the policed system and enforcing adaptation strategies

ASCENS Spring School 8

Access Control - Setting

ASCENS Spring School 9

Access Control - Confidentiality

”high” trust users can interact with both ”low” and ”high” trustinstances (unless strict access requested)

”low” trust users can only interact with ”low” trust instances

ASCENS Spring School 10

Access Control - Confidentiality

ASCENS Spring School 11

Access Control - Authorisation

users with profile P Usr can only add Usr Type APPs

users with profile P Adm can add both types

ASCENS Spring School 12

Access Control - Authorisation

ASCENS Spring School 13

Resource Allocation

Each SCP instance has limited computing resources

a free SCPi has 10 units of available resources;

a Sys Type APP consumes 1 unit of resource;

a Usr Type APP consumes 2 units of resource;

ASCENS Spring School 14

Adaptation - System Apps

can be instantiated unless no resources available

can be executed only from 1.00 a.m. to 6.00 a.m. (freeze otherwise)

ASCENS Spring School 15

Adaptation - System Apps

ASCENS Spring School 16

Adaptation - User Apps

user apps are executed locally if resources available or obtainable (byfreezing system apps) on instanceotherwise they are added to another instance with available resourcesif no SCPi available, run on a new SCP instance

ASCENS Spring School 17

Adaptation - User Apps

ASCENS Spring School 18

Adaptation - Big Picture

ASCENS Spring School 19

School Testing Environment

ASCENS Spring School 20

Extra requirements and scenarios

Language elements

reactivation of frozen apps

managing removal of a SCPi

handling exceptional behaviours: Break-the-Glass approach

ASCENS Spring School 21

Extra requirements and scenarios

Language elements

reactivation of frozen apps

managing removal of a SCPi

handling exceptional behaviours: Break-the-Glass approach

ASCENS Spring School 21

Extra requirements and scenarios

Language elements

reactivation of frozen apps

managing removal of a SCPi

handling exceptional behaviours: Break-the-Glass approach

ASCENS Spring School 21

Break-the-Glass

model Exception behaviour and Regular behaviour as twonon-interfering PolicySets

select appropriate PolicySet according to exception attribute of thesystem

Malicious APP: exception PolicySet allows explicit freeze of both app types

System update: allow freezing of all apps and execution of Sys Type apps(regardless of time)

ASCENS Spring School 22

Break-the-Glass

model Exception behaviour and Regular behaviour as twonon-interfering PolicySets

select appropriate PolicySet according to exception attribute of thesystem

Malicious APP: exception PolicySet allows explicit freeze of both app types

System update: allow freezing of all apps and execution of Sys Type apps(regardless of time)

ASCENS Spring School 22

Break-the-Glass

model Exception behaviour and Regular behaviour as twonon-interfering PolicySets

select appropriate PolicySet according to exception attribute of thesystem

Malicious APP: exception PolicySet allows explicit freeze of both app types

System update: allow freezing of all apps and execution of Sys Type apps(regardless of time)

ASCENS Spring School 22

Conclusions

Through this small workshop focused on learning the basics of the FACPLlanguage for policies specification we managed to:

define correct policies satisfying the requirements in a short amountof time

handle complex scenarios in terms of pre-conditions andpost-conditions

design hierarchical compositions of different policies allowing for anhigher degree of adaptability

Easy-to-use, intuitive language

Expressive language

Scalable language

ASCENS Spring School 23

Conclusions

Through this small workshop focused on learning the basics of the FACPLlanguage for policies specification we managed to:

define correct policies satisfying the requirements in a short amountof time

handle complex scenarios in terms of pre-conditions andpost-conditions

design hierarchical compositions of different policies allowing for anhigher degree of adaptability

Easy-to-use, intuitive language

Expressive language

Scalable language

ASCENS Spring School 23

Conclusions

Through this small workshop focused on learning the basics of the FACPLlanguage for policies specification we managed to:

define correct policies satisfying the requirements in a short amountof time

handle complex scenarios in terms of pre-conditions andpost-conditions

design hierarchical compositions of different policies allowing for anhigher degree of adaptability

Easy-to-use, intuitive language

Expressive language

Scalable language

ASCENS Spring School 23

Conclusions

Through this small workshop focused on learning the basics of the FACPLlanguage for policies specification we managed to:

define correct policies satisfying the requirements in a short amountof time

handle complex scenarios in terms of pre-conditions andpost-conditions

design hierarchical compositions of different policies allowing for anhigher degree of adaptability

Easy-to-use, intuitive language

Expressive language

Scalable language

ASCENS Spring School 23

Thank you

for your attention!

ASCENS Spring School 24