Presented By: Mohit Modi

(BT08CSE043)

The concept of grid computing is not new. In a way, it is nothing but parallel or distributed computing; however, the difference lies in the scale and complexity! So imagine parallel processing at a level where instead of sharing one or more resources, each and every computing resource is shared among all the computers within the network (as if they form an interconnected grid). Now imagine that the grid can consist of several different authorized heterogeneous systems, even owned by different organizations! It would be like a huge supercomputer with unmatched processing power, memory capacity and data storage capacity suitable for the most complex computations, but really it is just a network of interconnected computers. As far as the user of a grid computer is concerned, he/she is just using the local computer (now a supercomputer owing to the grid links) unaware of the links contributing to the power and enormous complexity of the network grid or cluster to which that machine belongs.

In order to provide: ◦ Confidentiality ◦ Authentication ◦ Message integrity ◦ Nonrepudiation

But Grid Security is difficult: ◦ Use of valuable resources, solving sensitive problems ◦ Distinct domains (own policies, procedures) ◦ A single computation might require a large and unpredictable set of resources ◦ Broad availability and applicability

Motivations:

Secure communication (authentication and

perhaps confidentiality) between elements of

a computational Grid.

Security across organizational boundaries,

thus prohibiting a centrally-managed security

system.

“Single sign-on" for users of the Grid,

including delegation of credentials for

computations that involve multiple resources

and/or sites.

Also known as Public Key Infrastructure (PKI).

User (or entity) gets a related key pair:

◦ A private key - known only to the user.

◦ A public key – in the public domain.

A message encrypted with one key requires

the other key for decryption.

Digitally "sign" a piece of information using public key cryptography. To sign a piece of information: ◦ The sender computes a mathematical hash of the information. ◦ Using the private key, he/she encrypts the hash, and

attaches it to the message (the recipient has the public key). To authenticate the information: ◦ The recipient computes the hash using the same algorithm. ◦ Using the public key, he/she decrypts the encrypted hash. Match? – Then the sender has signed the message and it is intact.

The Certificate - a central concept in GSI authentication. It identifies and authenticates every user and service on the Grid. A GSI certificate includes four primary pieces of information: ◦ A subject name, which identifies the person or object that the certificate represents. ◦ The public key belonging to the subject. ◦ The identity of a Certificate Authority (CA) that has signed the certificate to certify that the public key and the identity both belong to the subject. ◦ The digital signature of the named CA.

GSI certificates are encoded in the X.509 certificate format (a standard data format for certificates established by IETF). This certificate: ◦ identifies the subject and his/her institution; ◦ is created for the subject by the subject’s institution. An X.509 certificate includes: ◦ subject’s name; ◦ subject’s public key; ◦ name of the issuing CA; ◦ signature of issuing CA; ◦ validity dates (start and end dates); ◦ other - version information, etc.

At the end, Alice and Bob have established a connection to each other and are certain that they know each other’s identities.

GSI does not establish confidential (encrypted) communication between parties (by default). If it is desired, GSI can easily be used to establish a shared key for encryption. Related security feature – communication integrity. ◦ Integrity means that an eavesdropper may be able to read communication between two parties but is not able to modify the communication in any way.

GSI provides communication integrity by default.

Delegation capability in GSI – an extension of the

standard SSL protocol which reduces the number

of times the user must enter his passphrase.

A user needs to re-enter his/her passphrase if: ◦ several Grid resources are required for a computation;

◦ agents (local or remote) request services on behalf of a user;

◦ etc.

How to avoid this? - Create a proxy.

A proxy consists of a new certificate and a

private key.

The new certificate (proxy certificate): ◦ contains the owner's identity, modified slightly to indicate that it is a proxy;

◦ is signed by the owner, rather than a CA.

Proxies have limited lifetimes. ◦ The proxy certificate includes a time notation

after

which the proxy should no longer be accepted by

others.

The proxy's private key might be stored in a local storage system without being encrypted (since the proxy is not valid for very long). Mutual authentication when using proxies: ◦ The remote party receives the proxy's certificate (signed by the owner) and the owner's certificate.

◦ The signature on the proxy certificate is validated using the owner's public key (obtained from his/her certificate).

◦ The signature on the owner's certificate is validated using the CA's public key. ◦ A chain of trust from the CA to the proxy through the owner is established.

Single sign-on – used when there are service requests travelling through multiple security domains in GSI. GSI uses proxy certificates for single sign-on and delegation of rights to other entities.

What is really needed is to reduce the amount of

work the service has to do to establish

authorization, without doing so by looking up the

actual person. This is the sort of task that has been given to RBAC mechanisms. However the traditional view of people being given roles does not work very well in the grid either. The main issues are that it is very difficult to give people meaningful roles, and people understand different things by those roles. They do however make authorization much simpler as you are only checking whether a certain role can use a service.

Grid Computing Cloud Computing

Business Model

Typically, grid infrastructures are accessed by multiple, heterogeneous organizations or project teams that typically share a common goal and need access to a virtual supercomputer to work on a single task or a single set of tasks. However, the users or project sponsors would have to bear the enormous cost of setting up and maintaining and monitoring the grid. When compared to accessing a cloud infrastructure that charges only as per consumption of resources, the set-up costs of a grid along with the cost of ownership of resources (like network administration, maintenance staff, etc.) are likely to be phenomenally high.

A customer accessing a cloud infrastructure or service will pay the cloud provider on a pay-per-use basis. The business model relies on optimizing utilization such that the cost makes sense for the customer as well as brings profits to the provider. We can perhaps associate it to the use of utilities such as electricity, gas, etc., or purchasing in bulk, but only when there's a requirement or demand. The benefit is in achieving economies of scale. It's independent of whether the task requires computational power or increased storage capacity. The customer is ideally not involved with the building or maintenance of the cloud infrastructure or services. This feature of abstraction is common to both grid computing and cloud computing.

Computing Model

Grid computing does not have universal standards with regard to configuration of systems and software. Some software and most algorithms and codes require major restructuring in order to use all the benefits of "parallel processing" available with grid computing. Even data communication protocols are grid-specific. Since most resources are being shared, network congestion control, fairness in allocation, reduction in latency, etc., are factors governing the development of grid protocols. Standard protocols are just not agile or flexible to support grid infrastructures.

Cloud computing has a more commercial focus and is therefore, more flexible when compared to the grid model. For example, expansion of a business requiring more resources is as easy as informing your provider to avail their seamless and mostly automated expansion services. Even writing a new code etc., becomes less time-consuming with the use of generic software. Existing protocols such as Web Services (WSDL, SOAP), and some advanced Web 2.0 technologies such as REST, RSS, AJAX, etc., can be utilized in cloud-based systems.

Security

We have already seen that the grid infrastructure comprises diverse configurations and platforms. Hence, the security for such a system would be a consideration right from the setting up of the grid. Important factors considered are authentication (single sign-on), authorization, credential, conversion, auditing, and delegation. Typically, a grid infrastructure has operational autonomy which ensures greater security controls and protocols. However, providing a security layer to a grid infrastructure is a time-consuming process.

For obvious reasons (relative homogeneity of cloud systems), cloud security models are relatively simpler and less secure than that of grid computing. It is a matter of mutual understanding where the provider ensures protection of the customer's data and applications. Private cloud (where the infrastructure is dedicated to a single customer) and community cloud (cloud infrastructure shared between a finite set of multiple customers) are effective ways to restrict access to authorized, limited number of users. Cloud infrastructure typically use Web forms (over Secured Sockets Layer (SSL)) to create and manage account information for end-users. Encrypted communications ensure secure identity and password management.

Some Potential Issues

- Is there a possibility of lesser complexity in building grids? - Is there a possibility of developing ubiquitous standards for grid infrastructure?

- Does the cloud provider have a disaster management and recovery mechanism in place to deal with loss of customer's data? - Is there a backup/contingency plan in case of disasters to ensure business continuity? - What if the cloud provider exits the business or is acquired by another company, what happens to the customer's data and cloud operations?

Examples

- The European Organization for Nuclear Research (CERN) is one of the leading organizations running major grid computing initiatives including analyzing chemical compounds in the search for potential drugs for diseases such as avian flu. - SETI (Search for Extraterrestrial Intelligence) @Home project is one of the earliest grid initiatives that downloads and analyzes data from radio telescope. Participants simply need to download and run a program to join the grid network.

- Salesforce.com, Google App Engine, Microsoft Azure, and Amazon EC2 are famous cloud providers in the public domain (they provide services to anyone who needs them over the public Internet). - Other service providers include the open source AbiCloud, Elastichosts and NASA's Nebula platform.

From the above discussion of contrasting factors between grid computing and cloud computing, it is clear that it's not a simple matter of choosing one over the other. It seems as though cloud computing is more suited to businesses looking to derive value out of their IT operations in a streamlined fashion. The agility that comes with utilizing services from the cloud complements its scalability. The grid computing paradigm on the other hand, has been the traditional arena of funded scientific research although there are emerging instances of its use in biomedical, financial and industrial research. It now finds applications in weather modeling and weapons test simulations. In fact, web serving (serving requests of website content from users located all over the world) is an example of a commercial application that benefits from the grid infrastructure.