Start of change

Using the z/OS NFS server as persistent storage for zCX

Containerized applications running inside zCX might require persistent storage to store and share stateful application data. Network File System (NFS) is one of the persistent storage options that is available for zCX. Docker provides the capability to use NFS as persistent volumes for containerized applications using built-in Docker NFS volume driver support. Docker NFS volumes allow containerized applications to access NFS-exported persistent storage data using the NFS protocol over the TCP/IP network in zCX.

By leveraging the z/OS NFS server to persist data, containerized applications deployed in zCX can take advantage of the z/OS security controls and operational benefits to securely store, access, backup and restore application data. Additionally, clients can also extend z/OS qualities of service to the persisted data by integrating the management of data into existing z/OS operational procedures. In addition, using this method, existing z/OS data can also be exported and shared with containerized applications running inside zCX without duplicating the data.

Containerized applications deployed on zCX must leverage Application Transparent - Transport Layer Security (AT-TLS) support to securely persist and access data using the z/OS NFS server. z/OS NFS APAR OA62357 provides AT-TLS support for NFS client connections to the z/OS NFS server. With this support, the z/OS NFS server leverages the AT-TLS policy configurations provided by z/OS Communications Server to securely communicate with zCX instances. An AT-TLS policy must be configured on the z/OS NFS server host system for the zCX instance IP address (DVIPA) to securely authenticate using a certificate owned by a z/OS User ID, and access NFS-server exported data sets.

From the zCX instance side (the NFS client), TLS needs to be enabled on the connections to the z/OS NFS server. This can be accomplished by deploying HAProxy, an open-source proxy server, as containerized software on the same zCX instance to enable TLS on the connections to the z/OS NFS server.

This solution not only makes the authentication of multiple container user IDs to access NFS data simpler, but provides the additional benefit of an encrypted data connection between the zCX and the NFS server host.

For the containerized zCX to be able to securely access NFS resources on z/OS, the z/OS NFS server exploits the AT-TLS support provided by z/OS Communications Server. With the NFS server being AT-TLS aware, the AT-TLS policy on the NFS server host needs the zCX NFS client to present a client certificate owned by a z/OS user ID, which is then used to perform an implicit mvslogin action for each container user ID trying to access NFS data on that zCX client. HAProxy can be used to enable TLS on the zCX client side of the connection.

Figure 1. z/OS NFS server as persistent storage with zCX
In this illustration, two z/OS images each have two zCX instances, Docker/Linux, a zCX virtual layer, and z/OS TCP/IP. The zCX instances communicate with a z/OS NFS server over NFSv4 over TCP/IP.
End of change