Andrew McNab - EDG Access Control - 17 Jun 2003 EU DataGrid and GridPP Authorization and Access Control Andrew McNab, University of Manchester [email protected]

Andrew McNab - EDG Access Control - 17 Jun 2003

EU DataGrid and GridPPAuthorization and Access Control

Andrew McNab, University of Manchester

[email protected]

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

Outline

EDG Testbed Overview

Globus Security

Sysadmins’ issues

Existing VO

Pool accounts

LCAS/LCMAPS Site Access Control

VOMS

SlashGrid

GridSite

Grid ACL’s

Future developments


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


Globus Security EDG currently uses Globus 2 gatekeepers and file servers, and

Globus’s GSI model for authentication.

Users and hosts are identified by X.509 certificates, signed by one of ~20 “national” Certificate Authorities

CA policy statement must be acceptable to EDG CA Group

CA root certs/configuration distributed by same channels as bug fixes, security patches etc.

Users can produce delegated credentials (“GSI proxy”) by signing a public key with their user certificate

this can be chained to delegate credentials to remote servers

Authorization is provided by simple text file with certificate names and corresponding local Unix account names.

/etc/grid-security/grid-mapfile consisting of lines like:“/O=Grid/O=UKHEP/OU=hep.man.ac.uk/CN=Andrew McNab” mcnab


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 Virtual Organisation 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 /etc/grid-security/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.


LCAS / LCMAPS site access Extension of Globus access control / mapping

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


Virtual Organisation Membership Service: VOMS

Instead of publishing lists of VO and group membership, supply signed attribute certificates to users.

Users can then present these attribute certificates to sites/resources and obtain access with group privilege, role etc.

Certificates can be included in GSI proxy certificates as extensions

Multiple attribute certificates can be used simultaneously, even from different VOMS servers and VOs.

Potential to allow users to create ad-hoc groups within VO, and to discard unnecessary VOMS credentials at delegation steps.

This is similar to Globus’s Community Authorization Service (CAS) however, VOMS is designed for maximum backwards compatibility

and to maintain the user as the verifiable and principle source of authentication


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 certificate name’s and VO groups

certfs is very 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 name, this is equivalent to file ownership by certificate name 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 remote filesystem plugin (curlfs) provides 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 and execution environment factory.


Current ACL’s When building GridSite, SlashGrid and the EDG 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 can provide ACL-like feature, specifying what capability (“write”) is permissible on objects (“higgs-wg-montecarlo”)

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.

when you create a temporary working directory, you set its ACL to give only you read and write access.

applications should “find their own level” 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


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

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

Originally produced for www.gridpp.ac.uk

ACL’s control level of read and write access to file/directory Write access 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.

New 0.9 architecture also provides support for efficient HTTP GET and PUT operations via Apache module.

ACL enforcement now available for PHP, CGI, JSP etc as well as HTML

GridSite used by several external projects, including e-Science Level 2 Grid support website.


GridSite 0.9 architecture

mod_ssl: plainHTTPS > env vars

mod_gridsite: GACL access control + GACL > env vars

mod_gridsite:.html headersand footers

.shtml,mod_perlCGI, PHP

mod_jk:JSP withTomcat

HTTP

grst-admin.cgi: page editing,file upload, ACL editing etc.

grst-proxy.cgi: G-HTTPS, 3rdparty COPY, proxy GET + PUT

mod_gridsite:PUT, DELETE,

MOVE

mod_ssl-GSI: HTTPS withGSI+VOMS+CAS > env vars


Future Developments

EU DataGrid officially finishes 31st Dec 2003 EGEE is an EU Framework 6 proposal to deploy an EU-wide Grid, largely

using EDG technology for HEP, Bioinformatics and other e-Science.

GridPP comes to an end in 2004, and GridPP-2 proposal submitted to PPARC for e-Science 2nd Phase funding.

CERN is also sponsoring the LHC Computing Grid to deploy a Grid for High Energy Physics.

All of these projects stress deployment and operations rather than middleware development.

However, development of Accounting and Usage Control mechanisms is acknowledged as essential to running these production services.

We propose to extend GridPP Authorization work into Accounting to contribute to EDG / LCG / EGEE.


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.

LCAS/LCMAPS allow flexible, locally configurable site policies.

GridSite provides a way of controlling HTTP(S) via Grid credentials.

GACL library provides API for handling Grid ACL’s.

Extending work into Usage Control, not just Access Control.

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 Jun 2003 EU DataGrid and GridPP Authorization and Access Control Andrew McNab, University of Manchester [email protected]