Securing the build, promotion, and deployment of your mainframe application
Robin Yehle Bobbitt, Jazz Jumpstart Team
Tim Feeney, Unleash the Labs
Last updated: April 8, 2013
Build basis: Rational solution for Collaborative Lifecycle Management 2012
Restricting access to Builds, Promotions and Deployments
In order to comply with organizational standards or for compliance reasons, you may want to constrain or otherwise limit who is able to perform builds, promotions, packaging and deployments to certain environments. For example, it may be fine for a developer to promote into the development test environment, but you wouldn’t want him to do so into the system integration test environment.First, to have visibility at all to the definitions to request these operations, you need to be a member of the Project Area and second have a Developer for IBM Enterprise Platforms license to act upon them. Therefore, the first order of limiting access to submit a request for such as a build is to not make outsiders members of the project area nor grant them a license that enables the Enterprise Extensions functionality.
Limiting project membership and license assignment is a very coarse grained approach; something more fine grained is needed. Fortunately, Rational Team Concert provides two additional mechanisms: role-based permissions governing the roles that can submit a request, and operation pre-conditions restricting the teams that can do so.
Rational Team Concert provides options to limit the roles that can request a Build, Promotion, Package and Deployment. Since the Rational Team Concert build system underlies all of these capabilities, a user must have the Request Build permission to request a dependency build, perform a promotion, create a package or request a deployment. One caveat to this is a source-only promotion, which doesn’t require a build to take place.
The next level of permissions governs the specific operations.
To request a Dependency Build, one need only have the Request Build permission from the previous figure. Permissions can be placed on the dependency build to limit whether a user can set the ignore changes flag on a file or request a full build regardless of the changes detected.
There are two types of promotion requests: Promote Components and Promote Work Items. To Promote Components, only the Request Build permission is needed. To Promote Work Items, the Promote Work Items permission is additionally needed.
To Create a Package by Work Item or Ship List, the Request Package permission is needed.
To request a Deployment, the Request Deployment permission is needed.
An additional layer of restrictions that may be placed on Builds, Promotions and Deployments is to limit requests to users who are members of the team that owns the build, promotion, package or deployment definition. Since these are all based on Rational Team Concert build definitions, this restriction is put in place by adding a Restrict the Users Requesting A Build precondition to the Request Build operations. This precondition requires that the requester be a member of the team that owns the build definition being used.
Let’s go through an example. The JKE Banking project has two development feature teams, Business Recovery Matters and Energy Efficiency Matters. The project also has a Release Engineering team focused on build, promotion and deployment into the various test and production environments.
The project has the following stream structure in place that mirrors the development, test and production environments.
Correspondingly, dependency builds are defined for each environment. Those supporting the development environment are owned by the Business Recovery Matters development team. Those representing the project’s test and production environments are owned by the Release Engineering team.
Promotion, packaging and deployment through the Test, QA and Production environments will be owned by the Release Engineering team. Thus, all the definitions for these operations will be owned by that team.
Finally, the previously described Restrict the Users Requesting A Build precondition is placed on the Request Build operation so that the build through deployment lifecycle operations can only be performed by members of the appropriate team.
Based on this team structure, build ownership and preconditions, the following scenario is performed.
- Deb, a developer, makes a change to the source code and delivers that change to the Mortgage Development Stream.
- Deb requests the isdz.mortgage.dev.team dependency build. Since she is a member of the Business Recovery Matters team that owns that build, the build proceeds. Had Deb not been a member of the team, the following error would have occurred.
- The release engineer, Rebecca, promotes Deb’s change to the Test environment by requesting a work item promotion of isdz.promote.mortgage.devtotest.rdt. Since Rebecca is a member of the Release Engineering team that owns the promotion, and also has the Promote Work Items permission, the promotion proceeds. Had Rebecca not been a member of the team, she would have received the same error in the Team Advisor as Deb received in the step above. Without Promote Work Items permission, the following errors would have occurred.
- Rebecca packages the changes that have been promoted by requesting the isdz.package.mortgage.test.rdt.r2 package. She is able to perform this action because she is a member of the Release Engineering team that owns the package, and because she has Request Package permissions. Otherwise, she would see errors similar to those we have seen above.
- Upon completion of the package, Rebecca deploys it by requesting the isdz.deploy.mortgage.test.rdt.r2 deployment. Again, she is successful because she is a member of the Release Engineering team that owns the deployment, and she has Request Deployment permissions.
Rational Build Agent security on z/OS
In order to leverage dependency build or JCL build capabilities provided by Rational Team Concert, you will need to install and configure a Rational Build Agent on the z/OS system where the builds will be performed. It is important to consider the authority under which these builds will run on z/OS, both for team builds and for personal builds requested by individual developers. You have several options for securing your builds, as defined in the Information Center under Security considerations for the Rational Build Agent. This article will explore in detail the most common approach.There are two to three TSO user IDs involved with Rational Build Agent builds. They are:
- The TSO user that launches the Rational Build Agent on z/OS
- The TSO user that is configured in the Build Engine in Rational Team Concert
- Potentially a different TSO user specified at build request time using Build Agent Authentication Override
For example, here the superuser RYEHLE starts the build agent:
The Build Engine is configured with non-superuser BUILDER (though a superuser could be used):
A command line build that simply runs the whoami Unix command for validation of the configuration will print BUILDER to the build log, indicating that the build is running under the authority of the BUILDER ID.
The same command line build could be requested using Build Agent Authentication Override:
In this case, whoami will print USER11 to the build log.
Keep in mind that the user ID the build runs under must have authority to:
- Write to the build agent temporary directory (/tmp by default)
- In the case of a command line build:
- Set the working directory to the location specified
- Execute the specified command
- In the case of a dependency build:
- Write to the data set high level qualifier (HLQ) specified in the build definition
- Write to the load directory (USS) specified in the build definition
- Write to the USS folder SCM_WORK/SCM configured in startbfa.sh
You may want to force each of your developers to perform a Build Agent Authentication Override, so that their personal builds are always running under the authority of their own individual TSO user IDs. This can be done by specifying a dummy ID in the Build Engine, causing the build request to fail if no override is specified. One drawback to this approach is that scheduled builds are not possible because they would always fail. An alternative approach is to configure the Build Engine with a TSO user that can write to the load directory and HLQ specified in the build definition but can not write to the individual developers’ load directories and HLQs. Personal builds would fail unless they were requested using Build Agent Authentication Override. If you decide to take this approach, you will want to consider coding a precondition that confirms the user has specified a load directory and HLQ different from what is specified in the build definition for all personal build requests (or that he has used Build Agent Authentication Override), as today there is nothing preventing the user from reusing these values. This could in particular cause issues for other developers who are relying on the team build data sets to be in sync with the contents of the stream.
Additional configuration is required to perform overrides when using a command line build to submit JCL, as discussed in the Information Center in the Prerequisites and security considerations topic.
For more information
- Guide for migration to Rational Team Concert for z/OS application development
- Security considerations for the Rational Build Agent
- zOS Build Agent Security (Development Wiki)
About the authors
Robin Yehle Bobbitt was the build and promotion component lead for the Rational Team Concert Enterprise Extensions development team. She is currently the development lead for the Rational Adapter for Git. Robin can be contacted at ryehle@us.ibm.com.
Tim Feeney is a CLM solution architect and member of the Unleash the Labs (ULL) team. The ULL teams work with key customers worldwide to architect lifecycle solutions across the breadth of the Rational portfolio and industry solution domains. He can be contacted at tfeeney@us.ibm.com.
Copyright © 2013 IBM Corporation