grid computing

Abstract:
Grid computing allows you to unite pools of servers, storage systems, and networks into a single large system so you can deliver the power of multiple-systems resources to a single user point for a specific purpose. To a user, data file, or an application, the system appears to be a single, enormous virtual computing system. The major purpose of a grid is to virtualize resources to solve problems. The main resources grid computing is designed to give access to include (but are not limited to):
• Computing/processing power
• Data storage/networked file systems
• Communications and bandwidth
• Application software
Since the concept of putting grids into real-world practice is still relatively new, another good way to describe a grid is to describe what it isn't. The following entities are not grids:
• Cluster
• Network-attached storage device
• Scientific instrument
• Network
Each might be an important component of a grid, but by itself, doesn't constitute a grid. So, what does it take to make the vision of the grid-computing concept a reality? It requires standard and seamless, open, general-purpose protocols and interfaces, all of which are being defined now and are similar to those that enable access to information from the Web.
Key Terminology:
In the following discussion, we use the following terminology from the security literature:
A credential is a piece of information that is used to prove the identity of a subject. Passwords and certificates are examples of credentials.
Authentication is the process by which a subject proves its identity to a requestor, typically through the use of a credential. Authentication in which both parties (i.e., the requestor and the requisite) authenticate themselves to one another simultaneously is referred to as mutual authentication.
Authorization is the process by which we determine whether a subject is allowed to access or use an object.
A trust domain is a logical, administrative structure within which a single, consistent local security policy holds. Put another way, a trust domain is a collection of both subjects and objects governed by single administration and a single security policy.

Grid Security Challenges:
Security requirements within the Grid environment are driven by the need to support scalable, dynamic, distributed virtual organizations (VOs) collections of diverse and distributed individuals that seek to share and use diverse resources in a coordinated fashion. A fundamental requirement is thus to enable VO access to resources that exist within classical organizations and that, from the perspective of those classical organizations, have policies in place that speak only about local users. This VO access must be established and coordinated only through binary trust relationships that exist between (a) the local user and their organization and (b) the VO and the user. We cannot, in general, assume trust relationships between the classical organization and the VO or its external members. Grid security mechanisms address these challenges by allowing a VO to be treated as a policy domain overlay as shown in Figure 1. Multiple resources or organizations outsource certain policy control(s) to a third party, the VO, which coordinates the outsourced policy in a consistent manner to allow for coordinated resource sharing and use. Complicating Grid security is the fact that new services (i.e., resources) may be deployed and instantiated dynamically over a VO’s lifetime. For example, a user may establish personal stateful interfaces to existing resources, or the VO itself may create directory services to keep track of VO participants.
1. Multiple security mechanisms: Organizations participating in a VO often have significant investment in existing security mechanisms and infrastructure. Grid security must interoperate with, rather than replace, those mechanisms.
2. Dynamic creation of services: Users must be able to create new services (e.g., “resources”) dynamically without administrator intervention. These services must be coordinated and must interact securely with other services.
3. Dynamic establishment of trust domains: In order to coordinate resources, VOs need to establish trust among not only users and resources in the VO but also among the VO’s resources, so that they can be coordinated. These trust domains can span multiple organizations and must adapt dynamically as participants join, are created, or leave the VO.


Figure 1: A virtual organization policy domain overlay pulls together participants from disparate domains into a common trust domain.
The GT3 Security Model for OGSA:
OGSA defines standard Web service interfaces and behaviors that add to Web services the concepts of stateful services and secure invocation, as well as other capabilities needed to address Grid-specific requirements that are not relevant for this paper. These interfaces and behaviors define what is called a “Grid service” and allow users to manage the Grid service’s life-cycle, as allowed by policy, and to create sophisticated distributed services. Version 3 of the Globus Toolkit (GT3) and its accompanying Grid Security Infrastructure (GSI3) provide the first implementation of OGSA mechanisms. GT3’s security model seeks to allow applications and users to operate on the Grid in as seamless and automated a manner as possible. GT3 uses the following powerful features of OGSA and Web services security to work toward this goal:
1. Casts security functionality as OGSA services to allow them to be located and used as needed by applications.
2. Uses sophisticated hosting environments to handle security for applications and allow security to adapt without having to change the application.
3. Publishes service security policy so that clients can discover dynamically what credentials and mechanisms are needed to establish trust with the service.
4. Specifies standards for the exchange of security tokens to allow for interoperability.
In the following subsections we describe how each of these features is used in our GT3 OGSA security model. We then explain how they are used together to support seamless Grid security.
The GT3 OGSA Security Model in Action:
Figure 3 shows a simplified example of the GT3 OGSA security model in action. The OGSA client on the left makes a request to the OGSA service on the right. Both client and service are contained in advanced hosting environments that handle all security functionality for their respective contained application and service. The client first forms a request intended for the OGSA service and passes the request to its hosting environment for processing and delivery.


Figure 2: Example of a secured request in the OGSA security model
The following steps are taken to handle the security of the request:
1. The client’s hosting environment retrieves and inspects the security policy of the target service to determine what mechanisms and credentials are required to submit a request.
2. If the client’s hosting environment determines that the needed credentials are not already present, it contacts a credential conversion service to convert existing credentials to the needed format, mechanism, and/or trust root.
3. The client’s hosting environment uses a token processing and validation service to handle the formatting and processing of authentication tokens for exchange with the target service. This service relieves the application and its hosting environment from having to understand the details of any particular mechanism.
4. On the server side, the hosting environment likewise uses a token processing service to process the authentication tokens presented by the client. (In the example, both use the same service, but each could use a separate service.)
5. After authentication and the determination of client identity and attributes, the target service’s hosting environment presents the details of the request and client information to an authorization service for a policy decision.
If all these steps complete successfully, the target service’s hosting environment then presents the authorized request to the target service application. The application, knowing that the hosting environment has already taken care of security, can focus on application-specific request processing steps.
GT3 Security Implementation:
The Grid Security Infrastructure version 3 (GSI3) of the Globus Toolkit version 3 is an initial implementation of key components of the OGSA security model.
The key advantages of GT3 model are:
• Use of WS-Security protocols and standards: GT3 uses SOAP and the Web services security specifications for all of its communications. This allows it to leverage and use standard current and future Web service tools and software.
• Tight least-privilege model: GT3 resource management implementation uses no privileged services. All privileged code is contained in two small, tightly constrained setuid programs. We describe here how these two advantages are implemented in GT3 and describe the GT3 Grid Resource Acquisition and Management (GRAM) system, which illustrates all key GSI3 components.
Use of Web Services Security and Protocol:
GT3 uses Web services specifications to allow security messages and secured messages to be transported, understood, and manipulated by standard Web services tools and software. GT3 offers both stateful and stateless forms of secured communication.
Stateful: Like GT2, GSI3 supports the establishment of a security context that serves to authenticate two parties to each other and allows for the exchange of secured messages between the two parties. GT2 uses the TLS transport protocol for both security context establishment and message protection. Our GT3 implementation achieves security context establishment by implementing WS Secure Conversation and WS-Trust, which use SOAP messages to transport context establishment tokens between the two parties. The GT3 messages carry the same context establishment tokens used by GT2 but transport them over SOAP instead of TCP. Once the security context is established, GSI3 implements message protection using the Web services standards for secured messages.
Stateless: To allow for communication without the initial establishment of a security context, GT3 also offers the ability to sign messages independent of any established security context, by using the XML-Signature specification. Thus, a message can be created and signed, allowing the recipient to verify the message’s origin and integrity, without establishing synchronous communication with the recipient. A feature of this approach is that the identity of the recipient does not have to be known to the sender when the message is sent.
Tight Least-Privilege Model:
“Least privilege” is a well-known principle in computer security that states that each entity should only have the minimal privilege needed to accomplish its assigned role and no more. GT3 introduces two notable features that improve its security through the least privilege principle. No privileged services. Network services, since they accept and process communications from outside the resource, are prone to compromise by remote users through logic errors, buffer overflows, and the like. GT3 removes all privileges


Figure 3: A requestor initiating a job with the GT3 GRAM system.
from these services, significantly reducing the impact of compromises by minimizing the privileges gained. Minimal privileged code. In GT3, the privileged code is confined to small programs, each of which performs a specific function and works only with local users, accepting no network connections. The simple and well-constrained functionality of these programs allows them to be audited effectively and reduces the chance that they can be used maliciously to gain privilege elevation.
GT3 GRAM Implementation:

We introduce the GSI3 implementation by describing how it is used in GT3’s GRAM system. GRAM is a fundamental GT service enabling remote clients to instantiate, manage and monitor, in a secure fashion, computational tasks (“jobs”) on remote resources. While GT3 offers a number of other services, GRAM is the most complicated service in GT3 from a security perspective because it provides for the secure, remote, dynamic instantiation of processes, involving both secured interaction with a remote client and the local operating system. To invoke a job-using GRAM, a client describes the job to be run, specifying such details as the name of the executable, the working directory, where input and output should be stored, and the queue in which it should run. This description is sent to the resource and ultimately results in the creation of an instance of a Managed Job Service (MJS). An MJS is created by invoking a create operation on a MJS factory service. While conceptually we want to run one MJS factory service per user account, this approach is not ideal in practice because it involves resource consumption by factories that sit idle when the user is not using the resource. Thus GT3 introduce an additional construct, the Master Managed Job Factory Service (MMJFS). One MMJFS runs on each resource, in a non-privileged account, and invokes Local Managed Job Factory Services (LMJFS) for users in their account as needed. A service called a Proxy Router routes incoming requests from a user to either that user’s LMJFS, if present, or the MMJFS, if a LMJFS is not present for the user making the request. All MJS and MJS factories are implemented as Grid services running in a hosting environment. This approach allows for the creation of multiple services in a lightweight manner. Figure 3 shows a requestor initiating a job in the GT3 GRAM architecture.

1. The requestor forms a job description and signs it with appropriate GSI credentials. This request is sent to the target resource on which process initiation is desired.
2. The Proxy Router service accepts the request and either routes it to an LMJFS, if present (skip to step 6), or to the MMJFS otherwise (on to step 3).
3. The MMJFS verifies the signature on the request and establishes the identity of the requestor. It then determines the local account in which the job should be run based on the requestor’s identity using the grid-map file.
4. The MMJFS invokes the Setuid Starter process to start a LMJFS for the requestor. The Setuid Starter is a privileged program (typically setuid-root) whose sole function is to start a preconfigured LMJFS for a user.
5. When a LMJFS starts, it needs to acquire credentials and register itself with the Proxy Router. To register, the LMJFS sends a message (not shown) to the Proxy Router.
6. The LMJFS receives the signed job request. The LMJFS verifies the signature on the request to make sure it has not been tampered with and to verify the requestor is authorized to access the local user account in which the LMJFS is running. Once these verifications are complete, the LMJFS invokes an MJS with the job initiation request and returns the service reference of the MJS to the user.
7. The requestor connects to the MJS to initiate the job. The requestor and MJS perform mutual authentication, the MJS using the credentials acquired from GRIM. The MJS verifies that the requestor is authorized to initiate processes in the local account. The requestor authorizes the When making this connection, the user also delegates GSI credentials to the MJS for the job.
Conclusion:
Grid computing presents a number of security challenges that are met by the Globus Toolkit’s Grid Security Infrastructure (GSI). Version 3 of the Globus Toolkit (GT3) implements the emerging Open Grid Services Architecture; its GSI implementation (GSI3) takes advantage of this evolution to improve on the security model used in earlier versions of the toolkit. GSI3 remains compatible (in terms of credential formats) with those used in GT2, while eliminating privileged network services and making other improvements.
References:
1. www.gridforum.org
2. www.gridcomputing.com/
3. www.grid.org