infso-ri-508833 enabling grids for e-science g-pbox auth meeting 13/9/2005 presenter: vincenzo...

INFSO-RI-508833

Enabling Grids for E-sciencE

www.eu-egee.org

G-PBox

Auth meeting

13/9/2005

Presenter: Vincenzo Ciaschini


INFSO-RI-508833

Problem statement

• Available policy systems are working under a single administrative domain.– A Grid is composed by many administrative domains.

VOs need to set policies valid for all domains.

– There are many more policies than ACLs!


INFSO-RI-508833

Requirements

• Resources owners must have absolute control on resources owned by them.

• Policy managers must…. – Have a unique interface to manage policies regarding different

administrative domains. (VO managers only)– Be able to explicitly accept/reject policies from other domains.– Be able to distribute policies to other domains (e.g: banlists)

Necessary in order for them to be accepted.

– Have the possibility to express policies with “granularity”. Based on group/role combinations from VOMS.


INFSO-RI-508833

Our Proposal: G-PBox

• An independet set of modules that can be “plugged in” the current architecture.

• Compliant to relevant standards.– GSI, XACML

• Distributed architecture.• Leveled list of PBoxes

– Based on administrative domains. – Able to express many types of policies.

ACLs Management Policies Policies depending on environmental parameters

• Policy distribution– Resistant to network failures


INFSO-RI-508833

SITESITE SITESITE SITESITE SITESITE

GRIDGRIDGRIDGRID

VOVO

Architecture of G-PBox

PBoxPBox

PBoxPBoxPBoxPBox

PBoxPBoxPBoxPBox PBoxPBox PBoxPBox

PBoxPBoxPBoxPBox PBoxPBox

SubSITESubSITESubSITESubSITE SubSITESubSITE


INFSO-RI-508833

Architecture of G-PBox (contd.)

• PBoxes are the basic elements. They:– Receive and evaluate requests.– Originate and distribute policies.

• (At least) One PBox for administrative domain.• All PBoxes are structurally identical.• A PBox permits connections only from specific clients.


INFSO-RI-508833

Internal components

1 internal componentPR

3 boundary componentsPCIPATPDP

PAT

PDP

PR

PCI

PR Repository of the

PBox policies

PAT

PCI

PDP

PR

PCI

PCI

Communication interface

with other PBoxes (via GSI)

PDP

PEP PDPAction of useron resource

Module that receive policy evaluation

requests by PEP and determine the

results

PAT

PAT

Entry point of PBox to manage

PR and PCI functionalities


INFSO-RI-508833

Policy Propagation: Why?

• Policy propagation ensures that a PBox will always be capable of evaluate the last set of accepted policies even in case of network failures.– Propagation only happens among neighboring levels on a direct

father/child relationship. – Site admins will be able to explicitly:

Know the VO wishes, and check them against an existent AUP. Grant or refuse them.


INFSO-RI-508833

Policy propagation: How?

• The policy propagation module is based on a policy publishing service.

• Each PBox publishes a list of accepted PBoxPolicies metadata (PBoxPolicyId, Wished Status, Current Status, PBoxNickName list,Timestamp).

• Each PBox asks its neighbors to get a set of metadata.

• If the PBoxNickName list contains the PBox name, then it means that the policy is relevant for iself, so it has to get it and store it into its Policy Repository (PR).

• The PBox administrator can change the current status (Accepted, Rejected, Unknown, Removed) of each policy.


INFSO-RI-508833

Policy propagation

PBox APBox APBoxPolicy

metadata list

Publishing

PBox BPBox BPBoxPolicy

metadata list

Publishing

GetMetadataListMetadata

list

PRPRThe metadatalist containssomething relevant for me

The PBoxadmin changessome policiesstatus


INFSO-RI-508833

Policy status

• There are 2 kinds of policy status: Wished and Current.• The first one is created by the owner of the policy and

is the status the creator wants the policy to have.• The second one is relevant only for myself. If I accept a

policy coming from another level I have to change the current status from unknown to accepted, then I have to update my PDP server. – It is possible to setup a PBox as a “slave” of another PBox if

automatic acceptance is desired. Example: sublevels of a site PBox.


INFSO-RI-508833

Policy console

• Tool to administer the PBox. It will allow:– Policy Repository management– Policy editor (very simple)– Policy structure view (PBoxPolicy metadata and XACML)– Current Status management– Wished Status management

13


INFSO-RI-508833

Policy Evaluation:

• The client sends a request to its PEP, which rewrites it into the correct syntax and sends it to the PDP of its PBox (1)

• The PDP of the PBox sends back its answer (2)• The PEP translates the answer in a format recognized by the client.• Only ONE request and answer for each evaluation.

PEP PDP

1

2

A A client (for example a CE, SE, ecc.)client (for example a CE, SE, ecc.) must must implement a implement a

PEP (Policy Enforcement Point)PEP (Policy Enforcement Point)

client


INFSO-RI-508833

Policy Language

• Policies are expressed in XACML 1.1– XACML can be extended to also support policies needing

external data (ex: monitoring and accounting) It is done on a (very) limited set. Will be generalized to generic attributes. Allows the implementation of policies requiring knowledge of the

current grid status. E.g: “User X is allowed to submit a job only if the current disk usage of group /atlas/phys is less than 1T”

– The mechanism of Obligations is used to support administration policies.


INFSO-RI-508833

Status of the project

• The four main modules are finished.– They are committed into the EGEE

CVS.Module org.glite.gpbox


INFSO-RI-508833

What we can do:

• With the current version:– ACL policies– Local policies (user mapping)– Simple RBAC policies:

Depending on just one VOMS group/role.– Static Policies (quota, cpu share, etc… if they are specified by the

policy and/or the PEP) Need much support for this on the services though. Enforcement and data

collection.

• With the final product: (when integration with accounting and monitoring is complete)– Fair share.– Generic Storage.– Complex RBAC Policies

Depending on a combination of VOMS group/roles.– Policies in which the data needed for evaluation is taken from the

environment. Much less support needed from services. Essentially enforcement only.


INFSO-RI-508833

Information for services:

• APIs for C/C++/Java are available.– Services can use them to automatically construct XACML

requests, send them and parse XACML responses. Not only Deny/Allow are returned, but also Obligations

– However, services must have knowledge of possible obligations and honor them

– Services must do the real enforcements based on G-PBox answers.

• Demo quality implementations are available for LCAS, LCMAPS and RB

• We are in contact with CREAM developers for G-PBox integration.

• G-PBox is being integrated with WMS


INFSO-RI-508833

WMS & PBox: integration schema

WMS PBoxXACMLreqs

Attributes

Convert

Convertandfilter

XACMLresponse

Request

List of resources

•All the responses must be converted in a “readable” format for the WMSAll the responses must be converted in a “readable” format for the WMS•The policy enforcing process is the merging process between the resource list of The policy enforcing process is the merging process between the resource list of the WMS and the set of responses of the PBox.the WMS and the set of responses of the PBox.

List of resourcesafter policyenforcement


INFSO-RI-508833

G-PBox use case

Job submission Policies

VOMS server

Group A

Group B

Group C PBoxPBox

Policies

Group A : high priority CEsGroup B : low priority CEsGroup C : deny everywhere

CEHIGH

CELOW

RBRB


INFSO-RI-508833

Next steps

• Next week we will try to start a “real” test with CMS and ATLAS VOs (with one server for RB-PBox communications).

• Software consolidation for Egee time deadline (15/10/2005).

• PDP extensions with new attributes regarding Grid environments.

• G-PBox interfaces for DGAS and GridICE communications (for policies needing accounting and monitoring data).


INFSO-RI-508833

Under investigation:

• Implement Web Service interface for PEP-PDP communications and Admin interface.


INFSO-RI-508833

Example of policy<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy cs-xacml-schema-policy-01.xsd" PolicyId="xacmlid_3working“ RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"> <Description> Users of /CMS/PHYS can submit jobs to pbox2.cnaf.infn.it with priority 2 </Description> <Target><Subjects><Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/CMS/PHYS</AttributeValue> <SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"/>

</SubjectMatch> </Subject></Subjects> <Resources><Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">pbox2.cnaf.infn.it</AttributeValue> <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0: resource:resource-id"/> </ResourceMatch>

</Resource></Resources> <Actions><AnyAction/></Actions> </Target> <Rule RuleId="AttrCheck" Effect="Permit"> <Target>

<Subjects><AnySubject/></Subjects> <Resources><AnyResource/></Resources> <Actions><Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">job-submission</AttributeValue> <ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/> </ActionMatch> </Action></Actions>

</Target> </Rule> <Obligations> <Obligation ObligationId=“UserPriority" FulfillOn="Permit"> <AttributeAssignment AttributeId=“log" DataType="http://www.w3.org/2001/XMLSchema#integer">2</AttributeAssignment> </Obligation> </Obligations> </Policy>


INFSO-RI-508833

Example of policy - details

• User <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> /CMS/PHYS </AttributeValue>

<SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"/>

</SubjectMatch>

• Resource <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

pbox2.cnaf.infn.it

</AttributeValue> <ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/> </ResourceMatch>


INFSO-RI-508833

Example of policy – details (contd.)

• Action: <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

job-submission

</AttributeValue>

<ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/>

</ActionMatch>

• Priority: <Obligations> <Obligation ObligationId=“UserPriority" FulfillOn="Permit"> <AttributeAssignment AttributeId=“log” DataType="http://www.w3.org/2001/XMLSchema#integer"> 2 </AttributeAssignment> </Obligation> </Obligations>


INFSO-RI-508833

Working group

• Andrea Caltroni (INFN PD)• Vincenzo Ciaschini (INFN CNAF)• Andrea Ferraro (INFN CNAF)• Gian Luca Rubini (INFN CNAF)

infso-ri-508833 enabling grids for e-science g-pbox auth meeting 13/9/2005 presenter: vincenzo...

Documents