TLS in Kubernetes

To enhance security, the VerticaDB operator supports TLS authentication for both the HTTPS service and Client-Server authentication. This ensures that the OpenText™ Analytics Database server can verify identities of its clients before communication, helping protect against unauthorized access by enforcing certificate verification for both HTTPS service and Client-Server authentication. The OpenText™ Analytics Database does not store TLS certificates in its catalog or on disk. Instead, it reads the certificates directly from Kubernetes or AWS secrets when needed. This enhances security by reducing the risk of unauthorized access to stored certificates. For more information about configuring TLS, see CREATE TLS CONFIGURATION.

Configure TLS

Prerequisites

Install VerticaDB operator 25.3.0-0 and higher.
Create a VerticaDB custom resource definition manifest.

Note

Setting up HTTPS and Client-Server TLS via VerticaDB operator using Kubernetes or AWS secrets is supported in OpenText™ Analytics Database version 25.3.0-0 or higher.
Setting up Internode TLS via VerticaDB operator using Kubernetes or AWS secrets is supported in OpenText™ Analytics Database version 26.1.0-0 or higher.
TLS cannot be disabled after it has been enabled.

Enable TLS

Use kubectl edit to edit the existing VerticaDB. Set httpsNMATLS.secret, httpsNMATLS.mode, clientServerTLS.secret, clientServerTLS.mode, interNodeTLS.secret, and interNodeTLS.mode.

The operator generates a TLS secret when:
- A TLS configuration is enabled, either by setting enabled to true or by setting another field such as mode.
- No secret is specified (httpsNMATLS.secret, clientServerTLS.secret, or interNodeTLS.secret). The generated secrets follow the naming patterns <vdb-name>-https-tls-<5-digits-random-string>, <vdb-name>-clientserver-tls-<5-digits-random-string>, or <vdb-name>-internode-tls-<5-digits-random-string>.
If a TLS configuration is not specified at all, the operator does not generate a secret for that configuration.

If httpsNMATLS.mode and clientServerTLS.mode are not specified, the default mode try_verify will be applied.

If interNodeTLS.mode is not specified, the default mode verify_ca will be applied.

If you want to use your own TLS certificates, you can optionally provide them using a Kubernetes secret of type kubernetes.io/tls or an AWS Secrets Manager secret.

Note
The automatically generated secret is not deleted when the VerticaDB resource is removed. This is required if you want to revive the database later. If you want the secret to be automatically deleted, then set the vertica.com/remove-tls-secret-on-vdb-delete annotation to true.
```
$ kubectl edit vdb cluster-name

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
    vertica.com/remove-tls-secret-on-vdb-delete: "false"
    ...
spec:
  ...
  clientServerTLS:
    mode:    TRY_VERIFY
    secret:  your-clientserver-tls-secret
    enabled: true
  httpsNMATLS:
    mode:    TRY_VERIFY
    secret:  your-https-tls-secret
    enabled: true
  interNodeTLS:
    mode:    VERIFY_CA
    secret:  your-internode-tls-secret
    enabled: true
```

Use kubectl describe to check the events generated by the operator while setting up TLS mode:


$ kubectl describe vdb cluster-name

...

Events:

  Type     Reason                                   Age                From                Message
  ----     ------                                   ----               ----                -------
  Normal  TLSConfigurationStarted     3m46s  verticadb-operator  Starting to configure TLS for httpsNMA
  Normal  TLSConfigurationSucceeded   3m44s  verticadb-operator  Successfully set HTTP tls config
  Normal  TLSConfigurationStarted     3m44s  verticadb-operator  Starting to configure TLS for clientServer
  Normal  TLSConfigurationSucceeded   3m42s  verticadb-operator  Successfully set Server tls config
  Normal  TLSConfigurationStarted     3m42s  verticadb-operator  Starting to configure TLS for interNode
  Normal  TLSConfigurationSucceeded   3m40s  verticadb-operator  Successfully set Internode tls config

Note

The following example assumes that no custom secret was provided and VerticaDB operator automatically generates Kubernetes secrets for Https NMATLS, Client Server TLS, and Internode TLS.

Use kubectl describe to check the secrets that are generated:


$ kubectl describe vdb cluster-name

...
Status:
  ...
  Tls Configs:
    Mode:          try_verify
    Name:          httpsNMA
    Secret:        vertica-db-https-tls-lhj82
    Mode:          try_verify
    Name:          clientServer
    Secret:        vertica-db-clientserver-tls-j86v9
    Mode:          verify_ca
    Name:          interNode
    Secret:        vertica-db-internode-tls-gbcx8

Verify that the auto generated secrets exist in Kubernetes secrets manager in the same namespace where the VerticaDB was created.
```
$ kubectl get secrets
NAME                                                                                  TYPE                             DATA   AGE
vertica-db-clientserver-tls-j86v9                                                     kubernetes.io/tls                3      5m7s
vertica-db-https-tls-lhj82                                                            kubernetes.io/tls                3      5m18s
vertica-db-internode-tls-gbcx8                                                        kubernetes.io/tls                3      5m7s
```
The Client Server TLS.mode and Https NMATLS.mode are set to TRY_VERIFY by default. You can set following values:
- ENABLE: Enables TLS without validating client certificates.
- TRY_VERIFY: Establishes a TLS connection if the other host
  - presents a valid certificate.
  - does not present a certificate.
  - presents an invalid certificate. In this case, the connection will use plaintext.
- VERIFY_CA: Allows the connection if the other host presents a certificate signed by a trusted CA. If no certificate is provided, the connection falls back to plaintext.
Internode TLS.mode is set to VERIFY_CA by default and cannot be set to TRY_VERIFY or VERIFY_FULL.

You can set vertica.com/tls-cache-duration to a value of your choice. In the following example, we will set it to 1 hour in the VerticaDB CR:

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  annotations:
    ...    
    vertica.com/tls-cache-duration: "3600"

You can connect to the database and verify the necessary TLS configurations, authentication settings, and secrets after TLS is enabled. The operator creates four built-in TLS client authentication configurations for future connections. You must not modify or delete these configurations.

$ vsql -h <hostname/ip> -U dbadmin

Welcome to vsql, the Vertica Analytic Database interactive terminal.

Type:  \h or \? for help with vsql commands
       \g or terminate with semicolon to execute query
       \q to quit
SSL connection (cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, protocol: TLSv1.2)

-- Verify TLS Configuration
vertdb=> SELECT * FROM tls_configurations;

     name     |  owner  |     certificate     |     ca_certificate     | cipher_suites | cipher_list |    mode
--------------+---------+---------------------+------------------------+---------------+-------------+------------
 https        | dbadmin | https_cert_0        | https_ca_cert_0        |               |             | TRY_VERIFY
 server       | dbadmin | server_cert_0       | server_ca_cert_0       |               |             | TRY_VERIFY
 data_channel | dbadmin | data_channel_cert_0 | data_channel_ca_cert_0 |               |             | VERIFY_CA
 LDAPLink     | dbadmin |                     |                        |               |             | DISABLE
 LDAPAuth     | dbadmin |                     |                        |               |             | DISABLE
(5 rows)

-- Verify TLS authentication created
vertdb=> SELECT auth_name, auth_host_type, auth_host_address, auth_method FROM client_auth WHERE auth_method = 'TLS';
            auth_name             | auth_host_type | auth_host_address | auth_method
----------------------------------+----------------+-------------------+-------------
 k8s_remote_ipv4_tls_builtin_auth | HOSTSSL        | 0.0.0.0/0         | TLS
 k8s_remote_ipv6_tls_builtin_auth | HOSTSSL        | ::/0              | TLS
 k8s_local_tls_builtin_auth       | LOCALSSL       |                   | TLS
(3 rows)

-- Verify that secret_name is same as set in httpsNMATLS.secret and cache duration is same as set in vertica.com/ tls-cache-duration annotation
vertdb=> SELECT name, secret_name, secret_manager_config from certificates where name in ('https_ca_cert_0','server_ca_cert_0', 'data_channel_ca_cert_0', 'https_cert_0', 'server_cert_0', 'data_channel_cert_0');
          name          |            secret_name            |                        secret_manager_config
------------------------+-----------------------------------+---------------------------------------------------------------------
 https_ca_cert_0        | vertica-db-https-tls-lhj82        | {"data-key":"ca.crt","namespace":"vertica","cache-duration":86400}
 server_ca_cert_0       | vertica-db-clientserver-tls-j86v9 | {"data-key":"ca.crt","namespace":"vertica","cache-duration":86400}
 data_channel_ca_cert_0 | vertica-db-internode-tls-gbcx8    | {"data-key":"ca.crt","namespace":"vertica","cache-duration":86400}
 https_cert_0           | vertica-db-https-tls-lhj82        | {"data-key":"tls.crt","namespace":"vertica","cache-duration":86400}
 server_cert_0          | vertica-db-clientserver-tls-j86v9 | {"data-key":"tls.crt","namespace":"vertica","cache-duration":86400}
 data_channel_cert_0    | vertica-db-internode-tls-gbcx8    | {"data-key":"tls.crt","namespace":"vertica","cache-duration":86400}
(6 rows)

Add multiple CA certificates to your TLS configuration

When a Certificate Authority provides multiple certificate files (such as root and intermediate certificates), you need to combine them into a single file and then create a Kubernetes secret as shown in the following example:


# combine them into a single file
$ cat cert1_ca.crt cert2_ca.crt cert3_ca.crt > combined_ca.crt
 
# use combined file to create kubernetes secret
$ kubectl create secret generic combined-ca-secret --from-file=ca.crt=combined_ca.crt

You can now use combined-ca-secret for setting up TLS with the VerticaDB operator in OpenText™ Analytics Database.

Configure TLS version and cipher suites

TLS 1.2 supports the following cipher suites:

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA

TLS 1.3 supports the following cipher suites:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Note

While OpenText™ Analytics Database offers multiple cipher suites, the Kubernetes deployment supports only those listed here as the Go HTTP client supports only this subset.

Example 1: Configure TLS 1.2

The following example configures TLS1.2 and enables all cipher suites supported by OpenText™ Analytics Database.

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  name: vdb-tls
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
     
spec:
  ...  
  dbTlsConfig:    
    tlsVersion: 2
    cipherSuites:""

Example 2: Configure TLS 1.3 with single cipher suite

The following example configures TLS 1.3 and enables a single cipher suite (TLS_AES_256_GCM_SHA384):

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  name: vdb-tls
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
     
spec:
  ...  
  dbTlsConfig:    
    tlsVersion: 3
    cipherSuites:"TLS_AES_256_GCM_SHA384"

Example 3: Configure TLS 1.2 with multiple cipher suites

The following example configures TLS 1.2 and enables multiple cipher suites (ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-CHACHA20-POLY1305, and ECDHE-RSA-AES128-GCM-SHA256):

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  name: vdb-tls
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
     
spec:
  ...  
  dbTlsConfig:    
    tlsVersion: 2
    cipherSuites:"ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256"

You can run the following command to verify the TLS version and status of the cipher suites:

$ kubectl describe vdb
Name:         vdb-tls
...
Spec:
  ...
  Db Tls Config:
    Cipher Suites:  ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
    Tls Version:    2
Status:
  ...
  Db Tls Config:
    Cipher Suites:    ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
    Tls Version:      2
  Events:
  Type    Reason                Age    From                Message
  ----    ------                ----   ----                -------  
  Normal   DBTLSUpdateStarted          18s                verticadb-operator  Started to update tls version to 2
  Normal   DBTLSUpdateSucceeded        9s                 verticadb-operator  Successfully updated tls version to 2
  Normal   DBTLSUpdateStarted          9s                 verticadb-operator  Started to update tls cipher suites to ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
  Normal   DBTLSUpdateSucceeded        1s                 verticadb-operator  Successfully updated tls cipher suites to ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256

You can also connect to the database and execute SELECT LIST_ENABLED_CIPHERS(); to verify the changes have been applied:

$ vsql
Welcome to vsql, the Vertica Analytic Database interactive terminal.
 
Type:  \h or \? for help with vsql commands
       \g or terminate with semicolon to execute query
       \q to quit
 
SSL connection (cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, protocol: TLSv1.2)
 
vertdb=> SELECT LIST_ENABLED_CIPHERS();
                                LIST_ENABLED_CIPHERS
-------------------------------------------------------------------------------------
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
(1 row)

Certificate Rotation

Some deployments require periodic rotation of certificates for security and compliance. During this process, the goal is to avoid restarting or shutting down database nodes. Instead, only the HTTPS service and NMA are restarted, allowing certificate updates with minimal disruption to database operations.

Note

You must rotate certificates before they expire.
It is recommended to create a restore point before rotating certificates, so the database can be recovered in case the rotation fails. For more information, see VerticaRestorePointsQuery custom resource definition.
The interval between two certificate rotations must be longer than the TLS cache duration (vertica.com/tls-cache-duration in the VerticaDB spec). If it is shorter, the rotation may fail especially if the currently used secret is updated.
You must make a note of the secret used for create_db as you can use it for revive_db.
If you use the same secret for both HTTPS and Client Server TLS, you must rotate them at the same time to avoid issues when the old secret is updated or removed.
Certificate rotation is not supported for sandboxes.
You cannot rotate certificates when the operator is performing other tasks such as a database upgrade.
If TLS certificate rotation fails for any reason, the system rolls back to the last TLS certificate applied before the rotation began.

Rotate TLS certificates

Use kubectl edit to locate and change the secret you want to rotate (Client Server TLS.secret or Https NMATLS.secret). The following example shows how to rotate Https NMATLS.secret from vertica-db-https-tls-s42r2 to custom-cert.


$ kubectl edit vdb cluster-name

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
...


  httpsNMATLS:
    mode:             TRY_VERIFY
    secret:           vertica-db-https-tls-s42r2

Change the value of Https NMATLS.secret to custom-cert and save.

$ kubectl edit vdb cluster-name

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
...


  httpsNMATLS:
    mode:             TRY_VERIFY
    secret:           custom-cert

Use kubectl describe to check the events generated by the operator while rotating TLS certificates:


$ kubectl describe vdb cluster-name

...  
Events:
  Type    Reason                       Age   From                Message
  ----    ------                       ----  ----                -------

  Normal  HTTPSTLSUpdateStarted        15m   verticadb-operator  Starting tls cert rotation for HTTP with secret name custom-cert and mode TRY_VERIFY
  Normal  HTTPSTLSUpdateSucceeded      14m   verticadb-operator  Successfully rotated HTTP tls cert with secret name custom-cert and mode TRY_VERIFY
  Normal  NMATLSCertRotationStarted    14m   verticadb-operator  Start rotating nma cert from vertica-db-https-tls-s42r2 to custom-cert
  Normal  NMATLSCertRotationSucceeded  14m   verticadb-operator  Successfully rotated nma cert from vertica-db-https-tls-s42r2 to custom-cert

You can connect to the database to verify that the TLS configurations are updated with the rotated certificate. Each time a TLS certificate is rotated, a new key, certificate, and CA certificate are generated with an incremented index. For example, if the initial HTTPS TLS configuration uses https_cert_0 and https_ca_cert_0, the next rotation will use https_cert_1 and https_ca_cert_1. This index-based naming makes it easier to track certificate versions.


$ vsql -h <hostname/ip> -U dbadmin

Welcome to vsql, the Vertica Analytic Database interactive terminal.

Type:  \h or \? for help with vsql commands
       \g or terminate with semicolon to execute query
      \q to quit
SSL connection (cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, protocol: TLSv1.2)

-- tls_configurations updated to use https_cert_1 instead of https_cert_0
vertdb=> SELECT * FROM tls_configurations;
     name     |  owner  |  certificate  |  ca_certificate  | cipher_suites | cipher_list |    mode
--------------+---------+---------------+------------------+---------------+-------------+------------
 server       | dbadmin | server_cert_0 | server_ca_cert_0 |               |             | TRY_VERIFY
 https        | dbadmin | https_cert_1  | https_ca_cert_1  |               |             | TRY_VERIFY
 LDAPLink     | dbadmin |               |                  |               |             | DISABLE
 LDAPAuth     | dbadmin |               |                  |               |             | DISABLE
 data_channel | dbadmin |               |                  |               |             | DISABLE
(5 rows)

-- check the secrets used to generate above certificates
vertdb=> SELECT name,secret_name FROM certificates where name ilike 'https_cert%';
     name     |        secret_name
--------------+----------------------------
 https_cert_0 | vertica-db-https-tls-s42r2
 https_cert_1 | vertica-db-https-tls-xmmd2
(2 rows)

Note

The VerticaDB operator automatically rotates the secret used by the NMA container. For the updated secret to take effect, the NMA container is restarted. You can verify that the NMA secret has been rotated using the following steps:

$ kubectl exec -it <vertica-db-pod-name> -c nma -- env | grep NMA_SECRET
NMA_SECRET_NAME=vertica-db-https-tls-xmmd2
NMA_SECRET_NAMESPACE=<vertica-namespace>

Automatically rotate TLS certificates

You can configure the VerticaDB to automatically rotate both httpsNMATLS and clientServerTLS certificates. Provide a list of Secrets and set the rotation interval as shown in the following example:

apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  name: vdb-tls
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
     
spec:
  ...
  clientServerTLS:
    autoRotate:
      interval: 43200 # rotates every 30 days (30 days * 24 hrs * 60 mins = 43200 mins )
      restartAtEnd: true
      secrets:
      - clientServerSecret1
      - clientServerSecret2
      - clientServerSecret3
    mode: TRY_VERIFY
  ...
  httpsNMATLS:
    autoRotate:
      secrets:
        - httpsSecret1
        - httpsSecret2
        - httpsSecret3
      interval: 180 # rotates every 3 hours
      restartAtEnd: true
      mode: TRY_VERIFY

After automatic certificate rotation is enabled, you can check the VerticaDB status to see the currently used secrets and their last update time:

$ kubectl describe vdb
Name:         vdb-tls
...
Status:
  ...
  Tls Configs:
    Auto Rotate Secrets:
      httpsSecret1
      httpsSecret2
      httpsSecret3
    Last Update:  2025-09-23T19:10:52Z # last updated date and time of httpsNMA secret
    Mode:         try_verify
    Name:         httpsNMA
    Secret:       httpsSecret3 # current in-use httpsNMA secret
    Auto Rotate Secrets:
      clientServerSecret1
      clientServerSecret1
      clientServerSecret1
    Last Update:   2025-09-23T19:15:53Z # last updated date and time of clientServer secret
    Mode:          try_verify
    Name:          clientServer
    Secret:        clientServerSecret1 # current in-use clientServer secret

Note

If a new certificate fails, the system automatically rolls back to the last known good Secret. It also logs a warning in the event log, skips the faulty Secret, and continues with the next one.
If you modify the Secret list and the current Secret still appears in the updated autoRotate.secrets[] list, rotation continues with the next Secret in the new list. If the current Secret is no longer in the list, rotation restarts from the first Secret.

You can verify that the TLS configuration of VerticaDB has been updated by following the steps in the Rotate TLS certificates section in this topic.

Certificate rotation using AWS secret versioning

You can store certificates in a single AWS Secrets Manager secret and use versioning to manage updates. This makes it easy to rotate certificates by changing the version ID.

To allow VerticaDB to read the secret from AWS Secrets Manager, see Secrets management.

Following are steps to use and rotate version enabled AWS secret:

Verify the configuration of your version enabled AWS secret:


$ aws secretsmanager describe-secret --secret-id my_vertica_secret
 {
     "ARN": "arn:aws:secretsmanager:us-east-1:821715312548:secret:my_vertica_secret-fn1msI",
     "Name": "my_vertica_secret",
     "Description": "secret with version id",
     "LastChangedDate": "2025-06-13T11:08:15.533000-04:00",
     "LastAccessedDate": "2025-06-12T20:00:00-04:00",
     "VersionIdsToStages": {
         "46c90cb1-58e9-4053-bac0-5798a9f03daf": [
             "AWSPREVIOUS"
         ],
         "bd8e7d37-12b9-4433-b292-4ea33ab9e8e4": [
             "AWSCURRENT"
         ]
      },
  "CreatedDate": "2025-06-13T11:01:41.729000-04:00"
 }

Let's assume you used AWSPREVIOUS version of the secret in your initial VerticaDB CR:


apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
...

  Https NMATLS:
    Mode:             TRY_VERIFY
    Secret:           awssm://arn:aws:secretsmanager:us-east-1:821715312548:secret:my_vertica_secret-fn1msI@46c90cb1-58e9-4053-bac0-5798a9f03daf

To rotate the certificate, edit the VerticaDB and change the versionId to use the AWSCURRENT version as follows:


$ kubectl edit vdb cluster-name
apiVersion: vertica.com/v1
kind: VerticaDB
metadata:
  annotations:
    ...
    vertica.com/enable-tls-auth: "true"
...

  Https NMATLS:
    Mode:             TRY_VERIFY
    Secret:           awssm://  arn:aws:secretsmanager:us-east-1:821715312548:secret:my_vertica_secret-fn1msI@bd8e7d37-12b9-4433-b292-4ea33ab9e8e4

You can verify that the TLS configuration of VerticaDB has been updated by following the steps in the Rotate TLS certificates section in this topic.