Andrew McNab - EDG Access Control - 17 Jan 2003 EDG Site Access Control (ie Local Authorisation and Accounts) Andrew McNab, University of Manchester [email protected]

Andrew McNab - EDG Access Control - 17 Jan 2003

EDG Site Access Control

(ie Local Authorisation and Accounts)

Andrew McNab, University of Manchester

[email protected]

Andrew McNab - EDG Access Control - 17 Jan 2003GridPP / EDG / WP6

Outline

EDG Testbed Overview

Sysadmins’ issues

Existing VO

Pool accounts

SlashGrid

GridSite

Grid ACL’s

GACL library

LCAS/LCMAPS Site Access Control


Existing EDG TestbedCurrently ~300 users at ~20 sites across Europe


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 they’ve done to me?

How can I keep track of files they’ve created?

Local access control and account management usually boils down to

mapping Grid identities into appropriate local Unix identities

while respecting the above.


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 DN’s for a given group: eg an experiment, or a group within an experiment.

Groups have to be defined by an admin of the VO can’t 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


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


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 DN=>UID 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: can’t recycle UID until all files created have been removed.


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 DN’s 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 ACL’s just have creator’s 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 + ACL’s.


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 don’t correspond to real areas on disk

“gridmap” plugin, populated with symbolic links: eg /grid/p/atlas001 -> /grid/u/O=Grid/O=UKHEP/OU=hep.man.ac.uk/CN=Andrew%20McNab

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 user’s 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.


GridSite GridSite manages access to websites and HTTP(S) fileservers

Users and admins load GSI cert + key into unmodified web browsers

ACL’s 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.


Current ACL’s 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 ACL’s on same physical disk as files if possible (or managed off-site!)

Implementing ACL’s 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, isn’t a recognised standard, and we could go to, say, a subset of XACML: however, things like filesystems are very performance sensitive.


Current ACL format<gacl version=“0.0.1”><entry> <dn-list> <url>ldap://ldap.abc.ac.uk/ou=xyz,dc=abc,dc=ac,dc=uk</url> </dn-list> <voms-cred> <voms>/O=Grid/OU=abc.ac.uk/DN=AbcVOMS</voms> <vo>Abc</vo> <group>readers</group> </voms-cred> <allow><read/></allow></entry>

<entry> <person> <dn>/O=Grid/DN=Andrew</dn> </person> <allow><read/><list/><write/></allow> <deny><admin/></deny></entry></gacl>


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 don’t 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


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 ACL’s (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 ACL’s 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


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


David Groep – Pluggable Authorisation, LCAS and beyond – 2002.11.18 - 2

WP4 LCAS Authorization Service

LCAS plugable authorization

User Credentials

Name

Full proxy

J ob request details

Framework

combination of individual modules

Simple policy scheme (ordered)

Extensible (modules are .so ’s)

Near f uture (03Q1): ‘daemon’

TLS auth

LCAS client

apply creds *

Jobmanager-*

Gatekeeper LCAS

ACL

timeslot

gridmap

config

LCMAPS clnt

Id

Yes/no

In release 1.3


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 ACL’s

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

Documents

Andrew McNab - EDG Access Control - 17 Jan 2003 EDG Site Access Control (ie Local Authorisation and Accounts) Andrew McNab, University of Manchester [email protected]