Search <book_title>...

Storage Foundation Cluster File System High Availability 7.2 Administrator's Guide - Solaris

Last Published: 2018-03-06

Product(s): InfoScale & Storage Foundation (7.2)

Platform: Solaris

How secure communication works between the CP servers and the SFCFSHA clusters using the Veritas Product Authentication Services (AT)

Veritas Product Authentication Services (AT): Entities on behalf of which authentication is done are referred to as principals. On the SFCFSHA cluster nodes, the current VCS installer creates the authentication server credentials on each node in the cluster. It also creates vcsauthserver which authenticates the credentials. The installer then proceeds to start VCS in secure mode. Typically, in an existing VCS cluster with security configured, vcsauthserver runs on each cluster node.

CP server and SFCFSHA cluster (application cluster) node communication involve the following entities:

vxcpserv for the CP server
cpsadm for the SFCFSHA cluster node

Figure: End-To-end communication flow with security enabled on CP server and SFCFSHA clusters displays a schematic of the end-to-end communication flow with security enabled on CP server and SFCFSHA clusters (application clusters).

Figure: End-To-end communication flow with security enabled on CP server and SFCFSHA clusters

Communication flow between CP server and SFCFSHA cluster nodes with security configured on them is as follows:

Initial setup:
Identities of CP server and SFCFSHA cluster nodes are configured on respective nodes by the VCS installer.
Note:
At the time of fencing configuration, the installer establishes trust between the CP server and the application cluster so that vxcpserv process can authenticate requests from the application cluster nodes. If you manually configured I/O fencing, then you must set up trust between the CP server and the application cluster.
The cpsadm command gets the user name, domain type from the environment variables CPS_USERNAME, CPS_DOMAINTYPE. Export these variables before you run the cpsadm command manually. The customized fencing framework exports these environment variables internally before you run the cpsadm commands.
The CP server process (vxcpserv) uses its own user (CPSERVER) which is added to the local vcsauthserver.
Getting credentials from authentication broker:
The cpsadm command tries to get the existing credentials that are present on the local node. The installer generates these credentials during fencing configuration.
The vxcpserv process tries to get the existing credentials that are present on the local node. The installer generates these credentials when it enables security.
Communication between CP server and SFCFSHA cluster nodes:
After the CP server establishes its credential and is up, it becomes ready to receive data from the clients. After the cpsadm command obtains its credentials and authenticates CP server credentials, cpsadm connects to the CP server. Data is passed over to the CP server.
Validation:
On receiving data from a particular SFCFSHA cluster node, vxcpserv validates its credentials. If validation fails, then the connection request data is rejected.