The steps below apply to the following configurations: - Ignite Cluster Provider, using an Ignite Cache Provider
- TIBCO FTL Cluster Provider, using an Ignite Cache Provider
NOTE: When using TIBCO FTL as the Cluster Provider, you should also configure SSL options at the FTL level as well. Guidance for that is provided in Knowledge article "How to configure a secure FTL cluster for BE applications". You must create identities (i.e. digital certificates) to identify the BE agents that will need join the cluster. First, create the identity for the primary Ignite cache node. This node will act as the Ignite server in the cluster, to which additional cache/inference agents will later connect (acting as clients to the primary cache node). You can create the identity using the Java keytool command: keytool -genkey -keystore primary.node.keystore.p12 -keyalg RSA -validity 365 -storepass password -keypass password -alias PrimaryNode -dname "CN=Primary Node" -storetype pkcs12
Then, from the generated 'primary.node.keystore.p12', export the public certificate for this identity: keytool -export -alias PrimaryNode -keystore primary.node.keystore.p12 -file PrimaryNode.cer -storepass password
Add the 'PrimaryNode.cer' certificate to your BE project under a folder named (for example) 'trusted'. This certificate will be used by secondary BE nodes (i.e. additional cache/inference agents), as they will need to trust the primary Ignite cache node (i.e. the server) when making the secure SSL connection to the cluster.
Next, create the identity for any secondary BE nodes: keytool -genkey -keystore secondary.node.keystore.p12 -keyalg RSA -validity 365 -storepass password -keypass password -alias SecondaryNode -dname "CN=Secondary Node" -storetype pkcs12
Then, from the generated 'secondary.node.keystore.p12', export the public certificate for this identity: keytool -export -alias SecondaryNode -keystore secondary.node.keystore.p12 -file SecondaryNode.cer -storepass password
Add the 'SecondaryNode.cer' certificate to your BE project under the same 'trusted' folder, as noted above. This certificate will be used by the primary BE cache node (i.e. the server) as it will need to trust any secondary BE nodes when they attempt to join the cluster.
Next, create Identity Resources to reference the identities you've created for the primary and secondary nodes:
Next, select the 'Security Enabled' option in your CDD. If your Cluster Provider is Ignite, the security options can be found in the CDD Editor under Cluster > Cluster Management. If your Cluster Provider is FTL and your Cache Provider is Ignite, then the security options can be found in the CDD Editor under Cluster > Object Management. Set the additional security options as follows for the primary cache node:
For any secondary nodes, change the 'Identity' value in the CDD (shown above) to '/SharedResources/SecondaryNode.id'. A Global Variable may be used to substitute the Identity value as needed when deploying in a production environment.
Next, build the project EAR file and start the primary Cache node. Look for the following highlighted line in the BE console log: 2021 Nov 19 12:59:21:821 GMT -05 host.domain INFO [main] - [ignite.cluster] Ignite Cluster Discovery URL: 127.0.0.1:47500..47510 2021 Nov 19 12:59:21:821 GMT -05 host.domain INFO [main] - [ignite] Setting Ignite member name: host.domain Initializing JSSE's crypto provider class com.sun.net.ssl.internal.ssl.Provider in default mode 2021 Nov 19 12:59:21:993 GMT -05 host.domain INFO [main] - [ignite] Starting Ignite node as 'Server'
This indicates that security is enabled. You may also check the *-ignite.log (i.e. the cache log) for the 'Security status' line: 2021 Nov 19 12:59:22:641 GMT -05 host.domain INFO [main] - [org.apache.ignite] Security status [authentication=off, sandbox=off, tls/ssl=on]
Once you confirm that the Ignite cluster has initialized with SSL/TLS enabled, you may then start additional secondary nodes (again, by specifying the SecondaryNode.id in your CDD, as noted above).
You have now secured your Ignite cluster by forcing 2-way SSL connections between the primary cache node and additional secondary nodes.