20-may-03d.p.kelsey, lcg-1 security, hepix1 grid security for lcg-1 hepix, nikhef, 20 may 2003 david...

20-May-03 D.P.Kelsey, LCG-1 Security, HEPiX 1

Grid Security for LCG-1

HEPiX, NIKHEF, 20 May 2003

David KelseyCCLRC/RAL, UK

[email protected]


Overview

• LHC Computing Grid project (LCG)– Introduction: slides from Ian Bird (CERN)

• LCG Security Group• Security technology• Policies, procedures and other issues

D.P.Kelsey, LCG-1 Security, [email protected] 3

CERN

LCG - GoalsLCG - Goals

• The goal of the LCG project is to prototype and deploy the computing environment for the LHC experiments

• Two phases:

– Phase 1: 2002 – 2005– Build a service prototype, based on existing grid middleware– Gain experience in running a production grid service– Produce the TDR for the final system

– Phase 2: 2006 – 2008 – Build and commission the initial LHC computing environment

LCG is not a development project – it relies on other grid projects for grid middleware development and support


CERN

LCG - MilestonesLCG - Milestones

• The agreed Level 1 project milestones for Phase 1 are:The agreed Level 1 project milestones for Phase 1 are:– deployment milestones are in red

M1.1 - July 03 First Global Grid Service (LCG-1) available

M1.2 - June 03 Hybrid Event Store (Persistency Framework) available for general users

M1.3a - November 03 LCG-1 reliability and performance targets achieved

M1.3b - November 03

Distributed batch production using grid services

M1.4 - May 04 Distributed end-user interactive analysis from “Tier 3” centre

M1.5 - December 04 “50% prototype” (LCG-3) available

M1.6 - March 05 Full Persistency Framework

M1.7 - June 05 LHC Global Grid TDR


CERN

LCG Regional CentresLCG Regional Centres

Tier 0 • CERNTier 1 Centres• Brookhaven National Lab • CNAF Bologna• Fermilab• FZK Karlsruhe • IN2P3 Lyon• Rutherford Appleton Lab

(UK)• University of Tokyo• CERN

Other Centres• Academica Sinica (Taipei)• Barcelona• Caltech• GSI Darmstadt• Italian Tier 2s(Torino, Milano,

Legnaro)• Manno (Switzerland)• Moscow State University• NIKHEF Amsterdam• Ohio Supercomputing Centre• Sweden (NorduGrid)• Tata Institute (India)• Triumf (Canada)• UCSD• UK Tier 2s• University of Florida–

Gainesville • University of Prague• ……

Confirmed Resources: http://cern.ch/lcg/peb/rc_resources

Centres taking part in the LCG prototype service : 2003 – 2005 Centres taking part in the LCG prototype service : 2003 – 2005

http://cern.ch/lcg/peb/rc_resources


CERN

LCG Resource Commitments – 1Q04LCG Resource Commitments – 1Q04

CPU (kSI2K)

Disk TB

Support FTE

Tape TB

CERN 700 160 10.0 1000

Czech Republic 60 5 2.5 5

France 420 81 10.2 540

Germany 207 40 9.0 62

Holland 124 3 4.0 12

Italy 507 60 16.0 100

Japan 220 45 5.0 100

Poland 86 9 5.0 28

Russia 120 30 10.0 40

Taiwan 220 30 4.0 120

Spain 150 30 4.0 100

Sweden 179 40 2.0 40

Switzerland 26 5 2.0 40

UK 1780 455 24.0 300

USA 801 176 15.5 1741

Total 5600 1169 123.2 4228


LCG Security Group• LCG Grid Deployment Board (GDB)

– Regional centres and Experiments– Plan for deployment and operations

• GDB working groups – reported Feb 2003– WG1 Middleware selection– WG2 Services and resource scheduling– WG3 Security– WG4 Operations– WG5 User Support

• WG3 reported that lots of work still to be done– LCG Security Group created – first meeting 9 April 03

• Concentrating on the planning and implementation for start-up of LCG-1 (July 03)– But keep longer term in mind


Mandate• To advise and make recommendations to the Grid

Deployment Manager and the GDB on all matters related to LCG-1 Security– GDB makes the decisions

• To continue work on the mandate of GDB WG3– Policies and procedures on Registration,

Authentication, Authorization and Security• To produce and maintain

– Implementation Plan (first 3 months, then for 12 months)

– Acceptable Use Policy/Usage Guidelines– LCG-1 Security Policy

• Where necessary recommend the creation of focussed task-forces made-up of appropriate experts– the “Security Contacts” group already working

• Led by Dane Skow, FNAL


Membership• Experiment representatives/VO managers

– Important to create the balance between functionality and security

– Alberto Masoni, ALICE– Rich Baker, Anders Waananen, ATLAS– David Stickland, Greg Graham, CMS– Joel Closier, LHCb

• Site Security Officers– Denise Heagerty (CERN), Dane Skow (FNAL)

• Site/Resource Managers– Dave Kelsey (RAL) - Chair

• Security middleware experts/developers– Roberto Cecchini (INFN), Akos Frohner (CERN)

• LCG management and the CERN LCG team– Ian Bird, Ian Neilson, Markus Schulz

• Non-LHC experiments/Grids– Many sites also involved in other projects– Bob Cowles (SLAC)

• Still open to nominations of additional people


Grid security technology• For LCG-1 start-up

– Use what exists today• Based on EDG release 2.0• Authentication (X.509 PKI)

– List of trusted national CA’s– Online authentication: FNAL KCA, MyProxy

• Authorization– VO (LDAP) databases– Mkgridmap tool to create Grid mapfiles– Map to local user account (real or pool)

• AuthZ components: VOMS, LCAS/LCMAPS, US CMS VOX– Under development– See David Groep’s talk at this HEPiX– To be used when available, tested and proved

• Registration and VO management tools – under development


Policies and procedures

All under consideration by GDB for approval in June

• Authentication - trusted CA’s• Incident response• Audit (and Accounting)• User Rules/AUP/LCG Security Policy• User Registration

– Personal information– Procedures– Pre-registration and account creation

• VO Management• Not discussed in detail (yet):

– Firewalls (no big problems yet in LCG-0)– Outbound net connections from worker nodes?


Authentication - Trust• Two main issues

– Who defines the list of trusted CA’s?• LCG or other Grid projects (EDG)?

– How to introduce new types of CA (online)?• E.g. Kerberos CA at FNAL

• LCG-1 and EDG Application testbed– closely linked (at many sites)– Common approach desirable (for this year)

• For 2003: proposed that GDB approves the list– EDG list plus additions– Require sites to install trusted list

• For Jan 2004 onwards– Forum for CA best practice and trust is evolving

• EGEE, GGF• Community larger than just HEP


EDG CA’s

18 on the trusted list (today)• Canada, CERN, Cyprus, Czech Republic,

France, Germany, Greece, Ireland, Italy, Netherlands, Nordic, Poland, Portugal, Russia, Slovakia, Spain, UK, USA

• For EDG, CrossGrid, DataTAG, US projects…• “Catch-all” operated today by CNRS/FranceUnder development/consideration• Belgium, FNAL (KCA), Hungary, Israel, Japan,

TaiwanNext meeting of the CA group is 12/13 June

(CERN)


Incident Response• Draft document (Dane Skow)

– being discussed on Security Contacts list– Incidents, communications, enforcement,

escalation etc– working draft by end of May

• We already have a (mail) list of Contacts– these are people

• While no Grid Operations Centres– We need/will create an ops security list– Default site entry is the Contact person but

an operational list would be better• for Site Security Ops use only (not for users)• Response will be no better than current cover

– Varies from site to site– But not 24*7


Audit (and Accounting)

• LCG ops team defining lists of what logs need to be kept for audit purposes– Mainly grid services (CE etc) and batch

services– Some grid service logs are distributed– Logs may also contain non-grid jobs (no

problem)• List to be finalised in June• Format to be specified later (not July 2003)• Tools to analyse and aggregate info will come

later• Propose minimum retention period is 3 months• Some of the same logs will be needed for

Accounting but this is not our responsibility


Acceptable Use Policy• A single common policy to be agreed to/used by all

– A big challenge!– Refers to the AUP/Rules of all sites– Only for professional Grid use

• Users agree to this when they join the LCG-1 VO• We start with the current EDG User Rules

– Aim to make minimal changes• This includes User Rules, responsibilities of the

Sites and rules for access to personal data• Eventually we aim to have separate User Rules

and a LCG Security Policy (but not for July)• The AUP to be submitted to the GDB (end of May)


User RegistrationPersonal Information

• The process for July 03– User registers with the LCG-1 Reg. Web– This list of users (the LCG-1 Guidelines VO) starts

from an empty list (no inherited users)– User requests membership of a VO– Registration will have an initial short expiry date

• Propose 6 months (2004 – new AUP/Policy, new procedures)

– Information collected (fields on the web form) is ideally the super-set of that required by the sites

• But this almost certainly not possible

• Aims– Avoid user having to register at multiple sites– Avoid situation where users jobs will only run at

subset of sites (but technically possible)


User personal info (2)• Current common list (discussed on Security Contacts

list)– Full name, Institute, telephone number, e-mail

address, Certificate DN, Experiment• OK so far, but some sites have requirements for

additional fields• Some US sites, for example, require

– Nationality, date of birth and place of birth– Info required up-front for pre-registration

• These items raise significant privacy concerns– Can be used for Identity theft– Users rightly concerned about the distribution/use

of their data


User personal info (3)

• GDB expressed strong concerns about the distribution of and access to the data (privacy and legal issues)– Very unlikely to divulge personal info held by them

• Even after an incident

• Reg. web will request the user’s consent to use the personal data

• We need LCG policy in this area– Who has access to the data and for what purpose?

• GDB sites considering the requirements– Can policy be changed?

• At least in the short-term (or look at exceptions)

– Avoid pre-registration of the users wherever possible

– Aim to minimise and standardise the info collected– But may have to cope with diversity in the future


Registration procedures

• We need a robust process for checking– The right of the user to join LCG-1– That (s)he issued the request to join

• To enable sites to open resources to the users– Without pre-registration

• Long-term aim– move the registration process to the Experiment

Secretariats/User offices• Short-term

– checks at the first stage in the registration process• joining the LCG-1 Guidelines VO• This is where the user info is collected and stored

– Working with experiments to improve the existing rudimentary checks done by many VO managers


VO Management

• Strong message from the experiments– One VO service per experiment– shared between LCG and EDG

• July 2003– Use existing VO databases and servers run

by NIKHEF (for LHC in EDG)– With existing VO managers

• These check and approve the requests to join• With new-improved robust process

• By Jan 2004 (or earlier?)– LCG will need to run its own servers


Summary

• Security is one of the big challenges for LCG-1 • We are working hard to agree policy and

procedures for start-up in July 2003– But also planning for next year and beyond

• Looking forward to the new AuthZ technology– Groups, roles, fine-grained access control,

etc

• Questions, comments?

20-may-03d.p.kelsey, lcg-1 security, hepix1 grid security for lcg-1 hepix, nikhef, 20 may 2003 david...

Documents

grid security

lcg project

startup of lcg

lcg prototype service

donelcg security group

cern lcg teamian bird

security alberto masoni

security policywhere