Security Issues in Physics Grid Computing Ian Stokes-Rees OeSC Security Working Group 14 June 2005

Outline Issues (20 mins) Ideas (10 mins) Discussion (15-20 mins) I am not a security person, but I recognize it is essential for large scale grid computing of which I have some experience trying to “do”. Please interject, disagree, question anything I say.

Pieces of the Puzzle People Physicists Sys Admins VO managers Software developers Hardware Individual computers Computing centres Networks Software Operating system/host specific Site specific VO specific Communal grid s/w Services service class service instance User software parallel/cooperating jobs

Authorization Domains 3 Authz domains: Site specific (which we know well) VO/grid (which we’re working on) User configurable All need to give the “thumbs up” for data access service access execution

Usage Control and Costing Utilisation/Usage tracking Charging Fair share/dynamic access control Paradigms Turn a tap Release funds to an account

Privacy Data access Information leakage through meta-data through “recipe” to create data Access to entity identity/authentication tokens “unavoidable” through delegation/service access? Not such a big issue for particle physicists

Correctness Who generated this file data result Is it correct? Do I trust the source? What version(s) of software was used? What was the workflow?

Virtual Organisations Entities need to exist in security domains which span physical domains Virtual Organisations VOs are dynamic constantly changing membership must be easy to setup/destroy/propagate VOs are themselves (internally) hierarchical VO managers, even “per-role” managers Need automation Issuing of “rights” and membership Policies Services Sites want to make “block” arrangements with VOs and not negotiate terms with every user

Roles Current “user security” infrastructure has one focus: “I am Ian Stokes-Rees” because I know a password because I have a certificate signed by a trusted CA which has been told by a trusted RA that they should sign that certificate and give it to me Sites say: Ian Stokes-Rees can access this system submit batch jobs read/write data VO says: Ian Stokes-Rees is part of our VO (But at the moment only one VO can say this...) This isn’t very exciting, or a very big step but a journey of a thousand miles starts with one step

Roles II Authorization by sites or services is then per- entity Or “We trust this VO and will import/mirror their entire user list” Need to be able to say: “I am a Physics Working Group Coordinator” “I am an LHCb Data Curation Manager” “I trust CERN software services” So we need roles And of course services and hosts have roles And each entity may have multiple roles

Tickets Tickets imply time limited/windowed specific rights may be entity-bound or may be transferable Need a “Ticket Server” Or more likely a network of ticket servers Need some way to manage a ticket collection and probably to decide which tickets to use I am still trying to decide if tickets and roles are different

Decoupled There needs to be points of commonality understood data formats But there needs to be freedom of implementation different protocols different usages Need to identify fundamental requirements and representation leave implementation and handling open to different approaches

Scenario Users Software Services Site Administrators Grid Computing

Users Construct an “identity” time based permissions specify a set of roles collect and bind together a set of tickets meta-permissions (identity-bound policy?) can the identity delegate who can communicate with the identity Specify which identity to use for which operations Bind identity to data implications of identity “expiring” Use sets of identities is this different to roles or credential wallet? yes, if they are mutually exclusive identities no, if they are complimentary

Software Services Software needs to have its own security profile: identity token credentials (roles, access tickets) But also needs to accept delegated responsibility from other users, to perform operations on their behalf from other services (or maybe not?) Operates in a larger security domain (site, host and VO) this will imply “inherited” policy

System Administrators Need (and in many ways have) ultimate control over who accesses their systems, executes programs, reads and writes data Will have dynamic policies based on night, day, weekend, load level, maintenance Need it to be simple

Grid Computing specific example of Users and Software Services coming together many different tokens may be required to access grid resources run on a specific site collect data from different sources write data to different sources access remote services (e.g. database) draw “funds” from different accounts

Ideas PKI based infrastructure Credential wallet Timed credentials Tickets and Roles are equivalent Roles are just “long lived” tickets Two classes: transferable credentials identity locked credentials Also “receiver locked” credentials/identity (PK encrypted) Tickets, Grid Bucks, Reservation, and Resource Management somehow related

Questions Are roles and tickets different? Is PKI the only obvious way to do this right now? How good is PKI support for roles and/or tickets? What standards exist to support this? What libraries exist to make it happen? Where are we with Grid Economies?