EDG Site Access Control ie Local Authorisation and Accounts

1
EDG Site Access Control(ie Local Authorisation
and Accounts)

• Andrew McNab, University of Manchester
• mcnab_at_hep.man.ac.uk

2
Outline

• EDG Testbed Overview
• Sysadmins issues
• Existing VO
• Pool accounts
• SlashGrid
• GridSite
• Grid ACLs
• GACL library
• LCAS/LCMAPS Site Access Control

3
Existing EDG Testbed
Currently 300 users at 20 sites across Europe
4
Testbed site administrators initial worries...

• How can Grid users gain access without me
  creating new accounts every day?
• How can I limit what they can do?
• How can I audit what theyve done to me?
• How can I keep track of files theyve created?
• Local access control and account management
  usually boils down to
• mapping Grid identities into appropriate local
  Unix identities
• while respecting the above.

5
Existing EDG LDAP VO

• EDG currently uses VO authorisation servers
  centrally provided authorisation listings
• published via LDAP (300 users in 10 VO s)
• mkgridmap tool for building local grid-mapfile
  with local choice of VO s.
• GUI tools allow VO managers to manage VO
  membership
• Provides a list of certificate DNs for a given
  group eg an experiment, or a group within an
  experiment.
• Groups have to be defined by an admin of the VO
• cant be defined on ad-hoc basis by small groups
  of users
• Will eventually meet scaling issues since each
  site must frequently (daily?) fetch listings for
  VO s it accepts.
• VOMS or CAS visa model would help a lot with
  this

6
Joining an application VO

• Users first join the Acceptable Use Policy VO,
  with their web browser, using their certificate
• this involves agreeing to the DataGrid wide AUP,
  that sets out obligations of sites and users
• legal wording done in conjunction with CERN legal
  experts (who understandably have a lot of
  experience of international law)
• Users can then join the VO of their application
  (eg an LHC experiment)
• VO manager can choose whether to accept user
• At each site, AND of AUP VO and Application VO
  controls access

7
Pool accounts

• The other half of removing account creation
  burden from admins
• pre-create pools of accounts and allocate these
  to users when they request access
• Widely used by EDG Testbed sites, but not
  obligatory
• in practice, almost all have chosen to use it
• Auditing possible since all DNgtUID mappings
  recorded in log files.
• Same pool mappings can be shared across a farm by
  sharing gridmapdir lock files with NFS.
• Existing system works ok for CPU-only jobs.
• but not really appropriate if users are creating
  long lived files at the site in question.
• Limitations are because files are still owned by
  Unix UID cant recycle UID until all files
  created have been removed.

8
SlashGrid / certfs / curlfs

• Framework for creating Grid-aware filesystems
• different types of filesystem provided by
  dynamically loaded (and potentially third-party)
  plugins.
• certfs.so plugin provides local storage governed
  by Access Control Lists based on Grid DNs and VO
  groups
• certfs is quite solid you can build a bootable
  Linux kernel on a certfs filesystem (100,000
  file operations in a few minutes)
• Since new ACLs just have creators DN, this is
  equivalent to file ownership by DN rather than
  UID.
• solves admin worries about long lived files owned
  by pool accounts.
• if pool accounts are prevented from writing to
  normal disks, then no chance they will write
  something unpleasant somewhere unexpected.
• HTTP/HTTPS plugin (curlfs) ultimately aims to
  provide some NFS/AFS-like functionality, again
  governed by Grid creds ACLs.

9
SlashGrid as container environment

• Basic SlashGrid use maps area like
  /var/spool/slashgrid/grid/xxx to /grid/xxx, with
  mapping controlled by plugin code.
• But also allows virtual directory hierarchies
  which dont correspond to real areas on disk
• gridmap plugin, populated with symbolic links
  eg /grid/p/atlas001 -gt /grid/u/OGrid/OUKHEP/OUh
  ep.man.ac.uk/CNAndrew20McNab
• Could go further and create whole user
  environments on demand
• can be a sandbox if we prevent operations
  outside this environment
• can be tailored to users application (eg default
  shared library versions)
• This means we could achieve a lot of the security
  and uniformity between sites that, say, a Java VM
  has, but with native binaries.
• This would be very complementary to new GT3 GRAM.

10
GridSite

• GridSite manages access to websites and HTTP(S)
  fileservers
• Users and admins load GSI cert key into
  unmodified web browsers
• ACLs control level of read and write access to
  file/directory
• 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.
• fileGridSite is a cut-down version without any
  HTML page-formatting or HTML-editing forms
• provides streamlined HTTPS fileserver with Grid
  access control
• GridSite used by EDG Testbed website, and GridPP
  and e-Science support websites in the UK.

11
Current ACLs

• When building GridSite, SlashGrid and the Storage
  Element, we needed a simple ACL format to use for
  prototyping.
• Current SlashGrid and GridSite use per-directory
  XML ACL in .gacl
• As a file, this can be stored in directories,
  copied via unmodified https or gsiftp channels
  and easily manipulated by scripts and
  applications.
• Sysadmins want disk filesystem ACLs on same
  physical disk as files if possible (or managed
  off-site!)
• Implementing ACLs also solves some other Grid vs
  Unix issues that emerged during with Testbed
• eg per-UID tape storage can store all tape files
  with one UID but associate ACL with the file and
  use that.
• Clearly, isnt a recognised standard, and we
  could go to, say, a subset of XACML however,
  things like filesystems are very performance
  sensitive.

12
Current ACL format
ltgacl version0.0.1gt ltentrygt ltdn-listgt
lturlgtldap//ldap.abc.ac.uk/ouxyz,dcabc,dc
ac,dcuklt/urlgt lt/dn-listgt ltvoms-credgt
ltvomsgt/OGrid/OUabc.ac.uk/DNAbcVOMSlt/vomsgt
ltvogtAbclt/vogt ltgroupgtreaderslt/groupgt
lt/voms-credgt ltallowgtltread/gtlt/allowgt lt/ent
rygt ltentrygt ltpersongt
ltdngt/OGrid/DNAndrewlt/dngt lt/persongt
ltallowgtltread/gtltlist/gtltwrite/gtlt/allowgt
ltdenygtltadmin/gtlt/denygt lt/entrygt lt/gaclgt
13
Grid ACL vs fine-grained VO CAS, VOMS etc

• CAS or VOMS provides ACL-like feature of
  specifying what capability (eg write) is
  permissible on an object (eg higgs-wg-montecarlo).
  
• (If using lots of subgroups within an LDAP VO,
  could achieve much the same thing eg define a
  group of people in higgs-wg-montecarlo-write)
• In some cases, this could be used to provide ACL
  functionality.
• However, we think this is too coarse-grained and
  too heavyweight for all contexts
• eg if my job creates a temporary, working
  directory in /grid/tmp, I dont want to have to
  set up a new entry on the central CAS or VOMS
  machine
• The two types of system should be seen as
  complementary
• when you create some Higgs Monte Carlo data, you
  set its ACL to give write access for people with
  higgs-wg-montecarlo-admin credential.
• applications should find their own level of
  when splitting policy between local ACL or
  VO-wide authorisation service

14
GACL library

• XML ACL format not finalised but have several
  products in use which need to use it GridSite
  SlashGrid and EDG Storage Element.
• ACL will almost certainly change again in the
  future and may need to understand different
  ACLs (eg XACML?) from other projects.
• Insulate ourselves from this by putting ACL
  handling functions into a standalone library, and
  make this understand the current XML.
• Handles read/list/write ACLs in a reasonably
  general way
• packs C structs and linked lists with their
  contents
• provides access functions to manipulate the
  structs as new types.
• Despite current C implementation, API is readily
  translatable to object-orientated languages
• Java API and implementation being produced

15
LCAS / LCMAPS site access

• LCAS - provides site-specific callouts to check
  authorisation based on user identity, what is
  requested, quotas, free-slots in batch system
  etc.
• currently implemented as patched Globus
  gatekeeper, plus plugins to enforce policies
• allows sites to implement complex, locally
  defined rules for access, including locally
  written extensions to check site-specific
  features (eg load on locally written tape-library
  service)
• some of this functionality will also be provided
  by recent Globus proposal for authorisation
  callouts (but currently limited to yes/no on
  identity?)
• LCMAPS - manages current mappings of Grid to
  local identity
• makes this available to other local site
  components
• important when not just using a simple, shared
  grid-mapfile for mapping

16

17
Summary

• Most of the concerns of Testbed site admins are
  being addressed
• LDAP VO system is currently sufficient, but VOMS
  or CAS would be more flexible and scalable.
• Pool accounts are useful but limited by UID file
  ownership issues.
• SlashGrid / certfs provides a solution to this.
• Virtual container filesystems also possible via
  SlashGrid.
• GridSite provides a way of controlling access via
  Grid credentials.
• GACL library provides API for handling Grid ACLs
• LCAS/LCMAPS allows flexible, locally configurable
  site policies
• See http//www.gridpp.ac.uk/authz/ for links to
  source code and details of all tools mentioned in
  this talk