Defining Generic Architecture for Cloud Infrastructure as a Service (IaaS) Provisioning Model

(1)

Defining Generic Architecture

for

Cloud Infrastructure as a Service (IaaS)

Provisioning Model

Yuri Demchenko

SNE Group, University of Amsterdam

ISOD BoF at TNC2011

16 May 2011, Prague

(2)

Outline

• Background projects

• SNE Cloud research directions

• Generic Cloud IaaS architecture • InterCloud (OS/Middleware)

• Security Infrastructure for Cloud (dynamically provisioned)

• Proposed architectural framework

• Infrastructure Services Modelling Framework (ISMF) • Composable Services Architecture (CSA)

• Service Delivery Framework (SDF)

• Defining Security Infrastructure for Clouds

• Security aspects in Cloud computing

• Dynamic Access Control Infrastructure (DACI)

• Future work

• Architecture components development

• Architectures/models matching – NIST, OASIS, DMTF, etc.

(3)

System and Network Engineering (SNE) Group at

the University of Amsterdam

• SNE group is primarily a research group but also supports SNE master education

• Main research areas

– High speed optical networks

• Recent testbed achieved sub-40Gbps at Amsterdam-CERN link

– Information modeling for network and infrastructure services description – Security and generic AAA Authorisation framework (GAAA-AuthZ)

• Evolving from client/security model to dynamically provisioned services

• Long term research cooperation with SURFnet and GigaPort programs in NL

• Re-building own testbed for optical network technologies, Cloud experiments and

AAA/Security

• Recent and current projects participation – DatGrid, NextGrid, EGEE,

Phosphorus, GEYSERS, GEANT3, NOVI

• Research on Clouds as an emerging common method to provision and access

complex infrastructure services – combining network and IT resources

– Defining architectural framework for Cloud IaaS

– Extending it for Cloud Security infrastructure and defining basic security and trust models

(4)

Use case for Infrastructure Services Provisioning

ISOD BoF @ TNC2011 Cloud IaaS Architetcure Framework 4

Project based collaborating user groups located in remote campuses on data intensive

projects requiring high performance computing and rich visualisation

Campus infrastructure including visualisation tools Control & Monitoring Sc. Instrument (Manufactrg) Grid Storage T1 Grid CE Data Filtering Grid Storage T0 Grid VO-A Visuali- sation User Group A User CE Campus A Visuali- sation User CE _User Group B Campus B CE CE CE SE SE CSE CSE CSE CSE CloudSE T1 CE Processed Data Experimental Data Specialist Data Processing Project based Cloud Infrastructure Data Filtering Ctrl&Mngnt Plane

Grid based core e-Science Infrastructure including data intensive scientific instrument

Cloud

infrastructure provisioned on demand

(5)

Proposed Architectural Framework for Cloud IaaS

The proposed framework should support on-demand infrastructure services provisioning and operation

• Infrastructure Services Modeling Framework (ISMF) that provides a basis for

the infrastructure resources virtualisation and management, including description, discovery, modeling, composition and monitoring

• Composable Services Architecture (CSA) that intends to provide a conceptual

and methodological framework for developing dynamically configurable virtualised infrastructure services and Cloud middleware

• Service Delivery Framework (SDF) that provides a basis for defining the whole

composable services life cycle management and supporting infrastructure services

• (Additionally) Service Control and Management Plane/Framework may be

defined as a combination of management functionality in all 3 components

• (Additionally) Security services/infrastructure have a dual role:

– Virtual Security Infrastructure - provisioned as a part of virtualised infrastructure – Support secure operation of the whole provisioning framework

(6)

IaaS Abstract Model

User/ Applic B User/ Applic A _VIR3 VIR4 VIR5 VIR6 VIR2 VIR1 VI Operator Layer

PIP1 PIP2 PIP3 PIP4

Virtual Infrastructure (VI) (operated by VIO1)

VIProvider2 ND-PIP1 ND-VIP1 ND-PIP2 ND-PIP3-PIP4 ND-VIP2 ND-VIO1 UserND-A UserND-B PI Provider Layer (PR Layer) VI Provider Layer (VR/LR Layer) VIProvider1

VI/VR Adaptation Layer

Pi/PR Adaptation Layer

Pi/PR Layer Com p o sitio n Lo g ical Rsr AAI/Policy Security SLC Metadada Application/Service Layer Ctr l & M n g n t (Or ch e str a t n )

Logical Abstraction Layer

Security Context Resource

Config

VI Comp & Mngnt Layer (VICM)

VR1 VR2 VR3 VR4 VR5 _VR6 VIO1 SLA/ SLM Legend ND* - Network Domain

VIR* - VI Resource (deployed) VR – Virtual Resource

LR – Logical Resource PR – Physical Resource

(7)

Virtual Infrastructure Composition and Management

(VICM) Layer Operation

• Main actors involved into provisioning process

– Physical Infrastructure Provider (PIP) – Virtual Infrastructure Provider (VIP) – Virtual Infrastructure Operator (VIO)

• Virtual Infrastructure Composition and Management (VICM) layer includes

– VICM middleware - defined as CSA

– Logical Abstraction Layer and the VI/VR Adaptation Layer facing correspondingly lower PIP and upper Application layer.

• The infrastructure provisioning process includes the following main SDF stages

– (1) virtual infrastructure creation request

– (2) infrastructure planning and advance reservation;

– (3) infrastructure deployment including services synchronization and initiation; – (4) operation stage

– (5) infrastructure decommissioning

• VICM redefines Logical Infrastructure Composition Layer (LICL) proposed by

GEYSERS project

– Basic functionality is implemented as GEMBus/CSA

(8)

ISMF – Virtual Resource Lifecycle

{LR0} -> LR2 Planning Composition Reservation LR2 -> VR VI Deployment Ph y s ic a l Res o u rc e L o g ic a l Res o u rc e Vi rtu a l Res o u rc e Network Segment Network Segment LR0 Re-usable (Published) PRs Topology Pool Network Segment PR-LR1 Config& Instantiation Registered PRs Composed LRs Deployed VRs . Virtu al In fra s tru c tu re PIP1 PIP2

(9)

ISMF - Relation between PR-LR-VR-VI

• Virtual Resource lifecycle – defines relations between different resource presentations along the provisioning process

• Physical Resource information is published by PIP to the Registry service serving VICM and VIP

– Logical Resource representing PR includes also properties that define possible (topological) operations on the PR, such as e.g. partitioning or aggregation.

• Published LR information presented in the commonly adopted form (using common data or semantic model) is then used by VICM/VIP composition service to create requested infrastructure as combination of (instantiated) Virtual Resources and interconnecting them with the available network infrastructure

• Network infrastructure can be composed of a few network segments (from the network topology pool) run by different network providers.

• Composed LRs are deployed as VRI/VI to VIP/VIO and as virtualised/instantiated PR-LR to PIP

• Resource/service description format considered

– NDL/NML (Network Description Language / Network Markup Language at OGF) – USDL (Unified Services Description Language) at W3C

– VXDL infrastructure service request format by INRIA

(10)

Composable Services Architecture (CSA)

• Defined as middleware for on-demand provisioned

Composable Services

• Proposed in the GEANT3 JRA3 Composable Services

project

• Implemented as GEMBus (GEANT Multidomain Bus)

(11)

Composable Services Layered Model

– Application Layer hosts application related protocols

– GEMBus Messaging Infrastructure (GMI) includes

• Messaging Layer • Virtualisation

(Composition&Orchestration) Layer

– Network&Transport Layer should allow using/binding to standards

communication and security protocol – Composable services are defined as

“dynamically re-configured

virtualised services” according to OSIMM model for SOA

ISOD BoF @ TNC2011 Cloud IaaS Architetcure Framework Slide_11

Application Layer

Virtualisation Layer

Messaging Layer

Network&Transport Layer

Logical Abstraction Layer Composition & Orchestration Layer

(12)

Composable Services Architecture – Version 0.13

Applications and User Terminals

Composition Layer/Serv

(Reservation SLA

Negotiatn)

Logical Abstraction Layer for

Component Services and Resources Control &

Management Plane

(Operation, Orchestration)

Composable Services Middleware (GEMBus) Network Infrastructure Compute Resources Storage Resources

Component Services & Resources

Proxy (adaptors/containers) - Component Services and Resources Proxy (adaptors/containers) – Composed/Virtualised Services and Resources

MD SLC Registry Logging Security User Client Composable Services lifecycle/provisioning stages (1) Request (2) Composition/ Reservation (3) Deployment (4) Operation (5) Decommissioning Control/ Mngnt Links Data Links

(13)

Composable Services Lifecycle/Provisioning

Workflow

• Main stages/phases

(1) Service Request (including SLA negotiation) (2) Composition/Reservation (aka design) (3) Deployment, including Reqistration/Synchronisation (4) Operation (including Monitoring) (5) Decommissioning • Additional stages

– Re-Composition should address incremental infrastructure

changes

– Recovery/Migration can use SL-MD to initiate resources

re-synchronisation but may require re-composition

• The whole workflow is

supported by the Service

Lifecycle Metadata Service (SL MD)

•

Service Request/ SLA Negotiation Composition/ Reservation Deployment Operation (Monitoring) Decommissioning Registr&Synchro Recovery/ Migration Re-Compo sition Service Lifecycle Metadata Service (SL MD) Provisiong Session Managnt

(14)

Composable Services Architecture – Version 0.13

Lifecycle stages workflow

Composable Services lifecycle/provisioning stages (1) Request (2) Composition/ Reservation (3) Deployment (4) Operation (5) Decommissioning MD SLC – Service Lifecycle Metadata GEMBus – GEANT Multidomain Bus GESB – Geysers ESB

Control/ Mngnt Links

Data Links

Applications and User Terminals

Composition Layer /Serv

(Reservation SLA

Negotiatn)

Logical Abstraction Layer for

Component Services and Resources Control & Management Plane (Operation, Orchestration) Composable Services Middleware (GEMBus/GESB) Network Infrastructure Compute Resources Storage Resources

Component Services & Resources

Proxy (adaptors/containers) - Component Services and Resources Proxy (adaptors/containers) – Composed/Virtualised Services and Resources

MD SLC _Registry _Logging _Security User Clien t 1 1 2 2 2 2 2 3 3 3 3 3 3 4 2 4 4 4 4 4 Serv Serv Serv

(15)

CSA functional elements interaction

• (1) Request

– User Client -> Control and Management

• (2) Composition/ Reservation

– Control&Mngnt -> Registry -> Composition/Reservation Serv -> (Logical

Abstract -> Resr Adapters) -> LC Metadata Serv

• (3) Deployment

– Control&Mngnt -> Composition/Reservation Serv -> (Logical Abstract -> Resr

Adapters) -> LC Metadata Serv -> User Client

• (4) Operation

– User Client -> Control&Mngnt (Orchestration) -> Rsr Adapters ->

Virtualised/Composed Applications

• (5) Decommissioning

– Control&Mngnt -> LC Metadata Serv -> (Logical Abstract -> Resr Adapters)

(16)

GEMBus Infrastructure for Composable Service

GEMBus provides common dynamically configurable messaging infrastructure for Composable services communication

GEMBus Infrastructure Services GEMBus Component Services

Service 2 (CSrvID, SesID) GEMBus Registry Composition & Orchestration Logging Service Service 1 (CSrvID, SesID) Service 3 (CSrvID, SesID) Service 4 (CSrvID, SesID) GEMBus GEMBus Messaging Infrastructure (GMI) Routing Configur ation Interceptors (AspOrient) Security Service Message Handling

(17)

Example Service Composition – Service NX

• CSrvID, SesID – bind component services into the on-demand provisioned

Composed service NX

Role and place for Composition and Orchestration * Composable services or GEMBus infrastructure service UserClient (CSrvID,SesID) Service 4 (CSrvID,SesID) Service 3 (CSrvID,SesID) Service 1 (CSrvID,SesID) Service 2 (CSrvID,SesID) UserClient (CSrvID,SesID) Frontend CompSrvNX (CSrvID,SesID) Service 4 (CSrvID,SesID) Service 3 (CSrvID,SesID) Service 1 (CSrvID,SesID) Service 2 (CSrvID,SesID) Composed Service NX (CSrvID,SesID) Composed Service NX (CSrvID,SesID) User Interface

(18)

Defining Security Infrastructure for Clouds

• Security aspects in Cloud computing

• Dynamic Access Control Infrastructure (DACI)

– DACI implementation in GEYSERS for infrastructure services

(network + IT) provisioning on demand

(19)

General security services/aspects



Access Control (including AuthN, AuthZ, Identity

Management)



Trust Management (including key management)



Policy Based Management (PBM)



Data protection (Confidentiality, Integrity, Access Control)

– Communication Security

– Privacy (complex of measures and policy based access

control)

(20)

Cloud Security – Problem area and issues

• Virtualised services

• On-demand/dynamic provisioning

• Multi-tenant/multi-user

• Multi-domain

• Uncontrolled execution and data storage environment

– Data protection

• Trusted Computing Platform Architecture (TCPA) • Promising homomorphic/elastic encryption

• Integration with legacy security services/infrastructure of

providers

• Integration with the providers’ business workflow

(21)

Current Cloud Security Practice

• SLA based security model

– SLA between provider and user defines the provider responsibility and guarantee

– Providers undergo certification – Standard business model

• Using VPN and SSH keys generated for user infrastructure/VMs

– Works for single Cloud provider

• Has inherited key management problems

• Not easy integration with legacy physical resources

• Not scalable

• Simple access control, however can be installed by user

• Trade-off between simplicity and manageability

(22)

Emerging Cloud Security Models

• Former (legacy): Provider - User/Customer

• New Cloud oriented security provisioning models

– Provider - Customer - User

• Enterprise as a Customer, and employees as Users

– Provider – Operator (Broker) - Customer – User

• Application area IT/telco company serves as an Operator for

application services infrastructure created for customer company

• Security issues/problems in new security

provisioning models

– Integration of the customer and provider security services

– Identity Management and Single Sign On (SSO)

• Identity provisioning for dynamically created Cloud based

infrastructure or applications

(23)

Security Infrastructure for IaaS –

Dynamic Security Association (DSA)

User/ Applic B (TA0.B) User/ Applic A (TA0.A) VIR3 VIR4 VIR5 VIR6 VIR2 VIR1 VI Operator Layer TA1.x PIP1(TA3.1)

Virtual Infrastructure (VI) (operated by VIO1)

TD-PIP1 TD-VIP1 TD-PIP2 FedTD-PIP3-PIP4 TD-VIP2 TD/DSA VIO1 User B Trust Domain PI Provider (PR) Layer TA3.x VI Provider (VR/LR) Layer TA2.x

VI/VR Adaptation Layer

Pi/PR Adaptation Layer

Pi/PR Layer Com p o si ti o n L o g ica l Rsr AAI/Policy Security SLC Metadada Application/Service Layer Ctr l & M n g n t (Or ch e str a tn )

Logical Abstraction Layer

Security Context Resource

Config

VI Comp & Mngnt Layer (VICM)

VR1 VR2 VR3 VR4 VR5 _VR6

VIO1 (TA1, DSA)

SLA/ SLM

PIP1(TA3.2) PIP1(TA3.3) PIP1(TA3.4)

User B Trust Domain

DSA

Legend

- DSA Security Context/ Configuration

TD* - Trust Domains

DSA – Dynamic Security Assoc. VIR* - VI Resource (deployed) VR/LR/PR – Virtual/Logical/ Physical Resource

VIProvider1 (TA2.1) VIProvider2 (TA2.2)

(24)

Security Context management during provisioning

Dynamic Access Control Infrastructure (DACI)

VIO VIP VIP DACI/AAI

VI reservation request (including VIO TA1)

AuthZ request (VI-GRI)

PIP(s)

Mapping from the returned PR-LRI to VR-GRI for VIP

Reserve complex resource at PIP(s) in daisy-chain mode or concurrent mode VR reservation request

(including VIP TA2)

Reservation confirmation with PR-LRI of committed PR

VI reservation response with a VI-GRI and set of VR-GRI(s)

Generate a VI-GRI

PIP AAI

AuthZ request (PR-LRI)

User/Applicatn

VI/VR Request (TA0) SLA Negotiation

SDF Stages

VR’s . PR’s

DACI

Deployment stage – VI/VR Configuration, DACI configuration and Security context distribution

Operation stage – VI/VR Management, Monitoring, DACI operation and security context management

Dec``ommissioning stage – VI/VR teardown, resources release, security context recycling

SLA Negotiation Planning, Reservation Deployment, Activation Operation Decommissioning Generate GRI Return GRI

(25)

Dynamic Access Control Infrastructure (DACI)

Lifecycle stages

(1) Request (GRI, UserID, VIO-ID,

(SLA))

(2) Reservation (Reservation session,

SecContext)

(3) Deployment (DSA creation,

configuration)

(4) Operation (Access Session,

SecContext)

(5) Decommissioning (DSA, Creds/key

recycle, Sessions termination)

VIO VIP VIP DACI/AAI

VI reservation request (including VIO TA1)

PIP(s)

Mapping from the returned PR-LRI to VR-LRI for VIP Reserve complex resource at PIP(s) in daisy-chain mode or concurrent mode

VR reservation request (including VIP TA2) Reservation confirmation with PR-LRI of committed PR

VI reservation response with a VI-GRI and set of VR-LRI(s)

Generate a VI-GRI

PIP AAI

AuthZ request (PR-LRI)

User/Applicant

VI/VR Request (TA0) SLA Negotiation SLA Negotiation Planning, Reservation Generate GRI Return GRI VI deployment/activation

request DACS instantiate (VI-GRI)

Deploy VRs at the PIP (PR-LRIs) Deploy VRs at

PIP(s) in daisy-chain mode or

concurrent mode VR deployment response

VI deployment notification VI deployment notification

Deployment, Activation stage

VI/VR Configuration, DACI configuration and Security context distribution VR DACS PR Access VR(PR-LRI) Access PR Access VR(VR-LRI)

Authz request (VR-LRI) Authz response

Operation

Decomission VI (VI-GRI)

Decommision VRs at the PIP (PR-LRIs) For each PIP

providing VRs of the VI

Decomission DACS (VI-GRI) Decomission VI notification Decomission VI notification Decommissioning VI/VR teardown, resources release, security context recycling VI/VR Management, Monitoring, DACI operation and security context management Decomission VR notification

(26)

DACI at (2) Reservation stage

• Operated with AAI of VIO, VIP, PIP

• Collect and distribute components’ Trust Anchors

(27)

DACI at (3) Deployment stage

• DACI created: configured, bootstrapped, initiated

(28)

DACI at (4) Operation stage

• AuthN/AuthZ services of VI operated by DACI

• PIP AAI either

(29)

DACI at (5) Decommissioning stage

• Sessions termination, global sign-out/logout

• Key recycle, session credentials invalidation, cache purge

(30)

AAI in GEYSERS

Basic CSSI services

• Data encryption

• Digital signature

• Authentication

• Authorization

• Policy management

• Security session and context

management

Called from services (or part of core interfaces) • SLI (SML-LICL) • CCI (NCP-LICL) • NLI (NCP-LICL) • LPI (LICL-PHY) • NIPS-UNI SML NCP LICL VITM NIPS Server CCI NIPS-UNI SLI NLI PHY LPI GEY SER S Sec urit y (AAI ) CSSI

(31)

PEP: Policy Enforcement Point PDP: Policy Decision Point PAP: Policy Administration Point

DACS: Dynamic Access Control Service

AAI Reference Mode

l (GEYSERS)

AuthN Service PDP PAP AuthN DB Token Validation Service (TVS) SecCtx Handler AAI Gateway PEP Dyn AC Service Mngnt

Common Security Services Interface (CSSI)

Config, Attr Trust/Key

Mngnt

(32)

Implementation suggestions (GEYSERS DACI)

• Extend GAAA-Toolkit library to support dynamic Security/AAI

infrastructure creation and integration with provisioned VI

– Provides GAAA Authorisation API (GAAAPI) functions with extended AuthZ and session management functionality

• Support for SDF workflow and Security Services Lifecycle Mngnt

– Needs general infrastructure services such as Metadata SLM

• Define and implement Common Security Service Interface (CSSI)

– Supports both internal applications calls and Web service integration via Spring security

– Implements GSS-API and extends it with GAAAPI functionality

• Use standard Messaging, Transport and Network security

mechanisms provided by implementation platform

• Implementation platform specific – ESB/WS/SOA (Fuse, Apache

ServiceMix, etc.)

(33)

Future Research

• Architectures/models matching

– First, which are on the standard track

• NIST, OASIS, DMTF, IETF

– Next, proposed by industry and consortia

• IBM, Cisco, Juniper, Extreme Networks

• Basic terms and concepts definition/re-visiting

– Dynamic vs On-Demand

– Infrastructure services vs (Computer) Services

• ISMF definition

(34)

Planned Activities

• Further development of the proposed architectural

components in GEANT3 and GEYSERS projects

– Demo at SuperComputing 2011 conference and exhibition

• Dynamically provisioned security infrastructure

– Dynamic security association

• Contribution to OGF ISOD-RG activity

– Next meeting OGF32 Salt Lake City, USA (16-18 July 2011), OGF33

Lyon, France (19-23 September 2011)

• CloudCom2011 Conference November 29 –December 2,

2011, Athens

– Focus on Cloud Architecture research

• EU wide cooperation and possible new EU projects

(35)

Additional Information

• Security Services Lifecycle Management (SSLM)

model

(36)

Security Services Lifecycle Management Model

Specific SSLM stages and mechanisms to ensure consistency of the security context management

• Security Service Request that initiates creation of the dynamic security association and may use SLA security context.

• Reservation Session Binding with GRI (also a part of general SDF/SLM) that provides support for complex reservation process including required access control and policy enforcement.

• Registration&Synchronisation stage (as part Deployment stage) that allows binding the local resource or hosting platform run-time process ID to the GRI as a provisioning session ID. Specifically targets possible scenarios with the provisioned services migration or

restoration. Service Request (GRI) Planning Design Reservation

Deployment Operation _Monitoring Decom- _missioning

Operation Monitoring Decommis Key Recycle Resrv Session Binding SecServ Request Deploy Rtm Bind Bootstr Reqistr Synchron B) Service Lifecycle

(37)

Relation between SSLM/SLM stages and supporting general and

security mechanisms

SLM stages

Request Design/Reservatio

n Development

Deployment Operation Decomissio

ning Process/ Activity SLA Nego tiation Service/ Resource Composition Reservation Composition Configuration Orchestration/ Session Management Logoff Accounting

Mechanisms/Methods (M – mandatory; O - optional)

SLA M M Workflow (O) M Metadata M M M M Dynamic Security Associatn (O) M M AuthZ Session Context M (O) M