Archive
Archive
There are two aspects to security with Volt Active Data — security within the database with is managed through user accounts and roles and network security between the database nodes, between the cluster and client applications, and between clusters in the case of cross datacenter replication (XDCR). For internal security, you define user accounts as part of the database configuration and assign them to roles that are defined as part of the schema. For network security, Volt recommends encryption and authentication certificates using the TLS/SSL protocol. The following sections explain how to configure both types of security within Kubernetes.
User accounts allow you to control who has access to specific functions and procedures within the database. Security
is enabled in the configuration with the cluster.config.deployment.security.enabled property. You must
also use the properties to define the actual user names, passwords, and assigned roles. The users
property expects a list of sub-elements so you must prefix each set of properties with a hyphen.
If you 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 example enables basic security, defines two
accounts, and assigns the admin account for use by the VoltDB Operator:
V12.x Documentationcluster:
config:
deployment:
security:
enabled: true
users:
- name: admin
password: superman
roles: administrator
- name: mitty
password: thurber
roles: user
auth:
username: admin
password: supermanOnce you have defined your account names, password and roles, as an additional level of privacy you can hash the contents of the YAML file so the passwords are not in plain text. With the helm voltadmin plugin (described in Appendix A, Helm voltadmin Plugin) you can use the mask command to hash the passwords. If you only specify an input file, the passwords are hashed in place and the input file overwritten. If you include a second file specification, the masked YAML file is written to that file instead.
The following example uses the voltadmin mask command to process the file
myaccounts.yaml and write the YAML including hashed passwords to the file
hashedaccounts.yaml.
$ helm voltadmin mask myaccounts.yaml hashedaccounts.yaml
You can then use the hashed file when starting the database:
$ helm install mydb voltdb/voltdb \
--values myconfig.yaml \
--values hashedaccounts.yaml