0140dda04e98a1a253fc73954225ab68.ppt
- Количество слайдов: 17
Enabling Grids for E-scienc. E Glexec overview Gerben Venekamp NIKHEF www. eu-egee. org INFSO-RI-508833
Contents • What is glexec? • Why do we need glexec (and gsexec)? • How does glexec fit in the g. Lite architecture? • How can glexec be invoked? • Glexec on the worker node • Status INFSO-RI-508833 European Condor week June 28 th, Milano 2
What is glexec? glexec a thin layer to change unix credentials based on grid identity and attribute information you can think of it as: • ‘a replacement for the gatekeeper’ • ‘a griddy version of Apache’s suexec(8)’ • ‘a program wrapper around LCAS, LCMAPS or GUMS’ INFSO-RI-508833 European Condor week June 28 th, Milano 3
What glexec does Input 1. a certificate chain, possibly with VOMS extensions 2. a user program name & arguments to run Action 1. check authorization (LCAS, GUMS) • user credentials, proper VOMS attributes, executable name 2. acquire local credentials – local (uid, gid) pair, possibly across a cluster 3. enforce the local credential on the process Result 1. user program is run with the mapped credentials INFSO-RI-508833 European Condor week June 28 th, Milano 4
LCMAPS Workspace Service and the WSS in g. Lite-1 WMS Work. Space Service quarantine and terminate GK LCMAPS poolaccount Voms poolaccount lcmaps. db groupmapfile grid-mapfile Plug-ins Setuid, setgid Gridmapdir poolindices %2 fo%3 ddutchgrid%2 fo%3 dusers%2 f o%3 dnikhef%2 fcn%3 dmartijn%20 ste enbakkers%3 atlas 001 […] Condor schedd INFSO-RI-508833 European Condor week June 28 th, Milano 6
Why was glexec devised? • gatekeeper and other schedulers are complex, and need not be run with root privileges all the time – take an example from Apache httpd, where user cgi scripts can be run under their own identity, but without the web server itself having to run as root – to accomplish this, a small, program is needed with setuid(2) power: ‘suexec(8)’ • variety in grid job submission systems is increasing – need a common way of obtaining and enforcing site policy and credential mapping – without the need to modify each and every system – as such, glexec in this deployment mode is an alternative to having authorization and mapping call-outs in each system INFSO-RI-508833 European Condor week June 28 th, Milano 7
‘suexec’ requirements • Do as little as possible with ‘root’ privileges • Allow VO-services to use (pool)accounts for each user job • In- and outgoing pipes, file descriptors should be preserved as much as possible. • Should be usable by C/C++ and java services: program executable. • Sites should still be able to control the access to their resources • Apache’s su. EXEC fulfills many of these requirements – Safe code, has proven itself – Works with apache – 2 clones from apache’s su. EXEC: gsexec (part of gridsite) and glexec (part of g. Lite) INFSO-RI-508833 European Condor week June 28 th, Milano 8
suexec wrapper Thin layer with root privileges will replace gatekeeper • Intended for identity-switching services: – condor, gridsite, globus gram, cream. • Internal – Uses LCMAPS/Workspace service as credential mapping mechanism – Executes the requested command with local credentials • External interface – Should be usable by C, java (, perl? ) services: program executable. – A (user) credential should be passed to suexec. – In- and outgoing pipes, file descriptors should be preserved as much as possible. INFSO-RI-508833 European Condor week June 28 th, Milano 9
Scenario I: Apache INFSO-RI-508833 European Condor week June 28 th, Milano 10
Scenario II: Cream INFSO-RI-508833 European Condor week June 28 th, Milano 11
Scenario III: Condor/WSS INFSO-RI-508833 European Condor week June 28 th, Milano 12
Usage of glexec (1) Two run-modes depending on setuid bit settings: 1. glexec is setuid-root: setuid()/setgid() to local user in glexec code and execute the program -r-s--x--- 1 root apache /usr/sbin/glexec In the next release: 1. glexec runs as special user: glexec uses sudo for identity switching and program execution: -r-s--x--- 1 glexec /opt/glite/sbin/glexec sudo preserves only stdin, stdout, stderr sudo can be configured to allow the user “glexec” to run a predefined set of programs (blahp, qsub) INFSO-RI-508833 European Condor week June 28 th, Milano 14
Usage of glexec (2) • Environment variables to be set before calling glexec – GLEXEC_MODE: “lcmaps_verify_account”: glexec <uid> <gid> <command+args> “lcmaps_get_account”: glexec <command+args> – SSL_CLIENT_CERT and SSL_CLIENT_CERT_<n>: PEMencoded strings containing the proxy cert and chain components. – GLEXEC_SOURCE_PROXY: location of the (delegated) proxy to be used by the user job. . – GLEXEC_TARGET_PROXY: location where the proxy should be copied to. If not specified ~/. glexec/proxy is used. – GLEXEC_ID (optional): unique job id to be used as an index for the jobrepository: • All other environment variables are cleared INFSO-RI-508833 European Condor week June 28 th, Milano 15
Usage of glexec (3) Configuration: • At compilation time the default defines in the apache headers (/usr/include/httpd/*. h) are overridden by glexec. h – Contains at the moment hardcoded locations of lcas and lcmaps config files – Next version will use a configuration file instead. • lcas and lcmaps use the following config files: – /opt/glite/etc/lcas-glexec. db – /opt/glite/etc/lcmaps-glexec. db INFSO-RI-508833 European Condor week June 28 th, Milano 16
VO pilot job on the node • On success: the site will set the uid/gid of the new user’s job • On failure: glexec will return with an error, and pilot job can terminate or obtain other job Note: proper uid change by Gatekeeper or Condor-C/BLAHP on head node should remain default INFSO-RI-508833 European Condor week June 28 th, Milano 18
Status today • Status of ‘glexec’ today – implementation ready & tested, based off the Apache HTTP suexec code base – uses the LCAS and LCMAPS for enforcement and mapping in their library-based implementation – new modules have been added LCAS: RSL (executable path) constraints validation of cert chain and proxy lifetime – restrictions policy should be located on local posix-accessible file systems policy transport should be ‘trustworthy’ • Needed specifically for the –on-WN model – make the credential acquisition process (LCAS/LCMAPS) work with a site-central policy engine enforcement will have to stay local – changeover to standard callouts for both are needed – needs more site-sysadmin configuration capabilities INFSO-RI-508833 European Condor week June 28 th, Milano 19
Plans • Integration on prototype with CREAM and Condor • Replace callouts to LCAS and LCMAPS by a callout to Workspace service (a. k. a. the full scenario). – Workspace bind service • Use of sudo • Use of a glexec configuration file • Interoperability: use the common standardized auth. Z/mapping callout interface (OSG collaboration) INFSO-RI-508833 European Condor week June 28 th, Milano 20
0140dda04e98a1a253fc73954225ab68.ppt