INFSO-RI Enabling Grids for E-sciencE G-PBox Auth meeting 13/9/2005 Presenter: Vincenzo Ciaschini

Enabling Grids for E-sciencE INFSO-RI 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!

Enabling Grids for E-sciencE INFSO-RI 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.

Enabling Grids for E-sciencE INFSO-RI 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

Enabling Grids for E-sciencE INFSO-RI SITE SITE SITESITE GRID GRID VO Architecture of G-PBox PBox PBox PBox PBoxPBoxPBoxPBox PBox PBoxPBox SubSITE SubSITE SubSITE

Enabling Grids for E-sciencE INFSO-RI 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.

Enabling Grids for E-sciencE INFSO-RI Internal components 1 internal component PR 3 boundary components PCI PAT PDP PAT PDP PR PCI PR Repository of the PBox policies PAT PCI PDP PR PCI Communication interface with other PBoxes (via GSI) PDP PEPPDP Action of user on resource Module that receive policy evaluation requests by PEP and determine the results PAT Entry point of PBox to manage PR and PCI functionalities

Enabling Grids for E-sciencE INFSO-RI 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.

Enabling Grids for E-sciencE INFSO-RI 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.

Enabling Grids for E-sciencE INFSO-RI Policy propagation PBox A PBoxPolicy metadata list Publishing PBox B PBoxPolicy metadata list Publishing GetMetadataList Metadata list PR The metadata list contains something relevant for me The PBox admin changes some policies status

Enabling Grids for E-sciencE INFSO-RI 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.

Enabling Grids for E-sciencE INFSO-RI 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

Enabling Grids for E-sciencE INFSO-RI 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. PEPPDP 1 2 A client (for example a CE, SE, ecc.) must implement a PEP (Policy Enforcement Point) client

Enabling Grids for E-sciencE INFSO-RI 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.

Enabling Grids for E-sciencE INFSO-RI Status of the project The four main modules are finished. – They are committed into the EGEE CVS.  Module org.glite.gpbox

Enabling Grids for E-sciencE INFSO-RI 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.

Enabling Grids for E-sciencE INFSO-RI 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

Enabling Grids for E-sciencE INFSO-RI WMS & PBox: integration schema WMS PBox XACML reqs Attributes Convert and filter XACML response Request List of resources All the responses must be converted in a “readable” format for the WMS All 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 WMS and the set of responses of the PBox. The policy enforcing process is the merging process between the resource list of the WMS and the set of responses of the PBox. List of resources after policy enforcement

Enabling Grids for E-sciencE INFSO-RI G-PBox use case Job submission Policies VOMS server Group A Group B Group C PBox Policies Group A : high priority CEs Group B : low priority CEs Group C : deny everywhere CE HIGH CE LOW RB

Enabling Grids for E-sciencE INFSO-RI 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).

Enabling Grids for E-sciencE INFSO-RI Under investigation: Implement Web Service interface for PEP-PDP communications and Admin interface.

Enabling Grids for E-sciencE INFSO-RI Example of policy <Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi=" 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"> Users of /CMS/PHYS can submit jobs to pbox2.cnaf.infn.it with priority 2 /CMS/PHYS " pbox2.cnaf.infn.it " resource:resource-id job-submission " 2 "

Enabling Grids for E-sciencE INFSO-RI Example of policy - details User " /CMS/PHYS " Resource " pbox2.cnaf.infn.it "

Enabling Grids for E-sciencE INFSO-RI Example of policy – details (contd.) Action: " job-submission " Priority: <AttributeAssignment AttributeId=“log” DataType=" 2

Enabling Grids for E-sciencE INFSO-RI Working group Andrea Caltroni (INFN PD) Vincenzo Ciaschini (INFN CNAF) Andrea Ferraro (INFN CNAF) Gian Luca Rubini (INFN CNAF)