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