GPBox

1
G-PBox

• A Policy Management Framework for a Production
  Grid

Andrea Ferraro (andrea.ferraro_at_cnaf.infn.it) INFN
(Istituto Nazionale di Fisica Nucleare)
March 2nd 2005 Workshop Grid.it CNR - Roma
2
Summary

• Problem statement
• G-PBox overview
• G-PBox policy language
• G-PBox policies use-cases
• G-PBox internal
• Conclusions

3
Problem statement (1/2)

• Large scalable Grid environments have three
  domains
• VO domain (managed by VOs)
• Grid domain (managed by each Grid
  representatives ie. INFNGrid managers, GridPP
  managers, NorduGrid managers, etc.)
• Site domain
• single sites
• sub-farms of single huge sites

4
Problem statement (2/2)

• Available policy systems usually act at the level
  of Sites. A Grid, on the other side, is composed
  by various layered entities (VO domain, Grid
  domain, Site domain)

5
G-PBoxin large scalable Grid environments
6
VO
VO
VO
VO
Admins
GRID
Admins
GRID
SITE
Site
Site
Site
Site
Admins
7
G-PBox in short
G-PBox stands for Grid-PolicyBox
8
PBoxes receive and evaluate requests
1) The User wants to use the resource
PBox
3) The PBox responses regarding policies
2) The Resource asks to its domain PBox
Storage Element
Resouce Broker
Queue1 Queue2 Queue3
9
The XACML policy language

• Aplicable to a set of eterogeneous points of
  enforcement (like Grid ones)
• Fast and easy modification and viewing of a whole
  Grid security policy
• Beyond to DENY/PERMIT response
• Becoming a standard in both scientific and
  industrial worlds

10
Rule
Rule
Target
Effect
Condition
DENY PERMIT
Subject
Resource
Action
submit, read, write, route
site, CE, SE, RB, etc.
user, VO, etc.
11
Two Grid policies use-cases

• A VO grants an high priority to a group
• A Grid deny access to its sites for a while

12
Users of cms/muon (a CMS group) get their jobs on
a higher priority queues (Hi-CEs) than other CMS
users on Grid1 SITEs

• VO POLICY
• GRID POLICY

CMS
cms/muon
P
GRID1
RB
Lo-CEs of Grid1
Hi-CEs of Grid1
CE
CE
WNs
WNs
WNs
P
WNs
13
Grid1 says it prohibits VOA accesses to its
resources
RB of VOA

• VO POLICY
• GRID POLICY

RB
RB of Grid1
VOA
GRID1
P
SITEX of Grid1
WNs
CE
WNs
14
G-PBox topography
vo.cms.it
vo.cms.fr
vo.ingv.it
grid.nordugrid.se
grid.infngrid.it
site.xy1.nordugrid.se
site.pd.infngrid.it
site.bo.infngrid.it
site.xy2.nordugrid.se
15
Internal components
16
Policy evaluation
A Resource (CE, SE, RB, etc.) must implement a PEP
REQUEST
PEP sends the XACML request to the PDP of its PBox
PEP translates the RESOURCE DEPENDENT request in
XACML request
Resource sends a RESOURCE DEPENDENT request to
its PEP
PEP
PDP
Resource
RESOURCE DEPENDENT
XACML
PEP translates the XACML response in a RESOURCE
DEPENDENT response
Resource receives a RESOURCE DEPENDENT response
from its PEP
PDP of the PBox sends back the XACML response
based from PBox policy
RESPONSE
17
Tech notes (1/3)

• PCI flexibility
• PCI is a simple interface able to exchange
  PBoxMessages objects
• A set of implementations are available
• PCI is open to new implementations

RMI
PCI
PCI
SOCKET
GSI
18
Tech notes (2/3)

• XML oriented
• NO RDBMS, pure XML repository (XIndice)
• XML Schemas for PBoxPolicy e PBoxAddress
• JAXB as object representation of XML elements
• extensive use of XPath
• Asyncronous approach
• Initially were used standards message broker
  engines (e.g. OpenJMS)
• Now the prototype has an internal asyncronous
  mechanism
• Manta Ray peer-to-peer JMS system is under
  evaluation

19
Tech notes (3/3)

• Discovery mechanism
• Currently a manual issue
• Gnutella and JXTA protocols in evaluation phase
• PEP implementations
• PEP library for CE and SE LCAS plugin mechanism
  in evaluation phase
• PEP over RB in final phase

20
Conclusions

• G-PBox was totally conceived and developed by
  INFN people in WP3 Grid.it FIRB project
• Development and testing is ongoing (mid February
  05)
• EGEE and OSG demonstrated a special interest in
  G-PBox development
• G-PBox reference http//infnforge.cnaf.infn.it/pr
  ojects/pbox
• Thanks to Grid.it for support and funding of this
  work