Command logging provides durability of the database content across failures. You can control the level of durability as well as the length of time required to recover the database by configuring the type of command logging and size of the logs themselves. In Kubernetes this is done with the cluster.config.deployment.commandlog properties. The following examples show the equivalent configuration in both XML and YAML:

<commandlog enabled="true"
            synchronous="true"
            logsize="3072">
  <frequency time="300" 
             transactions="1000"/>
</commandlog>

cluster:
  config:
    deployment:
      commandlog:
        enabled: true
        synchronous: true
        logsize: 3072
        frequency:
          transactions 1000

Export simplifies the integration of the VoltDB database with external databases and systems. You use the export configuration to define external "targets" the database can write to. In Kubernetes you define export targets using the cluster.config.deployment.export.configurations property. Note that the configurations property can accept multiple configuration definitions. In YAML, you specify a list by prefixing each list element with a hyphen, even if there is only one element. The following examples show the equivalent configuration in both XML and YAML for configuring a file export connector:

<export>
  <configuration 
      target="eventlog" 
      type="file">
    <property 
       name="type">csv</property>
    <property 
       name="nonce">eventlog</property>
  </configuration>
</export>

cluster:
  config:
    deployment:
      export:
        configurations:
           - target: eventlog
             type: file
             properties:
                type: csv
                nonce: eventlog                 

There are a number of options for securing a VoltDB database, including basic usernames and passwords in addition to industry network solutions such as Kerberos and SSL. Basic security is enabled in the configuration with the cluster.config.deployment.security.enabled property. You must also use the property and its children to define the actual usernames, passwords, and assigned roles. Again, the users property expects a list of sub-elements so you must prefix each set of properties with a hyphen.

Finally, if you do enable basic security, you must also tell the VoltDB operator which account to use when accessing the database. To do that, you define the cluster.config.auth properties, as shown below, which must specify an account with the built-in administrator role. The following examples show the equivalent configurations in both XML and YAML, including the assignment of an account to the VoltDB Operator:

<security enabled="true"/>
<users>
  <user name="admin" 
        password="superman" 
        roles="administrator"/>
  <user name="mitty" 
        password="thurber" 
        roles="user"/>
</users>

cluster:
  config:
    deployment:
      security:
        enabled: true
      users:
        - name: admin
          password: superman
          roles: administrator
        - name: mitty
          password: thurber
          roles: user
    auth:
      username: admin
      password: superman

Another important aspect of security is securing and authenticating the ports used to access the database. The most common way to do this is by enabling TLS/SSL to encrypt data and authenticate the servers using user-created certificates. The process for creating the private keystore and truststore in Java is described in the section on "Configuring TLS/SSL on the VoltDB Server" in the Using VoltDB guide. This process is the same whether you are running the cluster directly on servers or in Kubernetes.

The one difference when enabling TLS/SSL for the cluster in Kubernetes is that you must also configure the operator with an appropriate truststore, in PEM format. The easiest way to do this is to configure the operator using the same truststore and password you use for the cluster itself. First, you will need to convert the truststore to PEM format using the Java keytool:

keytool -export          \
    -alias my.key -rfc   \
    -file mytrust.pem    \
    -keystore mykey.jks  \
    -storepass topsecret \
    -keypass topsecret

Once you have your keystore, truststore, and truststore in PEM format, you can configure the cluster and operator with the appropriate SSL properties. The following examples show the equivalent configurations in both XML and YAML (minus the actual truststore and keystore files).

<ssl enabled="true" 
     external="true" 
     internal="true">
  <keystore path="mykey.jks" 
     password="topsecret"/>
  <truststore path="mytrust.jks" 
     password="topsecret"/>
</ssl>

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=mytrust.pem

Three important notes concerning TLS/SSL configuration:

Finally, TLS/SSL certificates have an expiration date. It is important you replace the certificate before it expires (if cluster.clusterSpec.ssl.insecure is false, which is the default). If not, the operator will lose the ability to communicate with the cluster pods. See Section 5.3, “Updating TLS Security Certificates” for instructions on updating the TLS/SSL certificates in Kubernetes.