140 likes | 261 Views
AGD Grid Account Management. AGD Grid Account Management. VO Management in running projects: EGEE gLite Open Science Grid (OSG) – VO Privilege VOMRS Features Using VOMRS with GT4 Pragmatic solution: volist & merge-gridmap manage-local-gridaccounts: Flowchart
E N D
AGD Grid Account Management • VO Management in running projects: • EGEE gLite • Open Science Grid (OSG) – VO Privilege • VOMRS Features • Using VOMRS with GT4 • Pragmatic solution: volist & merge-gridmap • manage-local-gridaccounts: Flowchart • Serving multiple VOs & Sub-VOs
VOMS/VOMRS in EGEE gLite VOMRS (Igor Sfiligoi: gLite Authentication)
VOMS/VOMRS in OSG Certificate Certificate Proxy job job Member VOMRS register Grid Facility CE Globus Gatekeeper SRM JobManager SE membership/ privileges get proxy callouts callouts get uid, gid, rootpath gPlazma PRIMA membership/ privileges Is authorized? SAZ VOMS Facility Authorization Management get uid GUMS submit job (Tanya Levshina: VOMRS)
AGD Grid Account Management Certificate Certificate Proxy job job Member NFS homes VOMRS : VO Management, volist : communication manage-local-gridaccounts: local process accounts homes Grid resource group name manage- local -grid-accounts VOMRS DB local grid- mapfile “volist“ servlet local config List (DN+ID) & more (cronjob) grid- mapfile Auth lists Site-RA manage User VOMRS Globus Gatekeeper Submit job register JobManager
VOMRS Features secure & authenticated management of VO membership, grid resource authorization and privileges: • 2-phase registration workflow to register users with a VO • Dynamic set of collected personal information • Management of multiple grid certificates per member • VO-level control of member's privileges • Email notifications of selected changes and events • Permits delegation of responsibilities within the various VO administrators and group managers • Manages hierarchies of groups and group roles • Interfaces to third-party systems like VOMS
volist Features: • interfacing VOMRS database via jndi • extracting required information via sql-statements • multiple options for data retrieval SELECT CONCAT('"',a.distinguished_name,'"') AS dn, a.member_id-1 AS id FROM member_dns a, members b WHERE a.is_primary_ind='Y' AND a.member_id=b.member_id AND b.member_status='Approved'; • implemented as webapplication for tomcat container • http queries (htpasswd-security) • https queries (htpasswd-security + certification based authentication of host) wget --http-user Kerr --http-passwd Einstein \ "http://mintaka.aip.de:8080/volist/vomembers?print_id=1"
Manage local grid accounts wget/https RunAs aliases Create sudoers entries volist/ VOMRS use visudo VO list Command entries Local policies Map to pool account schema Write grid-mapfile grid- mapfile Keep copy Prefix+format “agd” %.3d Create account for new DN Log new accounts Allowed DNs Remove non-allowed DNs Log unknown accounts Check account existence Denied DNs Remove denied DNs Remap with local gridmap local grid- mapfile Higher priority Remap DN+ID Remap DNs to non-pool accounts
ManageLocalGridAccounts.pl Features: • Queries list of VOMRS servers via volist for generating actual list of VO members • parses listing into an adaptable schema of locally configurable usernames and groups (accounts) • creates accounts on demand with checking existence and home • allows for nfs-homes in cluster environments (separates creation of accounts and homes, if required) • addition: create_remote_homes.pl: takes local list from the script and creates via ssh (or rsh) homes, accounts and gridmap on nfs-host • creates new gridmap file • is designed to run as a regular cron job • takes a list of VORMS-servers and option lists for different VO
Serving multiple (Sub-)VOs local grid- mapfile VOMRS DB Grid resource “volist“ servlet A manage-gridmap Config Sub-VO /Omega/Uno VOMRS A Config VO /Alpha manage-gridmap VOMRS DB Auth lists “volist“ servlet manage-gridmap Config VO /Omega VOMRS grid- mapfile
Differences to GUMS GUMS : • duplicates VO-Management locally • by creating locally another VO-management tool • requires manual administration of local accounts • ‚is a "site tool" as opposed to a "VO tool“‘ • implements (weak) interaction with gatekeepers • substitutes the gridmap file • requires local (java) coding for group/account mappings • does not generate accounts „on demand“ • does not have a clean separation of VO-Management, information retrieval and local resource policies • requires additionally PRIMA on local resources • requires additional exchange mechanism for information exchange VOMRS & UNICORE • already has a clean implementation against OGSA AuthZ Interface (callout)
Summary Using volist+ManageLocalGridUser.pl with VOMRS • separation into three independent steps • managing VOs with VORMS • user registration • local RA manages membership for their users • central VO managers manage VO membership • retrieval of information from VORMS: • volist: queries and retrieval of different sets of information • for resource-providers • other middleware : UNICORE • VOMS VOMRS exchange • local grid-account management with • ManageLocalGridUser.pl with • different mapping schema and choices • one-to-one mapping
D-Grid Development Thinking ahead: • Currently: • HEP uses VOMS • All other CG use Globus: they need VOMRS • UNICORE will remain a special thing for HPC, but UUDB has to be served as well • All need a regular (and flexible) means to manage their VO • Since VOMRS is independent of underlying middleware, we should use this on the VO-Management level • Since almost every CG uses Globus, a solution for VO Management has to be based on this fact • VOMS is heavily relying on gLite, so it’s a non-option for all CG except HEP • D-Grid Call II: • new CG are waiting to be integrated into D-Grid • they will base their grid infrastructure on Globus
D-Grid Development Thinking ahead: • very few CG, except HEP and AGD, have a VO-Management established • Core D-Grid registers ~30..40 users • But: if only this amount of users comes from each CG, which hopefully will be the situation within the next year, a centralized approach will become unmanageable or inefficient (aka: users with certificates waiting on end to be registred on local resources, which already now is a common experience). • Consequence: establishing a • CG-centered VO-level management now with a VOMRS for each CG • interchange of data between those servers on a regular basis • separating VO-Management and local user management • linking both with simple tools will be an absolute necessity now • Inefficient VO-Management is one of the main obstacles for getting users interested in grid infrastructure and thus for the transformation from a playing ground for informatic freaks into a production means for science