Authenticate and Authorize Users

ScalarDB Cluster has a mechanism to authenticate and authorize users.

This guide describes how to use authentication and authorization in ScalarDB Cluster.

Overview

By using authentication and authorization, you can create users and grant or revoke their privileges. You can create a user by using the CREATE USER command, and you can grant or revoke one's privileges on a table or a namespace by using the GRANT or REVOKE command, respectively. For details about such data control language (DCL) commands, see DCL.

Users can log in to ScalarDB Cluster with a username and a password and execute SQL statements if they have the required privileges.

Authentication and authorization support two types of users:

• Superusers: This type of user has all privileges. Only superusers can create or drop other users and namespaces.
• Normal users: This type of user initially doesn't have any privileges, so they need to be granted privileges by a superuser or another user who has the GRANT privilege.

The following privileges are available when using authentication and authorization:

• SELECT
• INSERT
• UPDATE
• DELETE
• CREATE
• DROP
• TRUNCATE
• ALTER
• GRANT

For details about privileges, see Which privileges are required for each type of operation.

Configurations

This section describes the available configurations for authentication and authorization.

ScalarDB Cluster node configurations

To enable authentication and authorization, you need to set scalar.db.cluster.auth.enabled to true.

Name	Description	Default
scalar.db.cluster.auth.enabled	Whether authentication and authorization are enabled.	false

You can also set the following configurations:

Name	Description	Default
scalar.db.cluster.auth.cache_expiration_time_millis	Cache expiration time for authentication and authorization information in milliseconds.	60000 (1 minute)
scalar.db.cluster.auth.auth_token_expiration_time_minutes	Authentication and authorization token expiration time in minutes.	1440 (1 day)
scalar.db.cluster.auth.auth_token_gc_thread_interval_minutes	Authentication and authorization token garbage collection (GC) thread interval in minutes.	360 (6 hours)
scalar.db.cluster.auth.pepper	A secret value added to a password before hashing. If not specified, the password is hashed without pepper.

note

If you enable authentication and authorization, you will also need to set scalar.db.cross_partition_scan.enabled to true for the system namespace (scalardb by default) because authentication and authorization perform cross-partition scans internally.

ScalarDB Cluster Java client SDK configurations

To enable authentication and authorization on the client side, you need to set scalar.db.cluster.auth.enabled to true.

Name	Description	Default
scalar.db.cluster.auth.enabled	Whether authentication and authorization are enabled.	false

In addition to the configuration in the ScalarDB Cluster SQL client configurations section, you also need to set scalar.db.sql.cluster_mode.username and scalar.db.sql.cluster_mode.password to specify the username and password of the client.

Name	Description	Default
scalar.db.sql.cluster_mode.username	The username of the client.
scalar.db.sql.cluster_mode.password	The password of the client.

Initial user

When you enable authentication and authorization, the initial user admin is created and the initial password of that user is admin. This user is a superuser and has all privileges. You can log in with this user and create other users if necessary.

warning

For security purposes, be sure to change the password of the initial user, especially before deploying to a production environment.

Which privileges are required for each type of operation

The following tables show which privileges are required for each type of operation:

DDL

Command	Superuser required	Required privileges
CREATE NAMESPACE	true
DROP NAMESPACE	true
CREATE TABLE		CREATE
DROP TABLE		DROP
CREATE INDEX		CREATE
DROP INDEX		DROP
TRUNCATE TABLE		TRUNCATE
ALTER TABLE		ALTER
CREATE COORDINATOR TABLES	true
DROP COORDINATOR TABLES	true
TRUNCATE COORDINATOR TABLES	true

DML

Command	Superuser required	Required privileges
SELECT		SELECT
INSERT		INSERT
UPSERT		INSERT
UPDATE		SELECT and UPDATE
DELETE		SELECT and DELETE

DCL

Command	Superuser required	Required privileges
CREATE USER	true
ALTER USER	true (Users can change their own password.)
DROP USER	true
GRANT		GRANT (Users can grant only the privileges that they have.)
REVOKE		GRANT (Users can revoke only the privileges that they have.)

Wire encryption

ScalarDB Cluster also supports wire encryption by using Transport Layer Security (TLS). If you enable authentication and authorization, enabling wire encryption in production environments to protect the user credentials is strongly recommended.

This wire encryption feature encrypts:

• The communications between the ScalarDB Cluster node and clients.
• The communications between all ScalarDB Cluster nodes (the cluster's internal communications).

This feature uses gRPC's TLS support. For details, see the official gRPC Security Policy.

Configurations

This section describes the available configurations for wire encryption.

ScalarDB Cluster node configurations

To enable wire encryption, you need to set scalar.db.cluster.tls.enabled to true.

Name	Description	Default
scalar.db.cluster.tls.enabled	Whether wire encryption (TLS) is enabled.	false

You also need to set the following configurations:

Name	Description	Default
scalar.db.cluster.tls.ca_root_cert_pem	The custom CA root certificate (PEM data) for TLS communication.
scalar.db.cluster.tls.ca_root_cert_path	The custom CA root certificate (file path) for TLS communication.
scalar.db.cluster.tls.override_authority	The custom authority for TLS communication. This doesn't change what host is actually connected. This is intended for testing, but may safely be used outside of tests as an alternative to DNS overrides. For example, you can specify the hostname presented in the certificate chain file that you set for scalar.db.cluster.node.tls.cert_chain_path.
scalar.db.cluster.node.tls.cert_chain_path	The certificate chain file used for TLS communication.
scalar.db.cluster.node.tls.private_key_path	The private key file used for TLS communication.

To specify the certificate authority (CA) root certificate, you should set either scalar.db.cluster.tls.ca_root_cert_pem or scalar.db.cluster.tls.ca_root_cert_path. If you set both, scalar.db.cluster.tls.ca_root_cert_pem will be used.

ScalarDB Cluster Java client SDK configurations

To enable wire encryption on the client side, you need to set scalar.db.cluster.tls.enabled to true.

Name	Description	Default
scalar.db.cluster.tls.enabled	Whether wire encryption (TLS) is enabled.	false

You also need to set the following configurations:

Name	Description	Default
scalar.db.cluster.tls.ca_root_cert_pem	The custom CA root certificate (PEM data) for TLS communication.
scalar.db.cluster.tls.ca_root_cert_path	The custom CA root certificate (file path) for TLS communication.
scalar.db.cluster.tls.override_authority	The custom authority for TLS communication. This doesn't change what host is actually connected. This is intended for testing, but may safely be used outside of tests as an alternative to DNS overrides. For example, you can specify the hostname presented in the certificate chain file that you set for scalar.db.cluster.node.tls.cert_chain_path.

To specify the CA root certificate, you should set either scalar.db.cluster.tls.ca_root_cert_pem or scalar.db.cluster.tls.ca_root_cert_path. If you set both, scalar.db.cluster.tls.ca_root_cert_pem will be used.