CNES GRID EXPERIENCES AND PLANS FOR SPACE APPLICATIONS

EGEE-II INFSO-RI-031688

Enabling Grids for E-sciencE

www.eu-egee.org

EGEE and gLite are registered trademarks

CNES GRID EXPERIENCES AND PLANS

FOR SPACE APPLICATIONS Author Joël COURQUET CS SI On behalf of Jean-Marie WALLUT CNES (DCT/PS/VDO)

Anne JEAN-ANTOINE PICCOLO CNES (DCT/PS/TIS)

2nd EGEE User Forum Manchester, May 10-11, 2007

EGEE User Forum Manchester May 11, 2007 2



Activities in 2006

• CNES decided to be involved in the EGEE II project (April 2006 – March 2008) as a CERN partner.

• Objectives in 2006 :– Explore and experiment the Grid technology implemented in

EGEE (gLite middleware and high level services),– For that :

CNES set up a gLite infrastructure as a local grid in the computer centre in order to deploy experiments,

CNES aimed to demonstrate that this technology can provide a reliable and secure computing infrastructure for data processing (in conformance with the objectives of EGEE II project).

– Re-use this technology in data processing centres with huge requirements in term of CPU load and storage. The GAIA astronomy mission should be a precursor for requirement analysis and selection of high level services (job submission, monitoring, data management).




POLDER ground segment data analysis

Level 0 400 Mo / orbite

Product N1 700 Mo/orbite

Processing chain N 1

Processing chain N2 ERB

Processing chain N2Ocean

Processing chain N2 Aérosols

Processing chain

Browse

N 1

Processing chain N2 Land

Product N1 Browse

N1 Browse /Day

Product N2 ERBProduct N2 Ocean DR Product N2 AE M

Product N2 AE CProduct N2 Land DR

Product N2 OceanMP

Processing chain N3 ERB

Processing chain N3Ocean

Processing chain N3 Aérosols

Processing chain N3 Land

1

11

11 1 1 1

435 435 435 435

Product N3 ERB Product N3 Ocean MP

Product N3 AE M & C Products N3 DP &VP

2211

Products N3 Land DP &VP

14 products / Day

2,5 To/Year 1/1

3,5 To/Year

1/1

0.25

To/year

1/1

0.05

To/year

1/1

0.05

To/year

420/1 420/1 420/1




POLDER ground segment expected functionalities




Specific Security audit for gLite implementation

• Specific security requirement 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.

– Has delivered a “security requirement document” applicable for CNES-like organizations (with restricted accesses) : 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.





• Grid security key functionalities – Authentication: Each site must be able to identify, at any time, the end

user of a given executed resource. – Authorization: Before the information system executes a grid service, it

must check whether the user has access rights to the resource. – Auditing/accounting: By recording grid events in log files, they can be

checked and, where applicable, the source of an intrusion can be subsequently detected.

– Confidentiality: Only the user community concerned must know the data and how it is processed.

– Integrity: This consists in checking that data cannot be modified during the transfer and storage phases

– Resource network management: Grid operational security requires that there are no permissive sites. A check must also be made to ensure that security controls do not penalize traffic between sites and service execution excessively.

– Trust: Trust is established between the sites when they exchange proof that they are each behaving exactly like the other entities.





• gLite suitability for CNES doctrine – Analysis of threats and the associated risks: The threats are firstly

identified to serve as a basis in listing the risks. – Formalization of risks: This consists in identifying gLite’s response to

each of these risks. – Security objective: The security objectives are compared with the risks

to ensure they are covered. We also define the objectives regarding intrusion or security breach detection, whether at a system and network level or at an application level. Lastly, certain objectives are associated with requirements for conformity with CNES policy or IP network openness policy. gLite’s coverage of each of these objectives is then analyzed.

– Conformity of gLite with CNES security objectives: gLite’s conformity with CNES doctrine regarding architecture and IP openness policy must be checked.

– Functional security requirements: A number of functional security requirements characterize the grid components used to achieve security objectives. In accordance with EBIOS recommendations, these functional security requirements are selected as far as possible from the baseline requirements specified in ISO/IEC 15408.





• Authentication: Each site must be able to identify, at any time, the end user of a given executed resource. gLite includes this service, which is called each time each grid resource is requested. The following should be noted, however: Contrary to the CNES requirement, users can attempt to connect several times without the system being informed of these unsuccessful connection requests. There is no special control on the user’s chosen location for storing his encryption keys.

• Authorization: Before the information system executes a grid service, it must check whether the user has access rights to the resource. All gLite services comply with this principle. Two points are currently being improved: There is no service to automatically synchronize the VOs’ rights to each site’s SEs. This shortcoming is to be corrected for mid-2007 An improvement to the granularity of data and process rights within the VOs is planned

• Auditing/accounting: By recording grid events in log files, they can be checked and, where applicable, the source of an intrusion can be subsequently detected. Each gLite service produces a set of log files. There is currently no high-level service able to provide VO and site administrators with a global vision of grid use. It should be noted that the EGEE community has initiated moves to meet this need.





• Confidentiality: Only the user community concerned must know the data and how it is processed. The HYDRA service is used to encrypt a SE’s data. The data can then only be understood by the VO. The remaining difficulty is due to the fact that a VO member can still transfer data outside the SEs and retrieve them onto his UI. This bias can be avoided by forcing users to connect via a portal.

• Integrity: This consists in checking that data cannot be modified during the transfer and storage phases. The current protocol (gridFTP version 1) cannot be used to check data transfer integrity; this will be possible with version 2 of gridFTP, which is due to be deployed at the beginning of 2007.

• Resource network management: Grid operational security requires that there are no permissive sites. A check must also be made to ensure that security controls do not penalize traffic between sites and service execution excessively. This requirement needs every site to undertake to set up a level of security that meets the demand of all sites, and brings us to the trust problem discussed in the next point., gLite does not use encrypted data transfers or data integrity controls




A 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




Test bed configuration : a gLite “local” grid at Cnes computer centre

• Machine « Glite 1 »– VOMS (VO

Management System)– UI (User Interface)

• Machine « Glite 2 »– WMS (Worload

Management System) – LB (Logging &

Bookkeeping)• Machine « Glite 3 »

– CE (Computing Element) – RGMA Server

(Relational Grid Monitoring Architecture)

• Machine « Glite 4 »– LCG Catalog– DPM Server

• Machine « Glite 5 »– WN

• Machine « Glite 6 »– WN

UI

WMS

CE PBS

LB

WN PBS

WN PBS

DPM

glite5

glite6

VOMS MySQL

glite1

glite2

glite3

glite4

MySQL LFC

RGMA serv

UI

WMS

CE PBS

LB

WN PBS

WN PBS

DPM

glite5

glite6

VOMS MySQL

glite1

glite2

glite3

glite4

MySQL LFC

RGMA serv




Tasks achieved in 2006

• Task 1 : setup g-Lite components (3.0) and some grid services according to the GAIA data processing requirements (g-Lite WMS, R-GMA, …) on a very limited configuration based on recycled PC (Scientific Linux). Cnes has delivered feedbacks on setting up, installation guide and user support to the EGEE II project.

• Task 2 : analyse the security model of g-Lite and compliance with the very strict security rules required by CNES. CNES has delivered its security requirement document and a report on security analysis.

• Task 3 : assess the compliance of g-Lite with heterogeneous worker nodes. In this case, Cnes will prove that the experimental grid can be extended to cluster of PC (under Linux Red Hat ES 4 and Torque resource manager,… ). Cnes will deliver a feedback on this experiment – cause gLite today is only certified for Scientific Linux OS.




What are the features missing in gLite?

• A more detailed security policy for VO and resources• the compliance of g-Lite with heterogeneous worker nodes

• A Quattor like package for the installation and the management of the grid

• Needs for hardware requirements– Configurations parameters – An on line access to FAQ

• Needs about new high level services from EGEE community

• Roadmap of EGEE II (availability, lifetime, new services)




• Assess some hight level services by deploying on the experimental grid. The GIBIS application wil be gridified with gLite (3.0).

• CNES will deliver experience feedbacks on performance measurement, functional interests, reliability and efforts to translate this application over an ‘operational grid’

Tasks planned in 2006/2007

SOLARIS SEF

RENATER

DMZ

Gibis Web

FileExchange

CNESInternet1-ci

LINUX

Gibis tasksGibis Main

LINUX

Cluster PC Linux

Gibis tasksother tasks

Serveur NFS + Backup

(http)

(nfs)

(ftp)(ftp)

(ftp)

[500 Go Disk / 2 To Backup][500 Go Disk / 2 To Backup]

[10 Go Disk][10 Go Disk]

[24 bi-proc Opteron][24 bi-proc Opteron]

[500Mo Disk][500Mo Disk]

int-net01

int-net02

ext-net01

ext-net02

int-net04

SEMDVD

(nfs)

(tcp/ ftp)

int-net03

int-net05

SOLARIS SEF

RENATER

DMZ

Gibis Web

FileExchange

CNESInternet1-ci

LINUX


LINUX

Cluster PC Linux



(http)

(nfs)

(ftp)(ftp)

(ftp)





int-net01

int-net02

ext-net01

ext-net02

int-net04

SEMDVD

(nfs)

(tcp/ ftp)

int-net03

int-net05




SOLARIS SEF

RENATER

DMZ

Gibis Web

FileExchange

CNESInternet1-ci

LINUX


LINUX

Cluster PC Linux



(http)

(nfs)

(ftp)(ftp)

(ftp)





int-net01

int-net02

ext-net01

ext-net02

int-net04

SEMDVD

(nfs)

(tcp/ ftp)

int-net03

int-net05

SOLARIS SEF

RENATER

DMZ

Gibis Web

FileExchange

CNESInternet1-ci

LINUX


LINUX

Cluster PC Linux



(http)

(nfs)

(ftp)(ftp)

(ftp)





int-net01

int-net02

ext-net01

ext-net02

int-net04

SEMDVD

(nfs)

(tcp/ ftp)

int-net03

int-net05

UI

WN PBSWN PBS

WN PBS

WN PBS

DPM

WMSWMS

CE PBSCE PBS

VOMS MySQLVOMS MySQL

LBLB MySQL LFC

MySQL LFC

RGMA serv

RGMA serv

•GIBIS :Gaia Instrument and Basic Image Simulator

UI

UI




Conclusion

Thank you for your attention.

For any question, feel free to send me an e-mail :

[email protected]

[email protected]

Documents

CNES GRID EXPERIENCES AND PLANS FOR SPACE APPLICATIONS