Enabling Security

important

Security is enabled by default.

Security can be enabled/disabled by adding the disable-security-controls option to the configuration.

If this property is not supplied, or set to false, then security will be enabled. If set to true, then security will be disabled.

When security is enabled this has the same effect as adding:

• file-protection-level=0027
• rmi-ssl=true
• thl-ssl=true
• rmi-authentication=true
• jgroups-ssl=true
• datasource-enable-ssl=true
• replicator-rest-api-ssl=true
• connector-ssl=true
• connector-rest-api-ssl=true
• manager-rest-api-ssl=true

important

If you are enabling to-the-database encryption, you must ensure this has been enabled in your database and the relevant certificates are available first. See "Enabling Database SSL" for steps.

important

Installing from a staging host will automatically generate certificates and configuration for a secured installation. No further changes or actions are required.

For INI-based installations, there are additional steps required to copy the needed certificate files to all of the nodes. Please see "Enabling Security using the INI Method" for details.

Enabling Security using the INI Method

Security will be enabled during initial install by default, should you choose to disable at install, then these steps will guide you in the process to enable as part of a post-install update

Enabled During Install

As mentioned, security is enabled by default. This is controlled by the disable-security-controls property. If not supplied, the default is false. You can choose to specify this in your configuration for transparency if you wish.

disable-security-controls=false

The above configuration (and the default) will assume that your database has been configured with SSL enabled. The installation will error and fail if this is not the case. You must manually ensure database SSL has been enabled prior to issuing the install. Steps to enable this can be found in "how-to-enable-database-ssl"

If you DO NOT want to enable database level SSL, then you must also include the following options in your /etc/tungsten/tungsten.ini file:

enable-connector-ssl=false
datasource-enable-ssl=false

Following installation there are a few additional steps that will be required before starting the software.

• You must select one of the nodes and copy that node's certificate/keystore/truststore files to all other nodes.

  Available as of Version 7.1.0, the tpm copy command can perform the file transfers for you. For example, run it from node db1 to copy to all the rest of the nodes in the cluster:

  shell> tpm copy
  About to copy all needed files for:
  >>> Security directory: /opt/continuent/share
  Please confirm that all nodes are done installing, and that none of the Tungsten processes have been started yet.
  Ready to proceed (y/N)? y

  For example, assuming you choose db1, and have 5 other nodes to copy the files to you could use this syntax:

  shell> for host in db2 db3 db4 db5 db6; do 
  scp /opt/continuent/share/[jpt]* ${host}:/opt/continuent/share/
  scp /opt/continuent/share/.[jpt]* ${host}:/opt/continuent/share/
  done

  Important

  The above example assumes ssh has been set up between nodes as the tungsten OS user. If this is not the case you will need to use whichever methods you have available to sync these files.

• Then, on all nodes, you can start the software:

  shell> source /opt/continuent/share/env.sh
  shell> startall

Enabling Post-Installation

If, at install time, you disabled security (by specifying disable-security-controls=true you can enable it by changing the value to false in your /etc/tungsten/tungsten.ini on all nodes, or by removing the property.

The above configuration (and the default) will assume that your database has been configured with SSL enabled. The update will error and fail if this is not the case. You must manually ensure database SSL has been enabled prior to issuing the update. Steps to enable this can be found in "how-to-enable-database-ssl"

If you DO NOT want to enable database level SSL, then you must also include the following options in your /etc/tungsten/tungsten.ini file:

enable-connector-ssl=false
datasource-enable-ssl=false

Before issuing the update, there are a number of additional steps required. These are outlined below:

• First, configure the /etc/tungsten/tungsten.ini file as follows:

  disable-security-controls=false
  start-and-report=false

• Enable MAINTENANCE mode on the cluster

  shell> cctrl
  cctrl> set policy maintenance

• Do the update on each node, which will generate new, different certificates on every node.

  Warning

  This update procedure will force all running Tungsten processes to be stopped. Connectors MUST be done at the same time or they will no longer be able to communicate with the Managers.

  shell> stopall
  shell> tpm query staging
  shell> cd {staging_directory}
  shell> tools/tpm update --replace-jgroups-certificate --replace-tls-certificate --replace-release

• As with a fresh install, you must then select one of the nodes and copy that node's certificate files to all other nodes:

  Available as of Version 7.1.0, the tpm copy command can perform the file transfers for you. For example, run it from node db1 to copy to all the rest of the nodes:

  shell> tpm copy
  About to copy all needed files for:
  >>> Security directory: /opt/continuent/share
  Please confirm that all nodes are done installing, and that none of the Tungsten processes have been started yet.
  Ready to proceed (y/N)? y

  For example, assuming you choose db1, and have 5 other nodes to copy the files to you could use this syntax:

  shell> for host in db2 db3 db4 db5 db6; do 
  scp /opt/continuent/share/[jpt]* ${host}:/opt/continuent/share/
  scp /opt/continuent/share/.[jpt]* ${host}:/opt/continuent/share/
  done

  Important

  The above example assumes ssh has been set up between nodes as the tungsten OS user. If this is not the case you will need to use whichever methods you have available to sync these files.

• On all nodes:

  shell> startall

Enabling Security using the Staging Method

Security will be enabled during initial install by default, should you choose to disable at install, then these steps will guide you in the process to enable as part of a post-install update

Enabled During Install

As mentioned, security is enabled by default. This is controlled by the disable-security-controls. If not supplied, the default is false. You can choose to specify this in your configuration for transparency if you wish.

shell> tools/tpm configure defaults --disable-security-controls=false \\
[...the rest of the configuration options...]
shell> tools/tpm install

The above configuration (and the default) will assume that your database has been configured with SSL enabled. The installation will error and fail if this is not the case. You must manually ensure database SSL has been enabled prior to issuing the install. Steps to enable this can be found in "how-to-enable-database-ssl"

If you DO NOT want to enable database level SSL, then you must also include the following option in the tpm configure command above:

--enable-connector-ssl=false
--datasource-enable-ssl=false

important

Installing from a staging host will automatically generate certificates and configuration for a secured installation. No further changes or actions are required.

Enabling Post-Installation

If, at install time, you disabled security (by specifying --disable-security-controls=true) you can enable it by changing the value to false, or removing the option.

shell> tools/tpm configure defaults --disable-security-controls=false
shell> tools/tpm update --replace-jgroups-certificate --replace-tls-certificate --replace-release

The above configuration will assume that your database has been configured with SSL enabled. The update will error and fail if this is not the case. You must manually ensure database SSL has been enabled prior to issuing the update. Steps to enable this can be found in "how-to-enable-database-ssl"

If you DO NOT want to enable database level SSL, then you must also include the following options in the tpm configure command above:

--enable-connector-ssl=false
--datasource-enable-ssl=false

Following the update, you will also need to manually re-sync the certificates and keystores to all other nodes within your configuration. The following example uses scp for the copy and uses db1 as the primary source for the files to be copied. Adjust accordingly for your environment.

1. Place the cluster into MAINTENANCE mode

   cctrl> set policy maintenance

2. Sync Certificates and Keystores to all nodes

   db1> for host in db2 db3 db4 db5 db6; do
   scp /opt/continuent/share/[jpt]* ${host}:/opt/continuent/share
   scp /opt/continuent/share/.[jpt]* ${host}:/opt/continuent/share
   done

3. Available as of Version 7.1.0, the tpm copy command can perform the file transfers for you. For example, run it from node db1 to copy to all the rest of the nodes in the cluster:

   shell> tpm copy
   About to copy all needed files for:
   >>> Security directory: /opt/continuent/share
   Please confirm that all nodes are done installing, and that none of the Tungsten processes have been started yet.
   Ready to proceed (y/N)? y

   Important

   The above example assumes ssh has been setup between nodes as the tungsten OS user. If this is not the case you will need to use whichever methods you have available to sync these files.

4. Restart all components, on all hosts

   shell> manager restart
   shell> replicator restart
   shell> connector restart

5. Place the cluster back to AUTOMATIC mode

   cctrl> set policy automatic

warning

This update will force all running processes to be restarted. Connectors MUST be done at the same time or they will no longer be able to communicate with the managers.