SVOPME: Scalable Virtual Organization Privilege Management Environment

1
SVOPME Scalable Virtual Organization Privilege
Management Environment Nanbor Wang1, Balamurali
Ananthan1, Gabriele Garzoglio2, Steven
Timm2 1Tech-X Corporation, 5621 Arapahoe Ave,
Suite A, Boulder, CO 80303 2Fermi National
Accelerator Laboratory, P.O. Box 500, Batavia,
IL, 60510, USA
Problem Description Modern Grid middleware
provides both the mechanisms and tools to enable
fine-grained, role-based access control. However,
it comes up short in providing a streamlined and
consistent distributed user privilege management
across Virtual Organizations (VO) and sites.
Currently, this lack of automatic policy
instantiation/reconciliation is handled manually
via verbal discussions between VO administrators
and site administrators. Such manual propagation
of VO policies is a brittle and time-consuming
process. With privilege policies changing more
dynamically (a trend that is becoming more common
for large VO's and sites with more new VOs
getting onboard), Grid utilization suffers as
legitimate users may not be able to access
resources which are otherwise perfectly usable.
Key features are missing in the
state-of-the-art Grid middleware to enable the
effective communication of the desired VO
privilege policies to Grid sites. These features
call for VOs to define the privilege policies
formally and for Grid site to access these formal
definitions and verify their local configurations.

• How it works
• The following are the logical steps involved in
  comparing the VO and Grid site policies
• The VO administrator compiles the policies in the
  VO XACML policy editor.
• For every VO policy that is compiled, a
  corresponding XACML request is produced.
• Policies on the Grid site are auto-compiled using
  the results from the Grid probe.
• The VO requests, corresponding to VO policies,
  are evaluated against the site policies by the
  Policy Comparer web service and by the Policy
  Advisor. Both tools use the Sun XACML Engine.
• Using the evaluation result one concludes whether
  the Grid site honors a VO policy or not.

• List of currently supported policies
• Account Type Policy Run job submitted from FQAN
  A using Pool (unique) / Group (shared) accounts.
• Account Mapping Policy Must have accounts for
  all users in FQAN-A (may be pool accounts or
  Group accounts).
• Relative Priority Policy Jobs submitted from
  FQAN A should have higher priority than those
  from FQAN B.
• Preemption Policy Jobs from FQAN A should be
  allowed to execute for N consecutive hours
  without preemption.
• Package Installation Policy Allow users from
  FQAN A to install software in OSG_APP (assuming
  there is NO space reserved for any VO)
• Unix Group Sharing Policy Accounts belonging to
  FQAN A and FQAN B must share the same unix Group
  ID
• File Privacy Policy Users belonging to FQAN A
  expect privacy for their files
• Job Suspension Policy Do not suspend / resume
  jobs submitted from FQAN A
• Disk Quota Policy Assign disk quota of X GB to
  accounts mapped from FQAN A

Typical architecture of OSG Grid components and
VO components.
SVOPME as a solution SVOPME attempts to solve
this problem by providing a set of tools to the
VO and the Grid administrators. With these tools,
the VO administrator can define VO policies,
publish and verify them. In turn, the Grid
administrators can probe their underlying Grid
resources and auto-compile Grid policies. In
addition, SVOPME provides tools for a VO to
compare its policies with the Grid site policies
and discover compliant sites. Similar tools are
available for the Grid administrators to compare
site policies with VO policies and generate
recommendations on how to alter the Grid
configuration to comply with them.

• VO Policy Editor
• The editor is used to compile VO policies and its
  corresponding requests in XACML format. To
  compile a VO policy the administrator will
• Set a policy ID
• Select the FQAN(s) (collected from the VOMS
  server)
• Assign relevant parameters to the policy
• The VO policy and its requests are compiled.

SVOPME policy interactions between the VO and the
Grid site.
Sample policy comparer output VO/Grid Account
Mapping Policy Comparison /TECH-X is group mapped
on the Grid site. Passed! /TECH-X/RoleSoftware-A
dmin is group mapped on the Grid site. Passed!
/TECH-X/RoleTest is group mapped on the Grid
site. Failed! VO/Grid Grid Accounts Policy
Comparison /TECH-X/RoleUser does not have
sufficient accounts on Grid Site. Failed!
/TECH-X is mapped to 1 account(s) on the Grid
site. Passed! /TECH-X/RoleTest does not have
sufficient accounts on Grid Site. Failed!
VO/Grid Job Runtime Policy Comparison Jobs
submitted by /TECH-X/RoleSoftware-Admin will run
continously for 00 Hrs 04 Mins and 00 Secs.
Passed! Jobs submitted by /TECH-X/RoleVO-Admin
may not run continously for 00 Hrs 10 Mins and 00
Secs. Failed! Jobs submitted by
/TECH-X/RoleTest will run continously for 00 Hrs
04 Mins and 00 Secs. Passed! Files Privacy
Policy Comparison The home directory of
/TECH-X/RoleTest seem to posses adequate
privacy. Passed! Either /TECH-X does not exists
in the GUMS configuration in the Grid site (OR)
the home directory of the account to which
/TECH-X is mapped to does not seem to posses
adequate privacy. Failed! Job Suspension Policy
The jobs submitted from /TECH-X will not be
suspended. Passed! The jobs submitted from
/TECH-X/RoleUser may be suspended. Failed! The
jobs submitted from /TECH-X/RoleSoftware-Admin
will not be suspended. Passed! VO/Grid Priority
Policy Comparison /TECH-X/RoleUser has a
priority less than or equal to /TECH-X on the
Grid site. Failed! (Should be otherwise)
/TECH-X/RoleVO-Admin has a priority greater
than /TECH-X/RoleTest on the Grid site. Passed!
/TECH-X/RoleSoftware-Admin has a priority
greater than /TECH-X/RoleVO-Admin on the Grid
site. Passed!

• Architecture
• Overview
• The architecture is designed to address the needs
  of VOs and Site administrators.
• For the VO
• VO administrator is able to quickly and
  intuitively compile a VO policy
• VO administrator can easily verify which of the
  Grid sites support the VO policy
• The system publishes the VO policies so that a
  Grid site can access them for policy advise
  purposes.
• For the Grid site
• The site administrator probes the Grid resources
  and automatically builds resulting Grid policies.
• The site administrator uses a policy advisor tool
  to build a report on how Grid resources should be
  configured to honor the VO policies
• The system provides a policy comparer web service
  that accepts VO policies and returns a report on
  the compliance of the Grid policies with VO
  policies to the VO administrator.

Sample policy advisor output Grid Account
Mapping Policy Advices /TECH-X/RoleTest is
group mapped on the Grid site. Should be pool
mapped. Grid Accounts Policy Advices
/TECH-X/RoleUser mapped to 5 account(s) on the
Grid site, is not suffient enough. Needs to be
mapped to atleast 8 accounts. /TECH-X/RoleTest
mapped to 1 account(s) on the Grid site, is not
suffient enough. Needs to be mapped to atleast 8
accounts. Grid Priority Policy Advices
/TECH-X/RoleUser has a priority of 1689 and
/TECH-X has a priority of 8. To comply with the
VO, /TECH-X/RoleUser should have a higher
priority than /TECH-X Grid JobRuntime Policy
Advices Jobs submitted by user /TECH-X/RoleVO-Adm
in may not run continously for 00 Hrs 10 Mins and
00 Secs. Failed! Atleast 1 Condor Startd machine
is configured with a MaxJobRetirementTime of 00
Hrs 06 Mins and 40 Secs. Checkout
gridpolicies/CondorJobRuntime.txt to see what
each condor startd machines is configured with.
Grid FQAN Unix Group Account Policy Advices
The account mapped to /TECH-X/RoleTest belongs
to these techxVO group accounts and the account
mapped to /TECH-X/RoleSoftware-Admin belongs to
these vdt group accounts. To comply with the VO
policy, configure the Grid system such that the
accounts mapped to the FQANs shares atleast one
unix group account Files Privacy Policy
Advices The home directory of /TECH-X does not
seem to posses adequate privacy. This FQAN is
mapped to 'techx' whose's home dir is
'/scr_multipole/techx' and has permissions
'lrwxrwxrwx'. To conform with the VO policy, it
is advised that the home directory has
read-write-execute permission only for the user
and for no one else Job Suspension Policy
Advices The jobs submitted from
/TECH-X/RoleUser may be suspended. To conform
with the VO policy, it is advised to configure
all the Condor Startd machines such that the jobs
submitted from 'techx001' will not be suspended.

• Related works
• SVOPME project is synergistic to many projects on
  authorization management. For example,
• The GPBox 3 project is a policy management
  framework for the Grid environment to globally
  modify the execution priorities at sites for VO
  jobs. Compared to GPBox, SVOPME project does not
  attempt to configure site policies directly.
  Instead, SVOPME produces compliance reports about
  local configurations that hint on how the
  configurations could be modified for the site to
  provide better support for VOs. We believe that
  leaving local site administrators in full control
  of site configuration will give them peace of
  mind and reduce their resistance toward the
  eventual adoption of SVOPME.
• The EGEE Argus Authorization Service 2 aims to
  provide consistent authorization decisions for
  distributed services over the Grid. It provides
  software components for defining privilege
  policies at services. These policies are then
  used to answer queries about whether a particular
  action is permissible by certain users. Although
  the EGEE Authorization Service also aims at
  providing a set of consistent authorization
  policies over the Grid, unlike SVOPME, the new
  Authorization Service does not focus on the VO
  policies. The two projects will be able to
  leverage the work done by each other.
• Another effort related to SVOPME is the
  Authorization Interoperability project 1 which
  defines an attribute and obligation profile for
  authorization interoperability across Grids. We
  will leverage the efforts from this project to
  integrate SVOPME into OSG and other Grid
  infrastructure.

VO Tools VOMS Client collects information about
the list of available Fully Qualified Attribute
Names (FQAN) (user groups and roles) and user
membership to these FQAN. VO XACML Policy
Editor uses XACML format as the internal
representation of privilege policies. This
provides a generic mechanism for describing,
combining, and reasoning about policies. Using
the policy editor, a VO administrator compiles VO
policies and their corresponding policy requests.
These requests are used internally for comparing
with and advising the Grid policies. VO Requests
Archiver bundles the VO policy requests as a
compressed archive (tar.gz file) with a
time-stamp attached to it. The VO administrator
then places this VO policy request bundle in a
web server located at the VO. This enables the
Grid sites to download the latest VO policy
requests for policy-advise purposes. Policy
Comparer Client (Command-line and GUI) enables VO
administrators and users to communicate with the
Policy Comparer Web Service at a Grid site. The
client allows to verify the degree of support of
a site for of the VO policies. Grid Tools Grid
Probes probe the Grid resources and collect
information about the Grid sites. This
information is organized into individual text
files that are used to build the Grid
policies. Grid Policy Builder translates
information about site configuration into a set
of formally defined privilege policies in XACML
format. Policy Comparer Web Service compares
the VO and site policies and reports whether each
VO policy is honored by the Grid site. VO
Policy Requests Version Checker compares the
current version of the VO policy requests on the
Grid site with the latest version of VO policy
requests on the VO web server. If needed, it
downloads the latest version of VO policy
requests. Policy Advisor provides advice to the
site administrator on the site configuration
changes that are needed to comply with the VO
policies. Typically, the site administrator uses
the 'VO policy requests version checker' tool
beforehand to obtain the latest version of the VO
policy requests.

• Current deployment
• SVOPME tools are deployed in a realistic,
  large-scale Grid environment at Fermilab on the
  FermiGrid Integrated Test Bed (ITB).
• To evaluate the effectiveness of SVOPME, we
  gathered and defined the VO policies for the
  DZero and the OSG Engage VOs. This test motivated
  several enhancements to the Grid tools.

Future outlook We are currently soliciting VOs
and sites interested in testing out SVOPME in a
production environment. We will continue to
enhance and harden SVOPME tools based on the
feedback and experiences from these early
adopters. We will implement more policies for
future extension based on the needs of the VOs
that we work with. We intend to have SVOPME
incorporated in the Virtual Data Toolkit (VDT).
VDT is considered the de facto standard for Grid
middleware. This should allow SVOPME to be
available to the whole Grid community to realize
a fully automated privilege management
environment.
References 1 G .Garzoglio et al. XACML profile
and implementation for authorization
interoperability between OSG and EGEE 2010 J.
Phys. Conf. Ser. 219 062014 DOI
10.1088/1742-6596/219/6/062014 2 The EGEE
Authorization Service https//twiki.cern.ch/twiki/
bin/view/EGEE/AuthorizationFrameworkAccessed on
Oct 7, 2010 3 Cesini D, Ciaschini V,
Dongiovanni D, Ferraro A, Forti A, Ghiselli A,
Italiano A, Salomoni, Enabling a priority-based
fair share in the EGEE infrastructure 2008
Journal of Physics Conference Series 119 062023
DOI10.1088/1742-6596/119/6/062023
This work is partially funded by the Office of
Advanced Scientific Computing Research, Office of
Science, United States Dept. of Energy under
contracts DE-FG02-07ER84733 and
DE-AC02-06CH11357, the Fermi National Accelerator
Laboratory, and the Tech-X Corporation.