Grid Computing and Security

Table of Contents

1. Introduction
2. Setting Up Certificates And Certificate Authorities
3. Preparing For A User To Use A Grid Resource
4. Initiating the use of a grid resource
5. References

Introduction

• This document is intended to provide an overview of the process and protocols used to establish and use the resources of a computational grid using the GSI (Grid Security Infrastructure) security model provided by the Globus toolkit.
• The primary means of authentication in GSI is through SSLv3 using X.509v3 certificates for credentials. An entity will generate a public/private key pair. The entity will combine its public key and other information about itself into a certificate request.
• There will be at least one certificate authority (CA) in the network. Often there will be many CA's involved in a grid network. Each CA has its own public/private keypair. It uses its private key to sign certificate requests from other entities, producing a certificate for that entity. By signing a certificate, the CA is certifying that the information contained in the certificate is correct and that the public key actually belongs to the entity presenting it.
• When entity A wants to authenticate itself to entity B, entity A presents its certificate to B. B will provide A with a short piece of random data, called a nonce. A encrypts/signs the nonce with its private key and returns it to B.

  B then looks at A's certificate to obtain its public key. Next, B can decrypt the nonce using A's public key. If the nonce decrypts correctly with the public key, then B knows that A posseses the corresponding private key. The only question remaining is whether or not the public key really belonged to A.

  This is where the CA comes in. The CA signed A's certificate with its private key. B maintains a copy of the CA's public key for each CA it trusts. Therefore, B uses the CA's public key to verify the signature on A's certificate.

  Assuming the signature matches, then the public key in A's certificate really belongs to A and B has authenticated A. Also, B can trust the information in A's certificate since it was verified by the CA.

Setting up certificates and certificate authorities

• Every entity in the grid must have a certificate that is signed by some CA. An entity can be a user, computer, or some other type of resource. The certificate will include information such as a serial number, when it is valid, which CA signed it, the entities public key, and a subject. The CA will require some proof of the information before it signs the certificate.

  The subject uniquely identifies the entity on the grid. It is composed of an organizational structure and a common name. For example, the following user subject: "O=Princeton, OU=PALMS, CN=Jeffrey Dwoskin". This subject indicates the virtual organization of Princeton. Within Princeton, the user is in the organizational unit of PALMS (a group within the organization). Finally, the common name is Jeffrey Dwoskin, which in this case belongs to a user, me.

  Similarly, a host might have a subject such as: "O=Princeton, OU=PALMS, CN=host/pipe.ee.princeton.edu". Here, the common name indicates a host instead of a user and the hostname is pipe.ee.princeton.edu.

• Each virtual organization may run its own certificate authority (CA). The members of a virtual organization can be a real organization, part of an organization, or a group of organizations. The CA will sign all of the certificates of its members and verifies the information contained in those certificates for other entities that trust it. Alternatively a centralized or a commercial CA can be used.
• Every entity must maintain a list of CA's that it trusts. For each CA it stores a copy of the CA's certificate which contains a public key. It also stores what it trusts that CA to do. For example, a Princeton University CA may be trusted only for the certificates with subjects starting with O=Princeton.

Preparing for a user to use a grid resource

• A Grid can be used to access any type of resource, such as computation, storage, printing, displays, etc. For the purposes of this document it will be assumed that the user is accessing computation on a specific remote host. Where it is convenient, other methods will be discussed as well.
• Before a user can access a host, a local account must be created for their use. Other types of resources may not require a local account. A mapping must then be created from their global/Grid identification (the user's subject) to the local account. This is done in the grid-mapfile file. The user's task will later be managed by the local security policy using this local account.

  It is possible for multiple Grid subjects to map to the same local account or group of local accounts. If this is the case, it is the responsibility of the local security policy on the resource to ensure the protection of the user's data from other Grid or local users.

• If the user will request access to multiple resources, local accounts must be acquired, and mappings created on each resource. The user may also want to access any available resource instead of a sepecific resource. Again, in this case, local accounts and mappings must be acquired on each resource that might be used.
• Additionally, the resource must trust the CA that signed the user's certificate in order to authenticate the user. If this is not already the case, the user's CA's certificate will need to be added by the administrator of the resource.

Initiating the use of a grid resource

1. The user creates a user proxy using the command grid-proxy-init. The user proxy (UP) is given a new certificate with its own keypair that is only valid for a limited time, usually 24 hours.

   The user signs the UP's certificate with its private key, allowing the UP to act on its behalf while the certificate is valid. In addition to the time limitation, the user may put further restrictions on what the UP can do by listing them inside the certificate.

   The user often encrypts their private key with a password. This will be the only time the password is required so that the user can sign the UP's certificate with its private key. After this point, the UP's certificate will be used and the user will not have to "log in" again. This implements the idea of a single sign on.

2. The user then runs globus-job-run to initiate a program/job to run on a remote host. In this simple case, the user specifies which host to run on and what program to run. This causes the grid software to act as the user proxy to complete the process and the user doesn't need to do anything further until the results are ready.
3. The user proxy now connects to the gatekeeper of the remote host. The gatekeeper is a process on each grid host that listens for incoming requests from users (really their user proxies) and sends them to the appropriate resource.

   First, the gatekeeper and the user proxy perform mutual authentication. This means that the user proxy checks the identity of the gatekeeper and the gatekeeper checks the identity of the user.

   Like the user, each host also has a certificate signed by a CA. The user proxy uses the process described above to check that certificate so it can trust the host and its gatekeeper.

   Similarly the gatekeeper checks the user proxy's certificate. However its certificate was signed by the user and not a CA. Therefore the gatekeeper first checks the UP's certificate against the the user's certificate. Then it checks the user's certificate against the CA, which it trusts. Then it can be sure that the user proxy is really acting on the user's behalf.

   After mutual authentication, both the user and gatekeeper can be sure they are talking to each other and not a malicious third party, assuming no party's private key has been compromised.

4. Next the gatekeeper decides whether or not the user is allowed to use its services. This is determined by an entry in the grid-mapfile file with the user's Grid subject. If such an entry is not found, then the user is not authorized to use the host and the gatekeeper will reject the user's request. Once the user is authorized, the gatekeeper sends the user's request to a resource manager.
5. In this case, the gatekeeper is on the same host as the resource the user wants to use. The gatekeeper must first map the grid user to a local user. The local user is subject to the local security policies imposed by the host.

   The mapping of the grid subject to a local user is part of the user's entry in the grid-mapfile file. It is possible to have multiple grid users map to the same local user. If they are allowed to run at the same time as the same local user, or they leave files on the host, some other local mechanism may be necessary to protect the users' processes and data from each other.

   If the user was using multiple resources in parallel or letting the grid choose where to run its job, then the gatekeeper would forward the user's request to a grid resource manager to choose where to send it.

6. Once the grid user has been mapped to a local user, the gatekeeper starts a resource/job manager on the local host as the local user. The job manager must now allocate any necessary local resources that will be necessary to handle the user's request. It is also responsible for all future communication with the user.

   The job manager will send a contact string to the user. It can be used to check on the status of a job or to cancel a job in progress.

7. The job manager also allows the user to upload data or executables that are needed. This is done with a facility called Global Access to Secondary Storage (GASS). If GASS is used, the job manager contacts the user to receive the files before starting the job. GASS is also used to keep track of the output of a user's jobs.
8. When all of the data and executables are present on the remote host, the job manager starts the job for the user and sends back the output.

References

This overview has been compiled using information from many of the papers and links that I have listed.