10.1. Cluster synchronization

10.1.1. Introduction

The node-sync resource handles the synchronization of multiple SFTPPlus instance that operate as part of a single SFTPPlus file transfer cluster.

The same node-sync resource is use to setup a cluster controller or one or more cluster nodes.

The communication between nodes and the remote controller is done via HTTPS and thus protected using TLS. The node synchronization has the standard configuration options of a TLS-based SFTPPlus component.

Once synchronized, a local node operates as an independent SFTPPlus file transfer service. Even if the remote controller is offline, a local node continues to work using the last known configuration. As soon as the controller is available again, local nodes update their configurations to be up to date with the controller's configuration.

When you stop or start a component on the main controller, a corresponding start or stop action on the synchronized nodes is automatically triggered. You can enable or disable a component on the main controller to trigger a corresponding start or stop action on the nodes.

The configuration for the node synchronization resource itself is independent of the changes made on the controller node.

Warning

In the current version, only the configuration changes stored in the main configuration file are synchronized. Certificates or SSH keys stored as external files are not synchronized. Encrypted SSH or TLS keys are not synchronized. The content of the local-file authentication method configuration file is not synchronized.

10.1.2. role_in_cluster

Default value:

node

Optional:

Yes

Values:
  • controller

  • node

From version:

5.13.0

Description:

Defines how this SFTPPlus instance will interact with other SFTPPlus instance as part of the cluster.

When configured as controller, this SFTPPlus instance will allow remote SFTPPlus cluster nodes to pull their configuration and receive events and status from the remote cluster nodes.

When configured as node, this SFTPPlus instance will pull its configuration from the cluster controller. You will need to configure the URL to the controller and the credentials for this node. Direct configuration is disabled.

10.1.3. sync_interval

Default value:

60

Optional:

No

Values:
  • Number of seconds greater than 0

From version:

5.11.0

Description:

The interval in seconds between consecutive pulls of the configuration changes from the controller.

It should be greater than 0. We don't recommend setting it to values lower than 60 seconds for production usage. Lower values can be used to help with testing.

This is ignored when configured together with role_in_cluster = node.

10.1.4. sync_events

Default value:

Empty

Optional:

yes

Values:
  • Event ID

  • Event group

  • Comma-separated list of event IDs

  • Comma-separated list of event groups

  • Comma-separated list of event IDs and event groups

  • all

From version:

5.13.0

Description:

The nodes will always send to the controller authentication and security related events.

This defined which additional events are sent from the cluster nodes to the cluster controller.

When configured with an empty value, no extra events are sent.

When you want to send all the events excepting some few events, you should prefix each event id or group name with the exclamation mark (!).

When using cloud based or distributed Security information and event management (SIEM) systems you can leave this as empty value. The SIEM will take care of aggregating and managing the logs in a centralized way.

10.1.5. url

Default value:

''

Optional:

Yes

Values:
  • URL

From version:

5.11.0

Description:

The URL of the remote controller from which this local node synchronizes its configuration, receives management commands, and reports status to.

This is ignored when configured together with role_in_cluster = controller.

10.1.6. username

Default value:

None

Optional:

No

Values:
  • Text.

From version:

5.11.0

Description:

The node of the node as configured on the controller.

This is ignored when configured together with role_in_cluster = controller.

10.1.7. password

Default value:

None

Optional:

No

Values:
  • Plain text.

From version:

5.11.0

Description:

This is the password used by this node to authenticate to the controller.

This is ignored when configured together with role_in_cluster = controller.

10.1.8. ssl_certificate_authority

Default value:

set-on-first-connection

Optional:

Yes

Values:
  • PEM content of a CA chain (Since 3.40.0)

  • PEM content of a pinned public key (Since 5.1.0)

  • Absolute path to a local file

  • set-on-first-connection (Since 5.0.0)

  • pin-public-key (Since 5.1.0)

  • ${MOZILLA_CA_ROOTS} (Since 5.0.0)

  • ${GOOGLE_CA_ROOTS} (Since 5.11.0)

  • ${DIGICERT_CA_ROOTS} (Since 5.12.0)

  • ${LETS_ENCRYPT_X3_CA}

  • ${MICROSOFT_IT_CA}

  • ${GO_DADDY_G2_G1}

  • disable-identity-security (Since 5.0.0)

From version:

1.6.0

Description:

This is used to validate the identity of the remote server.

Remote server identity can only be validated when the remote address or URL is configured using a fully-qualified domain name. IP-based validation would always fail as this is not a method accepted by Certificate Authorities (CAs).

Configured certificates need to be in PEM format.

Multiple Certificate Authorities can be configured, one after the other. They can be multiple root CAs or intermediate CAs.

Warning

When disable-identity-security is set, the identity of the remote server is not validated. All remote servers are accepted without validating their TLS/SSL certificates. Communication is encrypted and data is protected in transit. This can result in an encrypted connection to an unknown server.

When set-on-first-connection is used, the Certificate Authority of the remote server is configured automatically. The set-on-first-connection configuration value is automatically replaced by the actual CA chain of the remove server on the very first connection. For all subsequent connections, the server identity is validated against the automatically configured CA chain.

When pin-public-key is set, SFTPPlus accepts server certificates that have the same public key as the one discovered during the first connection to this server. This is used to implement certificate and public key pinning. SFTPPlus only pins the public key. This can be used for self-signed server certificates.

You can configure the client to validate the server's identity based on a fixed list of public keys. In this way, you can implement public key pinning. When public key validation is used, the public key infrastructure (PKI) certificate policies are not enforced. For example, the server certificate is accepted even if it's expired or issued for a different hostname.

This can be defined as an absolute path on the local filesystem to a file containing the certificates of the Certificate Authorities used to validate the remote peer.

A series of bundle CAs are distributed with SFTPPlus. They can be configured together and mixed with other CA certificates. The bundle CAs are available under the following names:

  • ${MOZILLA_CA_ROOTS} - All the root certification authorities accepted by the Mozilla's CA Certificate Program

  • ${GOOGLE_CA_ROOTS} - All the root certification authorities handled by Google Trust Services

  • ${LETS_ENCRYPT_X3_CA} - For Let's Encrypt X3 certificate authority.

  • ${MICROSOFT_IT_CA} - For all Microsoft IT CA certificates.

  • ${DIGICERT_CA_ROOTS} - For all Digicert CA certificates. used by SharePoint Online and other services provided by Microsoft.

  • ${GO_DADDY_G2_G1} - For all GoDaddy Certificate Bundles, G2 With Cross to G1.

Only servers using certificates signed by one of the configured Certificate Authorities are allowed to communicate with this client.

Leave it empty to disable checking the identity of the remote server.