The following example uses YAML properties to enable TLS/SSL security and specify the truststore and keystore passwords. First you must enable TLS/SSL encryption, using the cluster.config.deployment.ssl.enabled property. Then you choose which ports will use SSL encryption (in this example, the internal and external ports, but not DR). Finally, you specify the passwords for the keystore and truststore. The YAML does not include the actual content of the truststore and keystore files, since they are in a binary format.

cluster:
  config:
    deployment:
      ssl:
        enabled: true
        external: true
        internal: true
        keystore:
          password: topsecret
        truststore:
          password: topsecret
  clusterSpec:
    ssl:
      insecure: false

Using the preceding YAML file (calling it ssl.yaml), we can complete the SSL configuration by specifying the truststore and keystore files on the helm command line with the --set-file argument:

helm install mydb voltdb/voltdb                                         \
  --values myconfig.yaml                                                \
  --values ssl.yaml                                                     \
  --set-file cluster.config.deployment.ssl.keystore.file=mykey.jks      \
  --set-file cluster.config.deployment.ssl.truststore.file=mytrust.jks  \
  --set-file cluster.clusterSpec.ssl.certificateFile=mycert.pem

Three important notes concerning TLS/SSL configuration:

An alternative method is to store the key and trust stores and passwords in a Kubernetes secret. Secrets are a standard feature of Kubernetes that allow you to store sensitive information as key value pairs in a protected space. Three advantages of using a secret are:

To use a Kubernetes secret to store the TLS/SSL information for your database, you must first create the necessary files as described in Section 7.2, “Configuring TLS/SSL”. Next you create your Kubernetes secret using the kubectl create secret command, specifying the key names and corresponding artifacts as arguments. For example:

$ kubectl create secret generic my-ssl-creds     \
    --from-file=keystore_data=mykey.jks          \
    --from-file=truststore_data=mytrust.jks      \
    --from-file=certificate=mycert.pem           \
    --from-literal=keystore_password=topsecret   \
    --from-literal=truststore_password=topsecret
 

It is critical you use the key names keystore_data, truststore_data, keystore_password, truststore_password, and certificate for the keystore, truststore, corresponding passwords, and PEM file, respectively. If not, the Volt Operator will not be able to find them. Also, the secret must be the the same Kubenetes namespace as the Helm release you are configuring.

Once you create the secret you can use it to configure your database by not setting any of standard SSL properties such as the cluster.config.deployment.ssl... properties or cluster.clusterSpec.ssl.certificateFile. Instead, set the property cluster.config.deployment.ssl.sslSecret.certSecretName. Using the secret created in the preceding example, the configuration of your database will look something like this:

cluster:
  config:
    deployment:
      ssl:
        sslSecret:
          certSecretName: my-ssl-creds

Another alternative for maintaining the TLS/SSL information is to use the Kubernetes cert-manager (cert-manager.io). The cert-manager is an add-on for Kubernetes that helps you create and maintain certificates and other private information in Kubernetes. If you wish to use cert-manager for self-signed certificates, you not only use it to store the certificate and truststore, you create them with cert-manager as well. (For more detailed information concerning cert-manager, see the cert-manager documentation.)

The basic steps for storing self-signed TLS/SSL credentials in cert-manager are:

You create the Kubernetes secret containing the password using the kubectl create secret command. For example, The following command creates a secret (my-ssl-password) with the password "topsecret". The password must be assigned to the label password:

$ kubectl create secret generic my-ssl-password     \
    --from-literal=password=topsecret
 

You create the cert-manager issuer and the certificate request using YAML properties. The easiest way to do this is by typing the property declarations into a YAML file. For example, the following two YAML files create a cert-manager issuer service and request a certificate.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
   name: selfsigned-issuer
   namespace: mydb
spec:
   selfSigned: {}

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-ssl-certificate
  namespace: mydb
spec:
  commonName: voltdb.com
  duration: 8766h
  secretName: my-ssl-creds
  keystores:
    jks:
      create: true
      passwordSecretRef:
        name: my-ssl-password
        key: password
  issuerRef:
    name: selfsigned-issuer
    kind: Issuer
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
  usages:
    - server auth

Four key points to note about the certificate request are:

Once you create the YAML files, you can create the issuer and request the certificate:

$ kubectl apply -f create-issuer.yaml    # Do only once
$ kubectl apply -f request-cert.yaml 

Finally, in your database configuration, you point to the two secrets containing the password and created by the certificate request (in this case, my-ssl-password and my-ssl-creds) the same way you would for a manually created secret:

cluster:
  config:
    deployment:
      ssl:
        sslSecret:
          passwordSecretName: my-ssl-password
          certSecretName: my-ssl-creds

In Volt Active Data V13.0 and later, the Volt Management Center (VMC) is run as a separate service and pod. This service has its own TLS/SSL configuration, both for connecting to the database servers (using the vmc.voltdb.ssl.* properties) and for its outbound HTTP interface for access by users (using the vmc.service.ssl.* properties). You can configure these properties manually, which you do by setting the associated ...enabled property to true and then setting the specific TLS/SSL settings using the accompanying properties.

However, it is far more convenient to let the operator configure these properties for you. If you accept the default — or set the ...enabled properties to auto — the operator will set the inbound connection between the VMC service and the database servers to match the servers' TS/SSL settings and it will also use these settings to enable TLS/SSL for the VMC service's outbound HTTP port.