Grid Security andVO Management

Andrew McNab

University of Manchester

13 December 2005 Grid Security

Outline

● Defining VOs● VO Pull vs Push● Pool Accounts● VOMS● GridSite components● Web service support● VO practicalities

13 December 2005 Grid Security

Perspective

● GridPP is the UK's High Energy Physics grid project

– 15 university sites + RAL

– largest is a 2000 processor farm at Manchester● Participates in deployment of LHC Computing Grid

– ~160 sites worldside, led by CERN● Contributes to EGEE middleware development

– info system, data management and security● I co-ordinate the GridPP security middleware work

– this is principally the GridSite system

EGEE/LCG-2 grid: 160 sites, 36 countries (35 sites in UK&Ireland cluster) >15,000 processors, ~5 PB storageOther national & regional grids: ~60 sites, ~6,000 processors

Country providing resources Country anticipating joining

LCG/EGEE Grid Sites : September 2005

13 December 2005 Grid Security

Virtual Organisations

● Within LCG/EGEE, VOs are essentially authorization domains:

– access rights to resources and datasets

owned by a group of people ● So the central “VO problem” becomes how to

prove individuals are members of that VO, subgroup etc

● There are two classic ways of doing this:

– Pull and Push

13 December 2005 Grid Security

VO by Pull

● EU DataGrid developed a way of publishing lists of VO members

– Authentication based on X.509 DNs: ie VO = “DN List”

– LDAP(S) used, but can also be done by HTTPS● Sites subscribe to VO lists and pull them periodically

– daily or every few hours● Advantage is that user's software doesn't need to know ● Disadvantage is that hundreds of service machines need

to pull lists of thousands of users several times a day

13 December 2005 Grid Security

Pool accounts

● The other half of the EU DataGrid system was Pool Accounts, developed in Manchester

– Unix accounts created and assigned to users as

they submit jobs, access files on that site.

– Local copy of VO membership list decides whether

a mapping can be created

– May direct user to a special pool of accounts for

their VO● Now used by LCG and UK NGS● Surprisingly successful for a “temporary” fix!

13 December 2005 Grid Security

VO by push

● LCG and EGEE are now deploying VOMS

– Users are given short-lived X.509 Attribute

Certificates which prove their VO and group

membership● Users then present these ACs to services, currently

in the form of extensions to GSI Proxy certificates● Advantages: no need for sites to pull all VO lists;

users can choose which group/role to use.● Disadvantages: clients need to be aware of VOMS;

need to add X.509 AC support to services' SSL/TLS.

13 December 2005 Grid Security

Access Policies

● “DN Lists” (eg grid-mapfile) are simplest access policies● LCG/EGEE also uses references to VOMS groups, and

XML policy files: both GridSite's GACL and XAMCL● GridSite GACL/XACML policy files support:

– multiple credential types: individual DN, DN List, VOMS

AC and DNS domain

– AND + OR of conditions

– Read, List, Write, Exec, Admin permissions● Allows “virtualisation” of access: not just tied to a (pool)

unix account, and easy to dynamically manage

13 December 2005 Grid Security

GridSite components

● libgridsite C/C++ toolkit provides utility functions

– based on OpenSSL, libxml2, gSOAP

– parse GSI Proxies and VOMS X.509 attribute certs

– evaluate GACL and XACML access policies

– generate new GSI Proxies● mod_gridsite adds support for GSI Proxies, VOMS

attributes, DN List groups, GACL/XAMCL policies and Onetime Passcodes to Apache

● htcp, htls, htdelegate, ... provide command line tools

13 December 2005 Grid Security

Module architecture

mod_ssl: plainHTTPS > env vars

mod_gridsite: GACL access control + GACL > env vars

mod_gridsite:.html headersand footers

.shtml,mod_perlCGI, PHP

CGI WebServices(gsexec)

HTTP

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

mod_gridsite:PUT, MOVEand DELETE

Apache/GridSite

mod_gridsite: GSI / VOMS OpenSSL callback wrappers

13 December 2005 Grid Security

Web Service support

● GridSite architecture can provide security for Web Service tools like gSOAP, with CGI Web Services

● We also provide the C/C++ implementation of the

GridSite / EGEE Delegation portType

– Java implementation by other members of EGEE● mod_gridsite + delegation CGI used by EGEE WMS

– Apache/FastCGI; GridSite (security); gSOAP (WS) ● Delegated credentials stored in the filesystem

● Allows sharing between different CGI languages

13 Decmber 2005 Grid Security

suexec and gsexec

● Apache has traditionally provided a wrapper to run CGIs as other Unix users:

● Start as root, process as apache, CGI as joeuser● We've modified this to run CGI scripts and services

as pool Unix users, similar to LCG/EGEE and NGS

● Either per-client: the cert in the client program

determines which pool user

● Or per-directory: all the CGIs in my directory run

as the same pool user

13 December 2005 Grid Security

suexec / gsexec (2)

● This allows us to sandbox CGI-based services by ensuring that the pool users are of sufficiently low privilege

● Different clients or service owners can't interfere with

each other● Access control is still via GACL/XACML policy files

● X.509, GSI Proxy, VOMS, DN List credentials● We can now offer “third-party” service hosting

● Give a user or VO access to a privileged directory

● They deploy their C/C++/Perl/Python services

remotely

13 December 2005 Grid Security

GRACE

● In adding support for Web Services to GridSite, we started to offer non-Java ways of building service-orientated grids

● This provides another way of deploying Web Services

– “GRACE” : GRidsite - Apache - CGI – Executables

– Allows services to be written in any language

– Can be deployed remotely

– Deployment rights controlled by GACL/XACML policies

– Different VOs/individuals are sandboxed via Unix UIDs

13 December 2005 Grid Security

Deployment Issues

● Panel question: “How can we deploy a Grid security infrastructure that is scalable, hierarchical, capable of dynamic VOs and easy to use?”

● I think that practical Grid infrastructures will follow most of the established patterns of practical Web infrastructures

– Many lessons already learnt on the Web

– Also, users/admins are already familiar with the Web● Key lession is to be as loosely-coupled as possible

– Use clearly defined interfaces and avoid reinvention

13 December 2005 Grid Security

Software Issues

● Most significant security issue for existing internet services is patching vulnerabilities

– “Keeping up to date” has resulted in automated

update services for major operating systems

– The more you deviate from off-the-shelf software,

the more of this you have to do yourself for your

users● So want to reuse Apache, OpenSSL etc as much as

possible, ideally without making own versions, to benefit from OS updates

13 December 2005 Grid Security

Authentication● This is largely dealt with by the CAs, and the

international CA co-ordination bodies (EUgridPMA and now the IGTF)

● However, users are very aware of authentication (“I forgot my password!” etc) and so it has a large impact on ease of use of the whole system

● Can already use X.509 certs in browsers as simple single-signon to HTTPS websites (GridSite, GridSiteWiki etc)

● But X.509 handling is itself cumbersome for some users

– May need to go to online CAs, merging CAs and

university Shibboleth infrastructures etc

13 December 2005 Grid Security

Authorization● Creation of VOs, subgroups, roles etc

– assigning users to these groups/roles

– binding credentials to resources, dataset rights etc● Scalability drives design decisions

– Can't keep asking VO if a local operation is permitted● Pull and Push models already cover most use cases

– Dynamic VOs are a natural extension of current systems

– Static CA infrastructure means trust can be described by

dynamic policies in terms of certificate identities

13 December 2005 Grid Security

Local enforcement

● Can easily be the Cinderella of a grid security architecture

– easy to implement shiny new authorization systems

in purely Grid software that your project is creating

– but what about file access, SQL database queries,

execution of native binaries?● Either use virtual machines (Java etc)● Or map grid identity to local identity (Unix pool

account, MySQL user etc) and then grant it rights derived from grid policies

● Getting this right has significant performance advantages

13 December 2005 Grid Security

More information

● www.gridsite.org is the GridSite project website

– Open Source, bug tracker, CVS, links to LCG/EGEE● Includes the new GridSiteWiki

– Derived from MediaWiki but uses X.509 instead of

usernames / passwords

– www.gridpp.ac.uk is the largest site using GridSite

– and includes it's own Wiki, which is pulling in info● You can also find GridSites at NGS, GOC, CERN,

LCG, TCD.IE, ... by searching for GridSite with Google!

13 December 2005 Grid Security

Summary

● LCG/EGEE have deployed multiple VOs to 160+ sites using Pull, and are moving to Push via VOMS

● Pool accounts allow a simple way of using Unix accounts

● Access policies tie VOs & Authorization to resources ● GridSite provides libgridsite Grid security toolkit for

C/C++● mod_gridsite adds support for GSI Proxies, VOMS,

GACL, XAMCL, and HTTP PUT,MOVE,DELETE to Apache

● We can now build secured Web Services for Grids as CGI programs