Securing the runtime system

Set up security on the runtime system and on the observed systems. Because an observed system can also be a runtime system, you might have to perform both definitions on these systems. On the runtime system the steps to take are:

• Define the started task
• Define ARM access
• Define access for the Provisioning Manager user
• Define the System Observation user
• Define the secured sign-on function
• Define access for the Capacity Provisioning Management Console user
• Define access to the hardware

The following examples assume that your external security manager is z/OS® Security Server (RACF®). If you have installed a different external security manager, modify the examples accordingly. These examples also assume that the Provisioning Manager user and the CPMC user are already defined to the security manager, and that an OMVS segment is defined for both users.

All RACF security definitions that are required for a runtime system that is also an observed system are contained in member CPOSEC1 in SYS1.SAMPLIB. You can copy and change this sample job to match your needs. All security definitions required for additional observed systems that are not sharing the same security database are listed in sample member CPOSEC2.

The RACF security definitions listed in this document and contained in the members CPOSEC1 and CPOSEC2 assume a prior CIM setup. Detailed information about CIM setup can be found in z/OS Common Information Model User’s Guide.

The samples CPOSEC1 and CPOSEC2 are adapted for the CIM security setup job CFZSEC.

Defining the started task

The Provisioning Manager started task on the runtime system must be assigned to the Provisioning Manager user. Here is an example definition for RACF:

RDEFINE STARTED CPOSERV.* STDATA(USER(CPOSRV))
SETROPTS RACLIST(STARTED) REFRESH

Defining ARM access

If Automatic Restart Manager (ARM) is used, a FACILITY class profile must be defined and the Provisioning Manager user must have an UPDATE access. If you change the default ARM element type, ARM element name or Provisioning Manager user you must replace the values SYSCPM, SYSCPO, or CPOSRV in the following example with the values you chose. An example definition is:

RDEFINE FACILITY IXCARM.SYSCPM.SYSCPO UACC(NONE)
PERMIT IXCARM.SYSCPM.SYSCPO CLASS(FACILITY) ID(CPOSRV) ACC(UPDATE)
SETROPTS RACLIST(FACILITY) REFRESH

Defining security for the Provisioning Manager user

The Provisioning Manager user requires access to local resources on your runtime system. The local resources include:

• Membership in the Provisioning Manager security groups CPOQUERY and CPOCTRL
• UPDATE access to the Provisioning Manager data sets CPO.DOMAIN1.*
• READ access to the profile BPX.CONSOLE in the FACILITY class
• CONTROL access to the Provisioning Manager user data sets CPOSRV.*
• If the FACILITY class does not exist, you can create it using the
  RDEF FACILITY BPX.CONSOLE UACC(NONE) command

You can define these access rights as follows:

ADDGROUP CPOQUERY OMVS(GID(...))
ADDGROUP CPOCTRL OMVS(GID(...))

CONNECT (CPOSRV) GROUP(CPOQUERY) AUTH(USE)
CONNECT (CPOSRV) GROUP(CPOCTRL) AUTH(USE)

ADDSD ('CPO.DOMAIN1.*') GENERIC UACC(NONE)
PERMIT 'CPO.DOMAIN1.*'  GENERIC ID(CPOSRV) ACCESS(UPDATE)
ADDSD ('CPOSRV.**')     GENERIC UACC(NONE)
PERMIT 'CPOSRV.**'      GENERIC ID(CPOSRV) ACCESS(CONTROL)
SETROPTS GENERIC(DATASET) REFRESH

Optionally, grant the Provisioning Manager access to BPX.CONSOLE in the FACILITY class.

If this access is not granted, all messages issued by the Provisioning Manager are prefixed with a BPXM023I message.

RDEFINE FACILITY BPX.CONSOLE UACC(NONE)

PERMIT 'BPX.CONSOLE' CLASS(FACILITY) ID(CPOSRV) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH

Note that you need to complete the OMVS information for the Provisioning Manager security groups before entering these definitions.

In addition, the Provisioning Manager user needs access to files and directories in the local file system of the runtime system. These access rights are usually sufficient by default. The following access is needed for the Provisioning Manager user:

• Read and execute access to the Capacity Provisioning installation directory /usr/lpp/cpo and all its subdirectories
• Read and execute access to the Java™ installation directory /usr/lpp/java and all its subdirectories
• Read access to the CIM Client for Java /usr/lpp/wbem/jclient/sblim-cim-client2.jar
• Read access to the SAF library /usr/include/java_classes/IRRRacf.jar
• Read and write access to trace and log data in file system path /tmp
• Read and write access to file system path /var
• Read and write access to the home directory of the Provisioning Manager user /u/cposrv

If the current access rights are insufficient, set the "other" read, write, and execute access permissions of the directories and files accordingly by using the UNIX command chmod, for example:

chmod -R o+rx /usr/lpp/cpo

These permissions allow all users to read and execute files and directories starting with /usr/lpp/cpo.

Defining the System Observation user

The Provisioning Manager uses a configured userid to logon to the observed systems. The default for this userid is CPOCIM and has to be configured in the PARM member of the parameter dataset prefix.PARM through key SystemObservation.UserName. This user requires an OMVS segment and unique non-zero uid. For example:

 ADDUSER  (CPOCIM)
  ALTUSER  (CPOCIM) +
           NORESTRICTED +
           DFLTGRP(........) +
           OMVS(HOME('/u/cpocim') UID(......) ) +
           PASSWORD(......)

See also Defining access to the CIM server.

Defining the secured sign-on function on the runtime system

Communication between the runtime system and the observed systems requires authentication and authorization. These processes are implemented by using the secured sign-on function, which generates PassTickets when the Provisioning Manager logs on to an observed system. For the logon to the observed system a separate System Observation userid (default CPOCIM) is defined on the runtime system and all observed systems.

The following definitions are needed to use the secured sign-on function for this userid and for the Provisioning Manager to be able to generate PassTickets:

To activate the PTKTDATA class

Use the definitions:

SETROPTS CLASSACT(PTKTDATA)
SETROPTS RACLIST(PTKTDATA)

To use PassTickets

If it is not already implemented as part of the CIM server setup, define the profile CFZAPPL in the PTKTDATA class. The Provisioning Manager user must have at least READ access to this profile. If a common cryptographic architecture (CCA) product is installed on the systems with the secured sign-on function you can encrypt the secured sign-on application keys. If not, mask the secured sign-on application key by using the SSIGNON operand and a 64-bit KEYMASKED value. For example:

RDEFINE PTKTDATA CFZAPPL SSIGNON(KEYMASKED(XXXXXXXXXXXXXXXX))+
       APPLDATA('NO REPLAY PROTECTION')
PERMIT CFZAPPL CLASS(PTKTDATA) ID(CPOCIM) ACCESS(READ)
SETROPTS RACLIST(PTKTDATA) REFRESH

To generate PassTickets

To enable the Provisioning Manager user to generate PassTickets for the System Observation userid, create the security profile IRRPTAUTH.CFZAPPL.CPOCIM in the PTKTDATA class giving the Provisioning Manager user at least UPDATE access authority. For example:

RDEFINE PTKTDATA IRRPTAUTH.CFZAPPL.CPOCIM
PERMIT IRRPTAUTH.CFZAPPL.CPOCIM CLASS(PTKTDATA) ID(CPOSRV) ACCESS(UPDATE)
SETROPTS RACLIST(PTKTDATA) REFRESH

For more information about configuring RACF to use PassTicket services, see z/OS Security Server RACF Security Administrators Guide.

Defining security for hardware access

If you are using BCPii communication, the Common Event Adapter (CEA) must run in full function mode and the Provisioning Manager user must be authorized for to some Common Event Adapter (CEA) services and for the CPCs that need to be managed. Instructions for setting the CEA into full function mode are provided in z/OS Planning for Installation.

For the CEA services, the Provisioning Manager user needs READ authority to the following profiles in the SERVAUTH class:

• CEA.CONNECT
• CEA.SUBSCRIBE.ENF_0068*

A sample definition would look like the following:

SETROPTS CLASSACT(SERVAUTH)
RDEFINE SERVAUTH CEA.CONNECT UACC(NONE)
RDEFINE SERVAUTH CEA.SUBSCRIBE.ENF_0068* UACC(NONE)
PERMIT CEA.CONNECT CLASS(SERVAUTH) ID(CPOSRV) ACCESS(READ)
PERMIT CEA.SUBSCRIBE.ENF_0068*  CLASS(SERVAUTH) ID(CPOSRV) ACCESS(READ)
SETROPTS RACLIST(SERVAUTH)  REFRESH  

The Provisioning Manager user needs the following authorizations to access information about the hardware, perform activation and deactivation requests for temporary capacity, and changing the defined capacity on a CPC:

• READ access to profile HWI.APPLNAME.HWISERV in the FACILITY class.
• CONTROL access to profile HWI.TARGET.netid.name in the FACILITY class. The net ID and name represent the SNA (System Network Architecture) name of the CPC as defined at the SE. The APPLDATA of the security definition must contain the uppercase community name for the Provisioning Manager as defined in Table 14. The profiles must cover all CPCs to be managed by Capacity Provisioning and all CPCs on which the Provisioning Manager can run.
• Optionally, if you plan to manage physical (On/Off CoD) capacity, READ access to profile HWI.CAPREC.netid.nau.* in the FACILITY class. The net ID and name represent the SNA name of the CPC as defined at the support element. The profiles must cover all capacity records.
• Optionally, if you plan to manage defined capacity, UPDATE access to the profile HWI.TARGET.netid.name.imagename in the FACILITY class. The net ID and name represent the SNA name of the CPC as defined at the support element. The imagename is the name of the LPAR that can be managed. The profiles must cover all LPARs that should be managed.

For example, if you have a CPC with SNA Name IBMNET.CPC1, and you plan to manage physical capacity and defined capacity for all LPARs, the definitions would look as follows:

RDEFINE FACILITY HWI.APPLNAME.HWISERV UACC(NONE)
RDEFINE FACILITY HWI.TARGET.IBMNET.CPC1 APPLDATA(...) UACC(NONE)
RDEFINE FACILITY HWI.CAPREC.IBMNET.CPC1.* UACC(NONE)
RDEFINE FACILITY HWI.TARGET.IBMNET.CPC1.* UACC(NONE)

PERMIT HWI.APPLNAME.HWISERV CLASS(FACILITY) ID(CPOSRV) ACCESS(READ)
PERMIT HWI.TARGET.IBMNET.CPC1 CLASS(FACILITY) ID(CPOSRV) ACCESS(CONTROL)
PERMIT HWI.CAPREC.IBMNET.CPC1.* CLASS(FACILITY) ID(CPOSRV) ACCESS(READ)
PERMIT HWI.TARGET.IBMNET.CPC1.* CLASS(FACILITY) ID(CPOSRV) ACCESS(UPDATE)

SETROPTS RACLIST(FACILITY)  REFRESH 

For more information about BCPii setup, see z/OS MVS Programming: Callable Services for High-Level Languages.

Defining security for the Capacity Provisioning Management Console user

The CPMC user must be authorized to connect the CPMC to the Provisioning Manager. Define this user on the runtime system with an OMVS segment, and add the user to the appropriate Provisioning Manager security group, depending on which administration and operation commands the user is allowed.

Define the CPMC users with a non-zero z/OS UNIX identifier (UID). When using a UID of zero, the "enableRemotePrivileged UserAccess" configuration property must be enabled in the CIM server. All CPMC users need to have execute permission to the /var directory. You can grant all users execute permission via the command chmod o+x /var.

At this time, the CIM server must be set up as described in z/OS Common Information Model User’s Guide.

The following examples assume a default CPMC user of ZMFUSR. This ID has to be replaced with the distinct userid(s) of your environment.

The CPMC user must have UPDATE access to the CIMSERV profile in the WBEM class. If your system is set up to use z/OS UNIX level security, for example, if BPX.SERVER is defined, define the CIM server user as a surrogate of the CPMC user. To accomplish this, profile BPX.SRV.ZMFUSR in the SURROGAT class is required if a generic BPX.SRV.** is not defined. The current CIM recommendation for switching identity (SURROGAT) is explained in the CIM User's Guide during the CIM setup. The CIM server user requires access to this profile. The next step depends on the authorization to be given to the CPMC user.

If the CPMC user is only authorized to query information from the Provisioning Manager, add this user to the Provisioning Manager query security group CPOQUERY, and grant UPDATE access to the CIMSERV profile by connecting it to the CIM users ID default group CFZUSRGP, which was defined during the CIM setup. In the following example we assume tat the CPMC user has the user id ZMFUSR:

CONNECT (ZMFUSR) GROUP(CPOQUERY) AUTH(USE)

CONNECT (ZMFUSR) GROUP(CFZUSRGP) AUTH(USE)

If instead the CPMC user is authorized to change the processing characteristics of the Provisioning Manager, add this user to both Provisioning Manager security groups, CPOQUERY and CPOCTRL, and grant UPDATE access to the CIMSERV profile by connecting it to the CIM users ID default group CFZUSRGP, which has been defined during the CIM setup:

CONNECT (ZMFUSR) GROUP(CPOQUERY) AUTH(USE)
CONNECT (ZMFUSR) GROUP(CPOCTRL) AUTH(USE)

CONNECT (ZMFUSR) GROUP(CFZUSRGP) AUTH(USE)