1 / 9

EU DataGrid security with GSI and Globus

EU DataGrid security with GSI and Globus. Andrew McNab University of Manchester mcnab@hep.man.ac.uk. Why we need GSI. EDG Testbed has ~300 users at ~20 European sites

myrna
Télécharger la présentation

EU DataGrid security with GSI and Globus

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EU DataGrid security with GSI and Globus Andrew McNab University of Manchester mcnab@hep.man.ac.uk

  2. Why we need GSI • EDG Testbed has ~300 users at ~20 European sites • Jobs typically submitted from site A to broker at B which uses Replica Catalog at C and sends job to site D which replicates output to site E • So users need a “portable” testbed wide identity ... • … and need to be able to delegate this identity from site to site

  3. Authentification / CA management • Since GSI built on X509, somehow need to get CA certificates for every CA to each site • EDG software, including bug fixes, distributed as binary packages • Information about Certificate Authorities part of this process • eg RPM for Linux that installs into /etc/grid-security/certificates CA ’s own certificate • Policy file and optional cert request configuration • Location of CRL: automatically found and used by fetcher run from cron • For a CA to be distributed as part of EDG software, it’s CPS must be accepted by EDG CA group. • Sites can still add other CA’s if they trust them

  4. Virtual Organisation membership • GSI provides a testbed-wide identity, but sites need lists of identities to accept • Manually, would have to email ~20 sites with new names every day • EDG currently uses VO authorisation servers: centrally maintained authorisation listings • published via LDAP (~300 users in ~10 VO ’s) • mkgridmap: automatically builds grid-mapfile with local choice of VO ’s. • GUI tools allow VO managers to manage VO membership • Users must also join Acceptable Use Policy VO by signing AUP • AUP defines relationship between all sites and all users in a single place

  5. Mapping GSI identity to local Unix ID • Not only need a list of GSI ID’s, also mapping to local Unix ID • Manually, site admins would have to create new accounts every day • Instead, pre-create pools of accounts for VO’s and allocate these to users when they request access • eg atlas001, atlas002, atlas003, … • implemented as a patch to gridmap.c, used by Globus Gatekeeper, Grid FTP etc • lock files store mapping: multiple connections with same identity receive same pool account • auditing possible since all GSI ID=>UID mappings recorded in log files. • Ok for jobs that use CPU but don’t make long-lived files locally • Limitations are because files are still owned by Unix UID: can’t recycle UID until all files created have been removed.

  6. GSI ID vs Unix ID file ownership • GSI gives testbed-wide identity, but local Unix ID still owns files • SlashGrid allows “Grid-aware” filesystems • different types of filesystem provided by plugins. • certfs.so plugin provides local storage governed by Access Control Lists based on GSI ID’s, VO groups, Globus CAS or VOMS. • Since new ACL’s just have creator’s GSI ID, this is equivalent to file ownership by GSI ID rather than UID. • solves admin worries about long lived files owned by pool accounts. • HTTP/HTTPS plugin (curlfs) ultimately aims to provide NFS/AFS-like functionality, again governed by Grid ACL’s.

  7. GridSite - Grid/Web crossovers • Since have invested in GSI identities for users, also want to use in web security • GridSite manages access to websites and HTTP(S) fileservers • Users and admins load GSI cert + key into unmodified web browsers • Grid ACL’s control level of read and write access • Write access either by HTML forms (interactive) or HTTP PUT (programmatic) • Website admins can define groups of users with specific rights • Can delegate administration of that group to one or more members. • Group membership can also be published in EDG VO LDAP format. • GridSite used by EDG Testbed website, and GridPP and e-Science support websites in the UK.

  8. Other EDG systems built on GSI • EDG WP2 (Data Management) has built a set of Java security modules • this includes modules for verifying GSI proxies, and enforcing ACL and grid-mapfile access control • can provide security handling for other Grid services • filtering of both plain HTTP and SOAP requests, and queries from service itself during processing • EDG WP4 (Fabric Management) site access system • LCAS - provides site-specific callouts to check authorisation based on user identity, what is requested, quotas, free-slots in batch system etc • LCMAPS - manages current mappings of Grid to local identities • similar to recent Globus proposal for authorisation callouts

  9. Summary • GSI is the security system that ties the EU DataGrid together • Implementing a grid using GSI requires mechanisms for: • distributing CA info to sites • distributing VO info to sites • managing GSI to local account mapping • EDG has demonstrated applying GSI security to filesystems and websites • GSI also provides the basis of Java information and LCAS site policy security systems • See http://www.gridpp.ac.uk/authz/ for links to source code and details of all tools mentioned in this talk

More Related