Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Dell PowerScale SyncIQ: Architecture, Configuration, and Considerations
Executive summary Introduction to SyncIQ Deployment topologies Use cases Architecture and processes Data replication Configuring a SyncIQ policy Impacts of modifying SyncIQ policies SyncIQ performance rules SnapshotIQ and SyncIQ SyncIQ design considerations Failover and failback Superna Eyeglass DR Edition SyncIQ and CloudPools SyncIQ security
Introduction to SyncIQ security
SyncIQ encryption
SyncIQ pre-shared key
SyncIQ bandwidth reservations Monitoring, alerting, reporting, and optimizing performance Administration SyncIQ replication and data reduction 16 TiB large file support and SyncIQ implications OneFS version compatibility SmartLock compatibility Conclusion Appendix A: Failover and failback steps Appendix B: SyncIQ encryption with self-signed certificates Appendix C: Configuring cascaded replication Appendix D: Configuring custom replication Appendix E: Technical support and resources

SyncIQ encryption

Home > Storage > PowerScale (Isilon) > Product Documentation > Data Protection > Dell PowerScale SyncIQ: Architecture, Configuration, and Considerations > SyncIQ encryption

SyncIQ encryption

  • OneFS release 8.2 introduced over-the-wire, end-to-end encryption for SyncIQ data replication, protecting and securing in-flight data between clusters. A global setting is available, enforcing encryption on all incoming and outgoing SyncIQ policies.

    Note: Before you enable SyncIQ encryption on a production cluster, test it in a lab environment that mimics the production environment. Encryption adds minimal overhead to the transmission, but it may affect a production workflow depending on the network bandwidth, cluster resources, workflow, and policy configuration. Only after you successfully test encryption in a lab environment and collect satisfactory measurements, you may consider implementing SyncIQ encryption for the production cluster.

    A figure illustrating SyncIQ encryption.

    Figure 32.    SyncIQ encryption

    SyncIQ provides encryption through X.509 certificates paired with TLS version 1.2 and OpenSSL version 1.0.2o. The certificates are stored and managed in the source and target cluster’s certificate stores, as shown in Figure 32. Encryption between clusters is enforced by each cluster, storing its certificate and its peer's certificate. Therefore, the source cluster is required to store the target cluster’s certificate, and conversely. Storing the peer’s certificate essentially creates a list of approved clusters for data replication. SyncIQ encryption also supports certificate revocation through the use of an external OCSP responder.

    Note: Before you enable SyncIQ encryption, you must upgrade and commit both the source and target cluster to OneFS release 8.2 or newer.

    Configuring SyncIQ encryption

    OneFS release 9.1 introduced support for SyncIQ configuration through the WebUI. For releases before OneFS 9.1, SyncIQ encryption configuration is available through the CLI only. To configure SyncIQ encryption between a source and target cluster, perform the following steps:

    1. Using publicly available tools, create X.509 certificates for the source and target cluster. This process results in a Certificate Authority certificate, source certificate, source private key, target certificate, and target private key.

    Certain certificate authorities do not generate the public and private key pairs. In that case, the public and private key pairs must be manually generated with a Certificate Signing Request (CSR), requiring a manually generated CSR. To manually generate the CSR file, as an example, run the following command:

    openssl req -new -newkey rsa:2048 -keyout <src_key> -out <src_csr>

    Next, provide the CSR file for each cluster to the certificate authority, and signed certificates are returned.

    Note: The certificates should be configured for use in TLS connections with client authentication enabled. They must be signed by a certificate authority and be able to act as both a client and a server certificate. Certificate extensions are not required and are not recommended because they result in additional restrictions and may cause SyncIQ policies to fail.

    The procedure explained in this step with the certificate authority is the recommended process. Alternatively, for environments where a Certificate Authority is not available, a self-signed certificate can be used for SyncIQ encryption. To configure SyncIQ encryption with a self-signed certificate, see Appendix B: SyncIQ encryption with self-signed certificates.

    1. Use the following commands to add the certificates created in step 1 to the source cluster certificate store:

    isi sync cert server import <src_cert_id> <src_key>

    isi sync cert peer import <tgt_cert_id> --name=[Specify a certificate name]

    isi cert authority import <ca_cert_id> –-name=[Specify the authority name]

    Alternatively, activate each certificate through the WebUI. Only selecting the certificate is supported through the WebUI. The certificates must first be transferred to the cluster. When the certificates are transferred to the cluster, activate each certificate as follows:

    • Add the source cluster certificate under Data Protection > SyncIQ > Certificates. Click Add certificate, specify the certificate file location, and provide an alias.
    • Add the target server certificate under Data Protection > SyncIQ > Settings. Find the Server Certificates section and click Add certificate. Specify the certificate file location and provide an alias.
    • Add the Certificate Authority, under Access > TLS Certificates, under the Authority tab, and select Import authority. Specify the certificate file location and provide an alias.

    Note: Activating the Certificate Authority is only supported in OneFS Release 9.5 and later. Use the isi cert authority import command in the CLI for previous releases.

    1. This step can be skipped if encryption is configured through the WebUI. On the source cluster, activate the SyncIQ cluster certificate from step 1 using the following command:

    isi sync settings modify --cluster-certificate-id=<src_cert_id>

    1. Use the following commands to add the certificates created in step 1 to the target cluster certificate store:

    isi sync cert server import <tgt_cert_id> <tgt_key>

    isi sync cert peer import <src_cert_id> --name=[Specify a certificate name]

    isi cert authority import <ca_cert_id> –-name=[Specify the authority name]

    Alternatively, activate each certificate through the WebUI. Only selecting the certificate is supported through the WebUI. The certificates must first be transferred to the cluster. When the certificates are transferred to the cluster, activate each certificate as follows:

    Note: Activating the Certificate Authority is only supported in OneFS 9.5 and later. Use the isi cert authority import command in the CLI for previous releases.

    1. This step can be skipped if encryption is configured through the WebUI. On the target cluster, activate the SyncIQ cluster certificate from step 1 using the following command:

    isi sync settings modify --cluster-certificate-id=<tgt_cert_id>

    1. Optionally, select the global option to require all incoming and outgoing SyncIQ policies to be encrypted.

    Note: Running this command affects existing SyncIQ policies that may not have encryption enabled. Only run this command after all existing policies have encryption enabled. Otherwise, existing policies that do not have encryption enabled will fail.

    To enable this option, run the following command:

    isi sync settings modify --encryption-required=True

    1. To modify an existing SyncIQ policy for encryption, go to the next step. Otherwise, to create a new encrypted SyncIQ policy, on the source cluster, use the following command:

    isi sync policies create <SyncIQ Policy Name> sync <Source Cluster Directory> <Target Cluster IP Address> <Target Cluster Directory> --target-certificate-id=<tgt_cert_id>

    Alternatively, from the WebUI, go to Data Protection > SyncIQ > Policies, and click Create a SyncIQ policy. Specify the policy name, action, and job run trigger, as illustrated in the following figure.

    A figure illustrating SyncIQ's WebUI.

    Figure 33.                   Creating a SyncIQ policy

    1. To modify an existing SyncIQ policy for encryption, on the source cluster, use the following command:

    isi sync policies modify <pol_name> --target-certificate-id=<tgt_cert_id>

    Alternatively, from the WebUI, go to Data Protection > SyncIQ > Policies, select an existing SyncIQ policy, and click View/Edit on the right. From the Target certificate drop-down, select the appropriate target cluster certificate.

    Other optional commands

    SyncIQ provides an option to require a policy to use a specified SSL cipher suite. To update a policy and enforce a specific SSL suite, use the following command:

    isi sync policies modify <pol_name> --encryption-cipher-list=<suite>

    You can update a target cluster to check the revocation status of incoming certificates using the following command:

    isi sync settings modify --ocsp-address=<FQDN of OCSP server> --ocsp-issuer-certificate-id=<ca_cert_id>

    By default, the encrypted connection is renegotiated on a cluster every eight hours. You can update this value using the following command:

    isi sync settings modify --renegotiation-period=<Specify time period in hours>

    Troubleshooting

    As with other SyncIQ policies, errors are documented in the SyncIQ reports. The same applies to SyncIQ encryption because the reason for failure is listed in the report. For instance, if the job failed due to a TLS authentication failure, the error message from the TLS library is provided in the report.

    Also, for a TLS authentication failure, a detailed log is available in the /var/log/messages directory on the source and target clusters. The log includes the error code and reason for failure, the depth at which the failure occurred in the certificate chain, the certificate ID, and the subject name of the certificate that caused the failure.