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. 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

• 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