User ID requirements

Edit online

Before using IBM® z/OS® Container Platform (zOSCP), you need to check the user ID requirements.

user icon z/OS security administrator

PODMAN group

The following group is created manually through the z/OSMF workflow that is described in Configuring the container runtime using a z/OSMF workflow. The z/OSMF workflow points to a sample job that is called BCZSECS1 located in SYS1.SBCZSMPL that can be modified and run.

  • PODMAN is a group that has access to the SAF resource CONTAINERS in the UNIXPRIV class. This new resource gives a non-UID 0 user access to run containers on z/OS, with a tool such as Podman for IBM z/OS (Podman). Connect users to this group to give them access. Each user of Podman should be connected to the PODMAN group to get the access required by Podman regardless of UID level.

K8SADMIN group

The following group is created manually through the z/OSMF workflow that is described in Provisioning IBM z/OS Control Plane Appliance instances. The z/OSMF workflow points to a sample job that is called BCZSECS2 located in SYS1.SBCZSMPL that can be modified and run.

  • K8SADMIN is a SAF group name representing Kubernetes administrators. This SAF group name is used by other programs that are meant for use by Kubernetes administrators.

ZCPA user ID

Creating a user ID for the IBM z/OS Control Plane Appliance (zCPA) started task is optional if there is already a default user ID defined to SAF that gets assigned to started tasks. The default user ID is associated with the name '*' in the STARTED SAF class, if defined.

If needed, a ZCPA user ID can be created. Assuming the zCPA is started with jobname ZCPAx (where x is any valid jobname character), a 'ZCPA*' SAF resource in the STARTED class would be defined. The ZCPA user ID would need R/W access to the zFS and VSAM data sets created through the z/OSMF workflow that is described in Configuring the IBM z/OS Control Plane Appliance as a Kubernetes control plane node.

Create the started task USERID for the zCPA, assuming the group K8SADMIN was the group name specified in the z/OSMF workflow to provision the zCPA:
ADDUSER ZCPA OMVS(AUTOUID) + NAME('zOS Containers zCPA') + DFLTGRP(K8SADMIN) NOPASSWORD
Define the STARTED profiles for the zCPA started tasks:
RDEFINE STARTED ZCPA* UACC(NONE) STDATA(USER(ZCPA) PRIVILEGED(NO) + TRUSTED(NO) TRACE(YES))

ZCPASURG user ID

The ZCPASURG user ID is created manually through the z/OSMF workflow that is described in Configuring the IBM z/OS Control Plane Appliance as a Kubernetes control plane node. The z/OSMF workflow points to a sample job that is called BCZSECS2 located in SYS1.SBCZSMPL that can be modified and run.

The ZCPASURG user ID owns the SAF key ring containing the certificate for the public and private key pair. This private key is used by the Kubeadm for IBM z/OS (kubeadmz) and IBM z/OS Appliance Manager for Kubernetes (kam) command-line utilities when authenticating with the zCPA.

CRIO, and KUBELET user IDs

These user IDs are required to use IBM z/OS Container Platform (zOSCP). A step in the Running the z/OSMF workflow to perform the prerequisite steps required to join a z/OS system to a cluster as a worker node z/OSMF workflow, creates the CRIO and KUBELET user IDs. For more information, see Running the z/OSMF workflow to perform the prerequisite steps required to join a z/OS system to a cluster as a worker node. The z/OSMF workflow points to a sample job that can be modified and run. For the user IDs CRIO, and KUBELET the sample job BCZSECS3 located in SYS1.SBCZSMPL can be used.

CRIO
The user ID to be assigned as the owning user for the CRIO cataloged procedure. This user ID:
  • Is defined as uid(0).
  • Has READ access to BPX.FILEATTR.SHARELIB to lay out images with files that have this extended attribute.
  • Has READ access to BPX.FILEATTR.APF to lay out images with files that have this extended attribute.
  • Has READ access to BPX.FILEATTR.PROGCTL to lay out images with files that have this extended attribute.
  • Has READ access to BPX.SRV.<userid> in the SURROGAT class, where <userid> specifies the user ID intended to run a container image through a Kubernetes deployment. For information on granting this access, see Authorizing the CRIO user ID for surrogate access.
KUBELET
The user ID to be assigned as the owning user for the KUBELET cataloged procedure. This user ID:
  • Is defined as uid(0).

IMGADMIN user ID

A Middleware system programmer or z/OS system programmer will retrieve the IBM provided images by using Podman. The user ID is required to allow certain extended attributes to be set for z/OS UNIX files. The extended attributes that are used for zOSCP are APF authorization, PGMCNTL (Program Control), and SHRLIB.

imgadmin
The user ID to be assigned as the owning user for images with APF authorized or program controlled files. This user ID:
  • Has READ access to BPX.FILEATTR.APF: 
    PERMIT BPX.FILEATTR.APF CL(FACILITY) ACC(READ) ID(imgadmin)
  • Has READ access to BPX.FILEATTR.PROGCTL: 
    PERMIT BPX.FILEATTR.PROGCTL CL(FACILITY) ACC(READ) ID(imgadmin)
  • Has READ access to BPX.FILEATTR.SHARELIB: 
    PERMIT BPX.FILEATTR.SHARELIB CL(FACILITY) ACC(READ) ID(imgadmin)
  • optional Has READ access to BPX.SUPERUSER: 
    PERMIT BPX.SUPERUSER CL(FACILITY) ACC(READ) ID(imgadmin)

    The user may switch to UID=0, requiring BPX.SUPERUSER access, before running the Podman command to pull an image to share with unprivileged users.

The imgadmin ID can pull images into /var/lib/podman/storage for other users of Podman.

Default user ID for containers on z/OS

It is recommended that a default user ID called OCIUSER is created, which can be used to run containers requiring minimal privileges. The OCIUSER user ID is created during the zoscp_worker_node workflow, for more information see Running the z/OSMF workflow to perform the prerequisite steps required to join a z/OS system to a cluster as a worker node. This user ID is used in the documentation examples, and in the Kubernetes security admissions controller, to restrict the user IDs under which containers can be run.

The default (OCIUSER) user ID needs read access to SURROGAT BPX.SRV.OCIUSER for the CRIO ID to allow containers to run under the OCIUSER ID. For more information, see Authorizing the CRIO user ID for surrogate access.

It is possible to choose a different user ID as the default (providing that user has the equivalent required SURROGAT access setup as mentioned earlier) by running the following command as a Kubernetes administrator: 
kubectl set env daemonset zoscp-zos-security-admission-controller -n zoscp-zos-security-admission-controller DEFAULT-PERMITTED-USERID=<USERID>
Note: A change in the default user ID for containers has implications for any running workload and a decision to perform such a change should be carefully managed. For example, you might do this when the cluster is instantiated and before any workload is assigned.