Deployment Plan for caGrid-SHA

This describes a plan for upgrading existing grids based on caGrid 1.4 to run with caGrid 1.5.

Objectives and Purpose

The security infrastructure of caGrid 1.X currently uses a SHA-1 hash when creating and signing host certificates and user credentials. The use of SHA-1 algorithms was deprecated for usage in NCI applications by NIST. CaGrid has an exemption for SHA-1 usage through 2011. The caGrid 1.5 projects updates the security infrastructure to use SHA-2 hashes in the creation of certificates and credentials.

Unfortunately, the changes in caGrid required to support SHA-2 break backwards compatibility with caGrid services and clients that can only consume SHA-1 signed certificates. The caGrid 1.5 project will require all services and clients to be upgraded to 1.5.

Upgrading a grid will involve standing up a new grid and then migrating everything from the old grid to the new grid.

All Stakeholders

• caGrid Development Team
• caGrid Knowledge Center
• CBIIT
• NCI
• NIH
• All parties hosting caGrid services.
• All users/consumers of caGrid services.

Scope

This describes a plan for migrating the existing NCI development, staging, production and training grids from a caGrid 1.4 based infrastructure to caGrid 1.5. This document is structured in such a way as to allow to be used as a template for migrating other existing grids from caGrid 1.2 - 1.4 based infrastructures to caGrid 1.5.

This document describes a deployment process.

• A high level description of the process is presented in the Deployment Strategy section.
• An overview of the high-level activities that will be performed in the course of this process is in the Deployment Overview section.
• A detailed description of the process is in the Deployment Approach section.
• A detailed timeline for the deployment is in the Schedule section.
• The risks to the successful completion of this plan and strategies for their mitigation are in the Risks and Mitigation Strategies section.
• The documentation that will be needed for and during this plan is described in the Documentation section.
• Suggested training is summarized in the Training section.

Assumptions

For previous versions of caGrid, not upgrading a service or client has been a workable option. This will not be an option for the upgrade to 1.5. The only options for services and their clients will be to upgrade or decommission.

It is assumed that the following will be true before the start of the deployment process:

• caGrid 1.5 software will be well tested and will have met specified criteria for release.
• A communications plan will have been developed that identifies the who will need to receive what notices, reports and other forms of communication. The communications plan will involve warning all stakeholders ASAP of the upcoming migration while leaving the details and schedules as TBA.
• Migration or other scripts that are needed to support the deployment process will be ready for use. A list of these scripts appears in the Scripts section. The details of each script are described elsewhere in this document.
• None of the NCI grids are in a federated trust relationship that requires them to consume trust information from a third party GTS service.
• Both the communications and deployment plans will evolve in the course of their execution. It is therefore assumed that a governance structure will be in place that is sufficient to keep activities well coordinated yet flexible.
• Introduce 1.5 will contain an upgrader to re-generate 1.2 services as 1.5 services.
• Introduce 1.5 will contain an upgrader to re-generate 1.3 services as 1.5 services.
• Introduce 1.5 will contain an upgrader to re-generate 1.4 services as 1.5 services.
• There will be a transition period when people are registering host and user identities with the new grid to replace the identities they used in the old grid. During this period there will be a higher than normal number of requests for grid administrators to approve host and user certificate requests. We assume that during this period, someone will be designated to check for and approve these requests.
• Before any non-core data services are migrated to a 1.5 grid, authors or maintainers of introduce custom data styles will have completed successful testing of all custom data styles.
• None of the NCI grids are involved in a circular trust relationship.

Deployment Strategy

The NCI grids will be migrated in this order: training (development), QA, staging and production. The technical steps for migrating each grid will be the same. They will vary in

• the hosts and clients involved
• the communications plan (the people who need to be notified)
• the schedule.

The migration of each grid will follow its own schedule. The migration schedules of grids are likely to overlap.

The major steps of each upgrade will include:

• Identify administrators of third party grids that have a federated trust relationship with the NCI grid and consume trust information from the NCI grid's GTS service. Notify the administrators of the third parts grids that they will be required to migrate or loose access to the NCI grid.
  
  
• Develop instructions for people to upgrade services using Introduce from 1.2/1.3/1.4 to 1.5.
  
  
• Develop a guide to help people upgrade custom-coded services (it is unclear if this will be actually needed).
  
  
• Notify the owners of all user and host grid identities of the plans to perform the migration to 1.5. The notification should include a summary of this plan that details what will need to be done to migrate hosts and clients. The summary should also specify the hard migration deadlines and specify preliminary dates for other milestones.
  
  
• Stand up a full set of core services for the 1.5 version of the grid.
  
  
• Begin a freeze on the issuance of new grid identities (user and host) on the 1.4 training grid.
  
  
• Work with administrators of the various groups and stems in the 1.4 GridGrouper to create the corresponding entries in 1.5 GridGrouper.
  
  
• Work with administrators of authentication services to install a 1.5 authentication service.
  
  
• Test Dorian, the other core services and the authentication services.
  
  
• Allow the issuance of new grid identities for the 1.5 grid.
  
  
• Issue a final migration schedule.
  
  
• Train the Knowledge Center.
  
  
• For each service outside of the core services, run a migration script that will migrate the service in-place to the 1.5 grid.
  
  
• Shut down the old 1.4 core services.

Deployment Overview

This sections contains an overview of the tasks to be performed as part of the migration from 1.4 to 1.5. Finalizing the contents of this section will require some internal planning and negotiation with the community. The contents of the schedule section will be based on this section.

Deployment Approach

A detailed description of the deployment phases and tasks goes here

Deployment Approach

The tasks that make up the migration effort for each NCI grid will be organized into phases

The current descriptions of phases are just stubs to be fleshed out.

Phase 0

Tasks that involve internal planning, initial negotiation with the community and writing documentation go here.

Phase 1

Tasks that involve setting up core 1.5 infrastructure prior to the involvement of the community go here. This includes cycles of:

• Use a release candidate to set-up the core services for a grid.
• test the core services for the grid.
• fix bugs.

Migration of no NCI grids should go beyond phase 1 until all internal testing is successfully completed.

Phase 2

Tasks that involve setting up 1.5 infrastructure with the involvement of the community go here.

Phase 2 begins by notifying the KC that the grid in question is entering phase 2.

Phase 3

Tasks that involve decommissioning 1.4 core services and winding down the deployment effort go here.

Schedule

The schedule will account for the following dependencies:

• The 1.4 NCI training GTS consumes trust information from the 1.4 NCI production grid. The 1.5 training grid will have a similar dependency on the 1.5 production grid.

The current contents of this section are just some sample tasks. This needs to be filled in.

Risks and Mitigation Strategies

Other risks and mitigation strategies go here.

Documentation

This is an list of the documentation to be developed.

Training

Descriptions of training to be offered in conjunction with the deployment goes here

Scripts

A part of this deployment process will be the development of some scripts.