Grid Security and VO Management Andrew McNab University of Manchester.

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


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


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


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


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!


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.


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


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


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


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


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


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


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


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


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


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


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


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!


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

Grid Security and VO Management Andrew McNab University of Manchester.

Documents

Transcript of Grid Security and VO Management Andrew McNab University of Manchester.