Security - Overview
As mentioned in Chapter 1, zCX is a new capability that is shipped for the first time with z/OS 2.4. The zCX instance that runs on z/OS runs in a Linux operating system. Inside the zCX instance, Docker containers run. Those containers run products and applications.
In turn, this new paradigm naturally raises the question,
How do we manage security for zCX on z/OS?
This chapter discusses the various aspects of security for zCX on z/OS, including these topics:
3.1 zCX instance security
In this section, we discuss security issues regarding a zCX instance. The next chapter discusses security within the zCX instance.
A key concept to grasp is that zCX instances run as standard started tasks, which are normal address spaces on a z/OS LPAR.
Associated with a zCX instance are the typical artifacts, which are associated with any started task that runs on z/OS. You must manage these artifacts as you would manage any other process on z/OS.
For a zCX instance, you must consider the following issues:
•RACF user IDs and groups that you must administer and manage
•zFS data sets
•USS directories and files
•zFS files and VSAM linear data sets
•TCPIP
•z/OSMF
3.1.1 Implications of zCX running as a started task
As mentioned, zCX instances run as standard started tasks on z/OS.
This means that all the normal rules that apply to a started task on z/OS apply to zCX that runs as a started task.
z/OS uses mechanisms to ensure that no process running in an address space can access any other part of z/OS outside that address space unless authorized to do so.
Access into and out of the zCX started task is done via TCPIP or virtual disk I/O.
Virtualization engine
When started, the zCX instance allocates real memory and runs the Linux operating system as a virtual machine inside this memory. Because of this, the z/OS architecture prevents any program running inside this virtual machine from being able to access any memory outside of the memory that is allocated.
3.1.2 zCX RACF planning
There are three main issues that relate to the management of zCX instances:
•Using z/OSMF to provision zCX instances
•Running zCX instances as started tasks
•User IDs to administer the running of Docker containers inside a zCX instance
Associated with the first two issues are the use of the following entities:
•zFS data sets
•VSAM data sets
•USS directories and files
3.1.3 RACF groups and user IDs for zCX
When you plan your RACF setup, it is always recommended that you define a user ID under which a started task runs on z/OS. That way, you can prevent this user ID from being used to log on to any z/OS application. This practice is a basic concept for RACF groups and user IDs for zCX instances.
The suggested approach is to create two RACF groups for the following purposes:
•A group to manage user IDs that would be used in z/OSMF to run workflows to manage the provisioning of zCX instances.
•A group to manage user IDs that would be used to run zCX instance started tasks.
Additionally user IDs are used inside zCX instances to administer Docker containers. There are two options that can be used for these user IDs:
1. During the zCX provisioning process, specify an initial administration user ID that will be defined in the zCX instance. You can then log on to the zCX instance with this user ID and define additional user IDs, if they are required. OR
2. Define the zCX instance to use an LDAP server as an external user repository, and log on to the zCX instance with an LDAP user ID.
If you use the first approach, you also must define a group to manage user IDs that are administration user IDs that can be used to log in to zCX instances.
We show example of creating such groups in 4.2.4, “Create RACF groups” on page 50.
Typically, you have multiple logical environments that run zCX instances, such as development, test, pre-production, and production.
You would set up the previously mentioned set of groups for each logical environment in which you plan to run zCX instances.
Within each group, you would then create at least one RACF user ID.
How many additional user IDs that you create depends on the size of your organization. For example, if you plan to have a number of people logging on to z/OSMF to run zCX workflows, you must define additional user IDs for these people.
You might decide to run all zCX instances in a logical environment under the same RACF user ID. Alternatively, you might define multiple user IDs so that different zCX instances run under these different user IDs.
In 4.2.5, “Create RACF user IDs” on page 50, we show example RACF commands that define the user IDs to manage the zCX instances that we set up in our environment.
3.1.4 zFS files and VSAM linear data sets
You provision zCX instances by running workflows in z/OSMF. During the running of the workflow, a single zFS file and five VSAM linear data sets are created.
 
Note: You must ensure that the user ID that you use in z/OSMF has the appropriate security to create this zFS file and VSAM linear data sets. Also, you must associate RACF data set rules with these data sets to protect them.
You should keep the UACC set to NONE while you create RACF rules for these data sets. Then, permit READ access to the group that is used to run the zCX workflows in z/OSMF and the group that contains the user IDs under which you run the zCX started tasks.
See the following topic in the z/OS 2.4 Knowledge Center to learn about issues regarding user IDs:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_setupvsamzfsreqs.htm
This topic covers the following issues:
•User IDs in z/OSMF that run the zCX workflows require ALTER access to the VSAM data sets so that they can be allocated.
•User IDs for running the zCX started task must have CONTROL access to the VSAM data sets.
SMS Considerations
One of the VSAM linear data sets that is created is approximately 20 GB in size. This means that you also must plan your SMS setup to have a DATACLASS that has Extended Format and Extended Addressability.
Pervasive Encryption
See the following topic in the z/OS 2.4 Knowledge Center to learn z/OS pervasive encryption:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_setupsecurity.htm
This topic covers the following issues:
•By default, zCX instance root file systems and swap data volumes that are backed by VSAM linear data sets are encrypted by Linux, based on LUKS encryption. Pervasive encryption is not recommended for these linear VSAM data sets.
•Pervasive encryption is recommended for configuration, user data, diagnostics data, VSAM linear data sets, and your zCX instance directory zFS file system. You can define an encryption key label by using one of the following methods:
 – The RACF data set profile DFP segment method OR
 – The DATA CLASS SMS construct method
3.1.5 USS directory and files
When you run the zCX workflows in z/OSMF, a new home directory is created for the zCX instance. This directory is created either in a default directory or in a directory that you specify. This choice of directory has the following implications:
•Before you run the zCX workflow, you must plan what USS directory to use. This directory serves as the parent directory in which the zCX instance directory is created.
•You must consider what RACF user ID and group to define as the owner and group for these directories.
Keep these factors in mind regarding user IDs:
•The user ID the runs workflows in z/OSMF must be able to create a new directory.
•The user ID that runs the zCX started task must be able to read files from this directory and write files to a sub-directory called FFDC.
In Section 4.3.1, “zCX directories” on page 52, we show how we set up our USS directory to support such a configuration.
Sysplex considerations
If you would like to be able to start the zCX instances that you define on any z/OS LPAR in the sysplex, you must ensure that the directory that you use to store the zCX instance configuration is shared across all LPARs in the sysplex.
In 4.3.1, “zCX directories” on page 52, we show how we used the default z/OS global directory that is located in the root directory as the location to achieve this goal.
3.1.6 TCPIP Networking
TCPIP is used to give access into and out of a zCX instance. The following link discusses the use of z/OS TCPIP and communication to zCX instances, including mentioning how z/OS IP filters can be used to restrict access to and from zCX:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_setupnetworking.htm
3.1.7 z/OSMF
You can provision zCX instances by using only the zCX workflows that are supplied in z/OSMF.
The workflow performs many tasks. One of these tasks is the mounting of a newly defined zFS to a new USS directory. This task requires proper configuration of the z/OSMF environment. See Section 4.4, “z/OSMF” on page 53 describes how we did this.
We recommend that you review z/OSMF set up by reading the various articles in the z/OS 2.4 Knowledge Center that describe the setup of z/OS, including this one:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua300/izuconfig_SecurityStructuresForZosmf.htm#DefaultSecuritySetupForZosmf__SecuritySetupRequirementsForCoreFun
3.1.8 Other data sets
As mentioned, the zCX instance uses 1 zFS file system and 5 VSAM linear data sets. There is no mechanism that allows any container — including the zCX Docker CLI SSH container in the zCX instance — to access any other data set, USS directory, or file that resides in z/OS.
3.2 Security within the zCX instance
In this section, we discuss security considerations within the zCX instance.
3.2.1 Linux in the zCX instance
When started, each zCX instance runs a provisioned Linux operating system. There is no direct access to this underlying Linux operating system.
3.2.2 The SSH container
To do the administration of the Docker containers that exist inside a zCX instance, you log in to the zCX instance with an administration user ID. When you do such a login, you are logging in to an SSH container in the zCX instance. Figure 3-1 shows the SSH container in a zCX instance.
Figure 3-1 SSH Container in a zCX instance
All such connections to this SSH container can be done over SSH only, which ensures that any data that flows over this connection is encrypted.
From this SSH container, you issue Docker commands to administer the Docker containers that you want to run in the zCX instance. This user ID for administering the zCX instance is not a UNIX root user ID.
3.2.3 zCX administration user IDs
To administer Docker containers in a zCX instance, you use administration user IDs. You can set up these user IDs in the zCX instance through either of these methods:
•Defined as local user IDs in the zCX instance
•Configuring the zCX instance to use an external LDAP server
This link from the z/OS 2.4 Knowledge Center describes these options in further detail:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_usermanagementchapterintro.htm
Section 4.2.6, “Create SSH Keys” on page 51, shows how we set up access to a local administrator user ID in the zCX instance.
Section 9.2, “Configuring zCX to use an LDAP server” on page 222 shows how we configure a zCX instance to use an LDAP server for the administration user IDs.
Adding additional local administration user IDs
If you use local administration user IDs in a zCX instance, you can define additional local administration user IDs, as shown in Section 9.1.1, “Adding Docker users” on page 220.
 
Note: When you use the local administration user ID approach, there are in effect two types of users:
•Users who can do Docker commands and user administration.
•User IDs that are created by the administration user IDs, who can do Docker commands but not user administration.
3.3 Docker in zCX versus Docker on distributed
This section discusses some differences between running Docker in zCX and on distributed systems.
3.3.1 Docker capabilities of the SSH container
There are some restrictions on which Docker commands can be issued in a zCX instance. These are documented in the following topic of the z/OS 2.4 Knowledge Center under the heading “Restrictions in the zCX Docker CLI SSH container”:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_whatissshd.htm
Two restrictions from the list are worth repeating here.
•Privileged Docker containers are considered insecure and not supported in zCX.
•Changing the namespace to host is not supported in zCX.
3.3.2 Considerations regarding the mounting of file systems
On a distributed system, you could mount any directory of the host system in Read Only or Read Write mode to a container. If the directory is mounted as Read Write, this configuration would allow a program in the container to directly update the file system of the hosting system.
In zCX instance, when you log on, you log in to the SSH container. You might try to mount a directory when you issue the docker run command with the -v or --mount option. However, you will never get an error message to indicate that there was an issue with the mount. The actual result depends on the directory that you specified.
 
Note: You cannot mount any directory that exists in the SSH container to a new Docker container that you are starting.
If the directory that you specify exists in the underlying Linux operating system, that directory is mounted in Read Only mode in the new container.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.113.197