Dell PowerStore 1000T EMC PowerStore Security Configuration Guide - Page 14

• For replication, a certificate exchange between two PowerStore clusters to establish trusted management communication. To facilitate replication between PowerStore clusters, bi-directional trust must be established between the clusters to allow for mutual TLS authentication when issuing replication REST control requests. • For data import, a certificate and credentials exchange with persistence, to establish a secure connection between a Dell EMC storage system (a VNX, Unity, Storage Center (SC), or a Peer Storage (PS) system) and a PowerStore cluster. vSphere Storage API for Storage Awareness support vSphere Storage API for Storage Awareness (VASA) is a VMware-defined, vendor-neutral API for storage awareness. A VASA Provider comprises multiple components working in cooperation to service incoming VASA API requests. The VASA API gateway, which receives all incoming VASA APIs, is deployed on the primary appliance (the one that owns the floating management IP) in a PowerStore cluster. ESXi hosts and vCenter Server connect to the VASA Provider and obtain information about available storage topology, capabilities, and status. Subsequently, the vCenter Server provides this information to vSphere clients. VASA is used by VMware clients rather than PowerStore Manager clients. The vSphere user must configure the VASA Provider instance as the provider of VASA information for the cluster. In the event that the lead appliance goes down, the related process will restart on the appliance that becomes the next primary, along with the VASA Provider. The IP address fails over automatically. Internally, the protocol will see a fault when obtaining configuration change events from the newly active VASA Provider, but this will cause an automatic resynchronization of the VASA objects without user intervention. The PowerStore provides VASA 3.0 interfaces for vSphere 6.5 and 6.7. VASA 3.0 supports Virtual Volumes (VVols). VASA 3.0 supports interfaces to query storage abstractions such as VVols and Storage Containers. This information helps storage policy based management (SPBM) make decisions about virtual drive placement and compliance. VASA 3.0 also supports interfaces to provision and manage the lifecycle of VVols used to back up virtual drives. These interfaces are directly invoked by ESXi hosts. For more information related to VASA, vSphere, and VVols, refer to the VMware documentation and the PowerStore Manager online help. Authentication related to VASA To initiate a connection from vCenter to the PowerStore Manager VASA Provider, use the vSphere client to enter the following information: • URL of the VASA Provider, using the following format for VASA 3.0: https://:8443/version.xml. • Username of a PowerStore Manager user (the role must be either VM Administrator or administrator). NOTE: The VM Administrator role is strictly used as a means to register certificates. • Password associated with this user. The PowerStore Manager credentials used here are only used during this initial step of the connection. If the PowerStore Manager credentials are valid for the target cluster, the certificate of the vCenter Server is automatically registered with the cluster. This certificate is used to authenticate all subsequent requests from the vCenter. No manual steps are required to install or upload this certificate to the VASA Provider. If the certificate has expired, the vCenter must register a new certificate to support a new session. If the certificate is revoked by the user, the session is invalidated and the connection is severed. vCenter session, secure connection and credentials A vCenter session begins when a vSphere administrator uses the vSphere Client to supply the vCenter Server with the VASA Provider URL and login credentials. The vCenter Server uses the URL, credentials, and the SSL certificate of the VASA Provider to establish a secure connection with the VASA Provider. A vCenter session ends when one of the following events occurs: • An administrator uses the vSphere Client to remove the VASA Provider from the vCenter configuration and the vCenter Server terminates the connection. • The vCenter Server fails or a vCenter Server service fails, terminating the connection. If vCenter or the vCenter Server service cannot reestablish the SSL connection, it will start a new one. • The VASA Provider fails, terminating the connection. When the VASA Provider starts up, it can respond to communication from the vCenter Server to reestablish the SSL connection and VASA session. A vCenter session is based on secure HTTPS communication between a vCenter Server and a VASA Provider. In VASA 3.0, the vCenter Server acts as the VMware certificate authority (VMCA). The VASA Provider transmits a self‐signed certificate on request, after authorizing the request. It adds the VMCA certificate to its truststore, then issues a certificate signing request, and replaces its self‐ signed certificate with the VMCA signed certificate. Future connections will be authenticated by the VASA Provider using the client 14 Authentication and access