Internode TLS

• 1: Control channel Spread TLS
• 2: Data channel TLS

=> SELECT SECURITY_CONFIG_CHECK('NETWORK');

1 - Control channel Spread TLS

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

Internode TLS uses the following channels. Both must be enabled in the following order before you set other parameters:

1. Control Channel, implemented with Spread, which allows nodes to exchange plan information and distribute calls. For details, see spread.org.

2. Data Channel, implemented with TCP, which allows nodes to exchange table data.

Enable EncryptSpreadComm

EncryptSpreadComm controls Spread encryption and can be set to 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.

You can verify the current value of EncryptSpreadComm with SECURITY_CONFIG_CHECK:

=> SELECT SECURITY_CONFIG_CHECK('NETWORK');

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

To create a new database with EncryptSpreadComm set:

$ admintools -t create_db -d my_db -s 192.0.2.100, 192.0.2.101, 192.0.2.10 \
    -c '/catalog/path' --config-param EncryptSpreadComm='aws-kms|abcde123-ab12-1234-abcd-abcde1234567' 

To set EncryptSpreadComm on an existing database:

1. Set 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');
   -------------------------------------------
    Spread security details:
   * EncryptSpreadComm = [vertica]
   Spread encryption is enabled
   It is now safe to set/change other security knobs
   

Privileges

Superuser

Restrictions

If you set this parameter on an existing database with ALTER DATABASE, you must restart the database for it to take effect.

See also

• Internode TLS
• Data channel TLS
• TLS overview

2 - Data channel TLS

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

• Internode TLS
• Control channel Spread TLS
• TLS overview