1 grid workshop – toulouse ias – october 20th ground segment & products department globus...

1

GRID Workshop – Toulouse IAS – October 20thGRID Workshop – Toulouse IAS – October 20th

Ground segment & products Department Ground segment & products Department

Globus TK4 experiment for image data Globus TK4 experiment for image data processing : processing :

security architecture, security architecture, Cnes feedbacksCnes feedbacks

Anne Jean-Antoine PiccoloAnne Jean-Antoine Piccolo

Globus TK4 experiment for image data Globus TK4 experiment for image data processing : processing :

security architecture, security architecture, Cnes feedbacksCnes feedbacks

Anne Jean-Antoine PiccoloAnne Jean-Antoine Piccolo

2



Introduction Introduction

A Grid architecture is such a distributed architecture.

From a logical view, 4 sub–systems compose a grid: administration (software and hardware allocation & administration, VO management) job management (user requests analysis, resource allocation & status monitoring,

workflow execution) job processing (storage and processing facilities, file handlers, data transfer tools) security (user access control, data flow security, event monitoring).

Here, we focus on the security subsystem.

Specific security requirements analysis derived from CNES high level security requirements applicable to a CNES designed system defined on a distributed architecture allowing

users from different organizations : - to work according to a collaborative schema- to share resources.

3



Grid overall architecture (target)Grid overall architecture (target)Grid overall architecture (target)Grid overall architecture (target)

Workflow

Portal / Authentication

CatalogFormat RequestScheduler BrokerAuthorization VO Admin

Workflow

Portal / Authentication

CatalogFormat RequestScheduler BrokerAuthorization VO AdminCatalogFormat RequestScheduler BrokerAuthorization VO Admin

4



Security studies : the following methodology Security studies : the following methodology

CNES led security studies based on the previous target architecture according to the classical methodology :1. Consequences assessment : comparison between security criteria

(availability, integrity, confidentiality, imputability) and sensitive levels (no impact, minor, major, critical, vital) for user data, grid management data and security data.

2. Threads analysis.

3. Risks analysis and a first security objective definition in term of network security, data and software integrity, processing control & monitoring, I&A, authorization, data flow, data protection, and so on …

4. Risks covered by security objectives ?

5. Security architecture : a first proposal => functional requirements in term of security (ISO/IEC 15408)

6. List of non recovered risks

5



Global security needs to be reached Global security needs to be reached

Needs issued from « Virtual Organization » : Protection of their resources (user data and software), Availability of the grid infrastructure hosting their resources (for

user request processing).

Needs issued from providers of grid resources : Grid resource under full control of local administrators, Security of resources which are not provided for grids => need to

isolate these resources regarding grid ones.

6



Identification of Grid Context (1/2)Identification of Grid Context (1/2)Identification of Grid Context (1/2)Identification of Grid Context (1/2)

Grid use cases : user requests for accessing computing software implemented on CNES machines

Previously known resources (software or data) before request processing, Resources have to be dynamically allocated step by step.

user requests for accessing VO resources (software, data) and CNES resources (servers) resulting in data backward transfers (e.g. computing results) : a command flow in input and a data flow in output,

user requests for accessing resources (software, data) located outside CNES.

Resulting security concerns authentication of user requests and of jobs running on behalf of the user, integrity of software and data implemented on CNES resources, control of dynamically accessed resources, data in/out transfers, isolation of CNES resources regarding VOs, except of resources formally designated as

accessible to users.

7



Identification of Grid Context (2/2)Identification of Grid Context (2/2)Identification of Grid Context (2/2)Identification of Grid Context (2/2)

Resource classification systems supporting tools and services devoted to grid utilization systems devoted to grid management: authentication, authorization, allocation,

information user workstations located outside CNES network protocols for

- Calling remote request - Cascading authentication (SSL/TLS with delegation)- Routing and localization service or node (OSPF, DNS)- Transferring files (e.g. ftp, gridftp)- Transferring data (e.g. http/SOAP)- Accessing security data (e.g. LDAP)- Information notification- communications between grid management services (depend on the grid middleware)

8



Architecture overview : CS recommandationsArchitecture overview : CS recommandationsArchitecture overview : CS recommandationsArchitecture overview : CS recommandations

Client

HTTPS (SOAP)

Remote Serveur

HTTPS (SOAP)VO Administrator

• • Firewall 1 • •

Proxy ServerAuthentification

data

HSMEncryption

timestamps


Proxy Authentification

Authentification data




Exchange file services

Configuration data

Access databased’autorisation

Services and data repository

Globus MDS

Remote Serveur

LDAP

LDAP ClientExchange Services for

remote sites

Remote SitesVO Administrator

Cluster (LSF, NQS, ...)Stockage (VTD, SRB, ...) Cluster (LSF, NQS, ...)

GRAM (Globus)program toolkit

GridFTP Grid MapFile NWS Network weather system

Authorisation

Request analysis

CoG-Core

CONDOR

Formatexchange

Routage

Catalogues

VO Administration

Locator foravailable services

Accounting Task control

andmonitoring

LL

Client

HTTPS (XHTML)

• • Firewall 7 (optionnal) • •

VTD


LocalAdministration

Client

HTTPS (SOAP)

Remote Serveur

HTTPS (SOAP)VO Administrator


Proxy ServerAuthentification

data

HSMEncryption

timestamps


Proxy Authentification

Authentification data




Exchange file services

Configuration data

Access databased’autorisation

Services and data repository

Globus MDS

Remote Serveur

LDAP

LDAP ClientExchange Services for

remote sites

Remote SitesVO Administrator

Cluster (LSF, NQS, ...)Cluster (LSF, NQS, ...)Stockage (VTD, SRB, ...) Cluster (LSF, NQS, ...)Cluster (LSF, NQS, ...)

GRAM (Globus)program toolkit

GridFTP Grid MapFile NWS Network weather system

Authorisation

Request analysis

CoG-Core

CONDOR

Formatexchange

Routage

Catalogues

VO Administration

Locator foravailable services

Accounting Task control

andmonitoring

LL

Client

HTTPS (XHTML)

• • Firewall 7 (optionnal) • •

VTD


LocalAdministration

9



Chistera over Globus GT4 : experiment configurationChistera over Globus GT4 : experiment configurationChistera over Globus GT4 : experiment configurationChistera over Globus GT4 : experiment configuration

TEC CALIPSO

Gestion des données

Réseau interne CNES

Solex Imalise1

Imalise2 PC-Firewall

CNES local network

IPCOP

Objective : to experiment Globus through a firewall and test the security architecture feasibility (simulate an extra grid).

10



Summary of traffic characteristics for Globus GT4Summary of traffic characteristics for Globus GT4Summary of traffic characteristics for Globus GT4Summary of traffic characteristics for Globus GT4

If Globus is behind a firewall then some ports need to be opened : 2119 (gatekeeper), 2811 (gridftp) and 2135 (GIS).

Globus will also need a range of ports opened for GASS (Global Access to Secondary Storage) to inform Globus of the port range you need to set the GLOBUS_TCP_PORT_RANGE variable in “xinetd” files and user

start up scripts.

The size of the port range depends on how many services are expected – generally a range of couple of thousand should be necessary.

11



Summary of traffic characteristics for Globus GT4Summary of traffic characteristics for Globus GT4Summary of traffic characteristics for Globus GT4Summary of traffic characteristics for Globus GT4

Application Network Ports

GRAM Gatekeeper ( To start job)

To 2119/tcp on server from CEP on client.

GRAM J ob Manager

From CEP on client to CEP on server.

GridFTP

From CEP on client to port 2811/tcp on server for control channel. From CEP on server to CEP on client for data channel

Web Services

To 8443/tcp on server from ephemeral port on client.

(*) CEP: Controllable ephemeral port

(*) TCP Transmission Control protocol

12



A Chistera processing demonstrationA Chistera processing demonstrationA Chistera processing demonstrationA Chistera processing demonstration

CHISTERA Processing

Synoptic of High Resolution Processing

High resolution product

Intermediate product

Intermediate product

Integrated into the Spot 5 user ground segment

13



Chistera monitoring using GRAM CommandsChistera monitoring using GRAM CommandsChistera monitoring using GRAM CommandsChistera monitoring using GRAM Commands

Master Image splitting

Data sending and command monitoring

Image gathering and assembly

Data Reception

Commands monitoring

CHISTERA treatment

Results sending

Data transfer : globus-url-copy

Control transfer : globus-job-run

Slaves

Data Reception

Command monitoring

CHISTERA treatment

Result sending

14




Master GT4 Client

Data transfer : globus-url-copy

Remote Processing : globus-job-run

Slaves

GRAM ServerGridFTP Server

GRAM ServerGridFTP Server

15




TEC CALIPSO



Solex Imalise1


Open Ports:CEP

CNES internal network

16



Chistera monitoring using web services WSRFChistera monitoring using web services WSRFChistera monitoring using web services WSRFChistera monitoring using web services WSRF

Master Image splitting

Creation of job descriptions (XML)

XML files sending

Assembly

XML file reception

Container processing

XML file reception

Container processing

XML job submission : globusrun-ws

Slaves/Containers

17




Master GridFTP Server

GT4 Client

GT4 web service container

GT4 web service container

Soumission de job XML: globusrun-ws

Slaves/Containers

18




TEC CALIPSO



Solex Imalise1


Open Ports:2811/tcp

CEP

CNES internal network

19



Firewall consequences on transfer time : first resultsFirewall consequences on transfer time : first resultsFirewall consequences on transfer time : first resultsFirewall consequences on transfer time : first results

Image processing Transfer with Firewall Transfer without Firewall Ratio

(364x364) 280 s 50 s 17 s 2.9

(12000 x 12000) 1950 s 2446 s 110 s 22.2

Globus feasibility through cascading firewalls proved , Not very compliant with performance requirements

(explain why ?)

=> a user recommendation can be to define a complete workflow avoiding several requests from outside

20



CPU charge CPU charge CPU charge CPU charge

Spliting phase Assembly

Imalise1

Treatment

Imalise2

Solex

21



CNES feedbacksCNES feedbacksCNES feedbacksCNES feedbacks

Some technical results reached and a strong involvement of CS company in the R&D project ,

A promising technology for future distributed ground segment if we adjust architecture design and project needs,

A good collaboration between the CS company and the Cnes security experts,

Grid technology trends needs expertise in different fields : security, middleware, architecture design, … (not always available in our organization !),

A weak involvement from the Cnes directors yet

=> a strong need to be supported if we want GRID succeeds and be used in our future projects .

1 grid workshop – toulouse ias – october 20th ground segment & products department globus...

Documents

security data

security of resources

data flow security

security architecture

grid architecture

grid management data

resources user data

providers of grid resources