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 TLS via VerticaDB operator using Kubernetes or AWS secrets is supported in OpenText™ Analytics Database version 25.3.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, and add the annotation vertica.com/enable-tls-auth: "true".

If httpsNMATLS.secret and clientServerTLS.secret are not specified, the operator will automatically generate two secrets. These secrets will follow the naming patterns <vdb-name>-https-tls-<5-digits-random-string> and <vdb-name>-clientserver-tls-<5-digits-random-string>.

If httpsNMATLS.mode and clientServerTLS.mode are not specified, the default mode try_verify 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
  httpsNMATLS:
    mode:             TRY_VERIFY
    secret:           your-https-tls-secret
```

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    51s    verticadb-operator  Starting to configure TLS for httpsNMA
  Normal  TLSConfigurationSucceeded  47s    verticadb-operator  Successfully set HTTP tls config
  Normal  TLSConfigurationStarted    47s    verticadb-operator  Starting to configure TLS for clientServer
  Normal  TLSConfigurationSucceeded  45s    verticadb-operator  Successfully set Server tls config

Note

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

Use kubectl describe to check the secrets that are generated:


$ kubectl describe vdb cluster-name

...

  Client Server TLS:
    Mode:    TRY_VERIFY
    Secret:  vertica-db-clientserver-tls-7j2z7
  ...

  Https NMATLS:
    Mode:             TRY_VERIFY
    Secret:           vertica-db-https-tls-w9dxx

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-7j2z7                                                     kubernetes.io/tls                3      5m7s
vertica-db-https-tls-w9dxx                                                            kubernetes.io/tls                3      5m18s
```
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.

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 VerticaBB 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
 LDAPLink     | dbadmin |               |                  |               |             | DISABLE
 LDAPAuth     | dbadmin |               |                  |               |             | DISABLE
 data_channel | 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',  'https_cert_0', 'server_cert_0');
      name       |            secret_name            |                       secret_manager_config
------------------+-----------------------------------+--------------------------------------------------------------------
 https_ca_cert_0  | vertica-db-https-tls-bvjwp        | {"data-key":"ca.crt","namespace":"vertica","cache-duration":3600}
 server_ca_cert_0 | vertica-db-clientserver-tls-dg9hb | {"data-key":"ca.crt","namespace":"vertica","cache-duration":3600}
 https_cert_0     | vertica-db-https-tls-bvjwp        | {"data-key":"tls.crt","namespace":"vertica","cache-duration":3600}
 server_cert_0    | vertica-db-clientserver-tls-dg9hb | {"data-key":"tls.crt","namespace":"vertica","cache-duration":3600}
(4 rows)

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 HTTPS and Client Server certificates at the same time.
You cannot rotate certificates when the operator is performing other tasks such as a database upgrade.

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>

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.