This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Internode TLS

Internode TLS secures communication between nodes within a cluster.

Internode TLS secures communication between nodes within a cluster. It is important to secure communications between nodes if you do not trust the network between the nodes.

Before setting up internode TLS, check the current status of your configuration with SECURITY_CONFIG_CHECK.

=> SELECT SECURITY_CONFIG_CHECK('NETWORK');

Communication between the server nodes uses two channels: the control channel and data channel. To enable internode encryption, set the EncryptSpreadComm parameter (disabled by default) to encrypt Spread communication on the control channel and configure the data_channel TLS Configuration to encrypt the data channel:

  1. Encrypt Spread communication on the control channel with EncryptSpreadComm. See Control channel spread TLS for details.

  2. Encrypt the data channel with the data_channel TLS Configuration. See Data channel TLS for details.

If you enable internode encryption, some of your queries might run slower than expected. Performance depends on the data sent and network quality.

Admintools generates or retrieves the spread key to encrypt all traffic on the control channel and ships the spread key to all nodes. Vertica uses TLS to encrypt all traffic on the data channel. TLS credentials are shared between nodes over the encrypted control channel.

The following graphic illustrates the internode encryption process.

See also

1 - Control channel spread TLS

The control channel allows nodes to exchange plan information with one another, and to distribute calls among nodes.

The control channel allows nodes to exchange plan information with one another, and to distribute calls among nodes. Enabling spread security secures this communication. See Internode TLS for more information.

Internode TLS uses the following channels. Both must be enabled, and in the following order, before setting other parameters:

  1. Control Channel to exchange plan information and distribute calls. It is implemented using Spread. For more information, visit spread.org.

  2. Data Channel to exchange table data. It is implemented using TCP.

Enabling EncryptSpreadComm

EncryptSpreadComm can be set with one of two values:

  • vertica. Vertica generates the spread encryption key for the cluster when the database starts up.

  • aws-kms|<key_name>. Vertica fetches the user-specified key from the AWS Key Management Service when the database starts up, rather than generating one itself.

In general, you should set the EncryptSpreadComm parameter to enable spread encryption before setting any other security parameters.

  1. Set the EncryptSpreadComm parameter with ALTER DATABASE.

    => ALTER DATABASE DEFAULT SET PARAMETER EncryptSpreadComm = 'vertica';
    
  2. Restart the database.

  3. Verify your settings with SECURITY_CONFIG_CHECK.

    => SELECT SECURITY_CONFIG_CHECK('NETWORK');
    

Privileges

Superuser

Restrictions

After setting this parameter, you must restart your database.

Example

This enables the EncryptSpreadComm parameter and tells Vertica to generate a spread encryption key the next time the database starts up.

=> ALTER DATABASE DEFAULT SET PARAMETER EncryptSpreadComm = 'vertica';

For more information on this and other security parameters, see Security parameters.

See also

2 - Data channel TLS

Nodes use the data channel to exchange table data during operations such as queries.

Nodes use the data channel to exchange table data during operations such as queries.

Internode communication uses the following channels. Their associated components and parameters must be enabled in the following order:

  1. Control Channel to exchange plan information and distribute calls. It is implemented using Spread. For more information, visit spread.org.

  2. Data Channel to exchange table data. It is implemented using TCP.

Configuring data channel TLS

This procedure configures TLS between Vertica nodes and uses the predefined TLS Configuration data_channel. To use a custom TLS Configuration, see TLS configurations.

  1. Enable TLS on the control channel.

  2. Generate or import a CA (Certificate Authority) certificate. For example, to create a self-signed CA certificate, generate a key and sign CA certificate with the key:

    => CREATE KEY SSCA_key TYPE 'RSA' LENGTH 2048;
    
          
    => CREATE CA CERTIFICATE SSCA_cert
    SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=OpenText/OU=Vertica/CN=Vertica Root CA'
    VALID FOR 3650
    EXTENSIONS 'nsComment' = 'Self-signed root CA cert'
    KEY SSCA_key;
    
    

  3. Generate or import a private key. For example, to generate the private key:

    => CREATE KEY internode_key TYPE 'RSA' LENGTH 2048;
    

  4. Generate or import a TLS certificate. The certificate must have a full chain that ends in a CA, and must be either a x509v1 certificate or use the extendedKeyUsage extensions serverAuth and clientAuth. For example, to generate internode_cert and sign it with SSCA_cert:

    => CREATE CERTIFICATE internode_cert
    SUBJECT '/C=US/ST=Massachusetts/L=Cambridge/O=Micro Focus/OU=Vertica/CN=data channel'
    SIGNED BY SSCA_cert
    EXTENSIONS 'nsComment' = 'Vertica internode cert', 'extendedKeyUsage' = 'serverAuth, clientAuth'
    KEY internode_key;
    

  5. Set the certificate, and optionally the TLSMODE for data_channel TLS configuration. If the TLSMODE is set to TRY_VERIFY or higher, the certificate's signing CA is added to the TLS Configuration's list of CA certificates:

    => ALTER TLS CONFIGURATION data_channel CERTIFICATE internode_cert TLSMODE 'TRY_VERIFY'
    

    If you do not specify a TLSMODE, and the TLSMODE was previously set to DISABLE (default), TRY_VERIFY, VERIFY_CA, or VERIFY_FULL (which behaves like VERIFY_CA), the TLSMODE automatically changes to VERIFY_CA:

    => ALTER TLS CONFIGURATION data_channel CERTIFICATE internode_cert;
    

    If the certificate is not signed by a known CA, the TLSMODE is set to DISABLE.

  6. Verify that the InternodeTLSConfig parameter uses the TLS Configuration:

    => SHOW CURRENT InternodeTLSConfig;
      level  |        name        |   setting
    ---------+--------------------+--------------
     DEFAULT | InternodeTLSConfig | data_channel
    (1 row)
    
  7. Verify that data channel encryption is enabled with SECURITY_CONFIG_CHECK('NETWORK'):

    => SELECT SECURITY_CONFIG_CHECK('NETWORK');
       SECURITY_CONFIG_CHECK
    ---------------------------
     Spread security details:
    * EncryptSpreadComm = [vertica]
    Spread encryption is enabled
    It is now safe to set/change other security knobs
    
    Data Channel security details:
     TLS Configuration 'data_channel' TLSMODE is VERIFY_CA
    TLS on the data channel is enabled
    

Privileges

Superuser

Restrictions

  • In general, you should set EncryptSpreadComm before configuring data channel TLS.

  • Changes to the InternodeTLSConfig parameter and its underlying TLS Configuration take effect immediately and interrupt all ongoing queries in order to update node connections.

See also