Security of Code Pipeline
This section describes how Code Pipeline can be secured. Code Pipeline uses standard SAF facilities to secure the functions in Code Pipeline. Functions in Code Pipeline are secured by the use of Objects and Methods. Security Rules can be defined at the Object/Method level to secure these functions. It is possible to install Code Pipeline with no security at first, and then add rules to define security checking later.
How does it work?
Input cards to the Code Pipeline CM started task determine how Code Pipeline is to make SAF checks and for which Objects/Methods these checks are to be made. Code Pipeline will dynamically build the SAF Resource Name to check based upon the rules specified to Code Pipeline. Security profiles/rules need to be defined to the local security product in line with the Security Rules specified to Code Pipeline. Security-Objects-and-Methods contains the complete list of Objects/Methods and the attributes that can be used in the security checking.
Code Pipeline Security
“Statement of Integrity”
Code Pipeline’s use of APF authorized code is only for the functionality of Code Pipeline, as described in the product documentation. Code Pipeline has been rigorously tested for security exposures, and any security exposures that come to light in the future will be given BMC's highest priority.
Preparing for Security
Defining a SAF Class for Code Pipeline
Code Pipeline makes security checks to SAF which require a Class Name (Generic). It is recommended that a separate SAF Class be defined specifically for Code Pipeline because the Code Pipeline CM started task issues (RACROUTE REQUEST=LIST) against the class at start-up to pre-load all of the profiles. Keeping the Code Pipeline profiles separate provides the maximum level of optimization under SAF.
SAF Class Attributes
An example of a dynamic RACF CDT class definition is shown in the following figure.
Dynamic RACF CDT Class Definition
DEFAULTUACC(ACEE) FIRST(ALPHA NATIONAL NUMERIC) GENLIST(DISALLOWED) +
KEYQUALIFIERS(0) MACPROCESSING(NORMAL) MAXLENX(80) MAXLENGTH(80) +
OPERATIONS(NO) OTHER(ALPHA NATIONAL NUMERIC SPECIAL) POSIT(25) +
PROFILESALLOWED(YES) RACLIST(DISALLOWED) SIGNAL(NO) +
SECLABELSREQUIRED(NO))
This can be refreshed using the RACF command:
Defining Security
Server Definition
Input cards are placed in the dataset allocated to the REFRDATA DDName specified for the CM started task. Input cards for security are required for:
- Specification of the SAF Class which Code Pipeline checks for authorities
- Specification of an optional prefix used when building the resource string
- Specification of the Security Rules to define how Code Pipeline functions are to be secured.
Define RACF Class
The format of the input card for the definition of the SAF Class is:
SECCLASS=xxxxxxxx
where xxxxxxxx is the name of the Class.
If a class is specified which does not exist—or no class is specified at all—Code Pipeline will write a message in the log to indicate that it could not load the profiles and internal Code Pipeline security is unavailable.
Define Resource Name Prefix
The format of the input card for the definition of the Resource Name Prefix is:
SECPREFIX=xxxxxxxx
where xxxxxxxx is the text of the prefix. This card is optional and should rarely need to be specified if the Code Pipeline Server variable is used in the definition of the Security Rules.
Define Delimiter for Resource Name Variables
The Code Pipeline parameter SECDELIM is used to specify the delimiter for variables in the name. The default is that no delimiter is required, causing recognized variable names to be substituted. For example, a resource name in the Security Rules of SERVER.RL.APPL.METHOD will have SERVER, APPL, and METHOD substituted with the runtime values. This can make it difficult to discern what was a literal and what would be substituted, occasionally leading to unexpected results. So using the parameter SECDELIM=$ makes the variables in the resource name more obvious, as you would use $SERVER.RL.$APPL.$METHOD.
Define Security Rules
Input cards can be defined for each Code Pipeline Object and Method using the following format:
This is described further in the following table.
Define Security Rules
Parameter | Description |
|---|---|
Object | A Code Pipeline defined Object (for example, RELEASE). The wildcard symbol “*” can be used to specify all Objects, but only if “*” has also been used for the Method. See Security-Objects-and-Methods for a complete list of Objects. |
Method | A Code Pipeline defined Method that is valid for a specific Object. (For example, the Method ADD is valid for Object RELEASE.) The wildcard symbol “*” can be used to specify all Methods. The wildcard value for the Method can be specified for both a specific Object and for an Object of “*”. See Security-Objects-and-Methods for a complete list of Methods. |
ResourceName | The value here determines what resource string Code Pipeline builds to pass to the security product for the authorization check. For each Object there are a specified number of variables which can be used in the definition of this string (for example, SERVER, APPL, LEVEL, etc.). These variables are resolved at security check time to build the actual Resource Name to check against. See Security-Objects-and-Methods for a complete list of available variables. |
Access | The SAF authority to be checked for. (For example, does the user have READ authority on the Resource Name.) See Security-Objects-and-Methods for a complete list of available Access levels. |
Default Security
Code Pipeline comes pre-defined with internal rules to determine which security checks are to be made. This default security is described in Security-Objects-and-Methods against each Object and Method. The user-defined Security Rules override these defaults.
Previewing Security Rules
There is a Code Pipeline-supplied program which takes as input the defined Security Rules and produces a report detailing all the Code Pipeline Objects and Methods with the Resource Name string Code Pipeline will check against and the authority required. This is a useful report to validate the rules with the definitions in the security product. The JCL for running this report is shown in the following figure. This JCL can be found in the Code Pipeline SAMPLIB dataset member WZZACDMP.
Previewing Security Rules
//*
//*-------------------------------------------------------------------
//* EXECUTE THE ROUTINE WZZACDMP TO DUMP OUT SECURITY RULES
//*-------------------------------------------------------------------
//RUN EXEC PGM=WZZRCJOB,PARM='PROD/WZZACDMP WZACISPW'
//STEPLIB DD DISP=SHR,DSN=ISPW.CONFIG.AUTHLOAD
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SDEFISPW DD DISP=SHR,DSN=YOUR.ISPW.PARMLIB(SDEFREFR)
Report Layout
See Security-Objects-and-Methods for examples of this report.
The report has three sections:
- Heading
- Input Cards
- Altered Rules.
Heading
Input Cards
The input cards that were input into the program are re-printed.
Altered Rules
The security rules are printed out in the format shown in the following section.
Altered Rules
The security rules for the Objects and Methods are printed out in the format listed in the following table.
AlteredRules
Column | Field | Description |
|---|---|---|
1 | Modify Indicator | This indicates whether the input cards have altered the default rules defined in Code Pipeline. An “M” identifies it as modified. |
3 | Object | The Code Pipeline Object. |
12 | Method | The Code Pipeline Method for the Object. |
21 | Access | The access level that is required for the Object/Method combination. |
30 | Resource String | The SAF Resource String which is checked against to see if the user has the required access. |