Security parameters
Use these client authentication configuration parameters and general security parameters to configure TLS.
-
To configure Vertica for client-server TLS, see Configuring client-server TLS.
-
To configure JDBC and ODBC clients for TLS, see Configuring TLS for JDBC clients and Configuring TLS for ODBC Clients.
-
For Kerberos-related parameters, see Kerberos parameters.
Database parameters
- DataSSLParams
- This parameter has been deprecated. Use the data_channel TLS Configuration instead.
Enables encryption using SSL on the data channel. The value of this parameter is a comma-separated list of the following:
-
An SSL certificate (chainable)
-
The corresponding SSL private key
-
The SSL CA (Certificate Authority) certificate.
You should set
EncryptSpreadComm
before setting this parameter.In the following example, the SSL Certificate contains two certificates, where the certificate for the non-root CA verifies the certificate for the cluster. This is called an SSL Certificate Chain.
=> ALTER DATABASE DEFAULT SET PARAMETER DataSSLParams = '----BEGIN CERTIFICATE-----<certificate for Cluster>-----END CERTIFICATE----- -----BEGIN CERTIFICATE-----<certificate for non-root CA>-----END CERTIFICATE-----, -----BEGIN RSA PRIVATE KEY-----<private key for Cluster>-----END RSA PRIVATE KEY-----, -----BEGIN CERTIFICATE-----<certificate for public CA>-----END CERTIFICATE-----';
-
- DefaultIdleSessionTimeout
- Indicates a default session timeout value for all users where
IDLESESSIONTIMEOUT
is not set. For example:=> ALTER DATABASE DEFAULT SET defaultidlesessiontimeout = '300 secs';
- DHParams
-
Deprecated
This parameter has been deprecated and will be removed in a future release.String, a Diffie-Hellman group of at least 2048 bits in the form:
-----BEGIN DH PARAMETERS-----...-----END DH PARAMETERS-----
You can generate your own or use the pre-calculated Modular Exponential (MODP) Diffie-Hellman groups specified in RFC 3526.
Changes to this parameter do not take effect until you restart the database.
Default: RFC 3526 2048-bit MODP Group 14:
-----BEGIN DH PARAMETERS-----MIIBCAKCAQEA/////////// JD9qiIWjCNMTGYouA3BzRKQJOCIpnzHQCC76mOxObIlFKCHmONAT d75UZs806QxswKwpt8l8UN0/hNW1tUcJF5IW1dmJefsb0TELppjf tawv/XLb0Brft7jhr+1qJn6WunyQRfEsf5kkoZlHs5Fs9wgB8uKF jvwWY2kg2HFXTmmkWP6j9JM9fg2VdI9yjrZYcYvNWIIVSu57VKQd wlpZtZww1Tkq8mATxdGwIyhghfDKQXkYuNs474553LBgOhgObJ4O i7Aeij7XFXfBvTFLJ3ivL9pVYFxg5lUl86pVq5RXSJhiY+gUQFXK OWoqsqmj//////////wIBAg==-----END DH PARAMETERS-----
- DisableInheritedPrivileges
- Boolean, whether to disable privilege inheritance at the database level (enabled by default).
- DoUserSpecificFilteringInSysTables
- Boolean, specifies whether a non-superuser can view details of another user:
-
0: Users can view details of other users.
-
1: Users can only view details about themselves.
Default: 0
-
- EnableAllRolesOnLogin
- Boolean, specifies whether to automatically enable all roles granted to a user on login:
-
0: Do not automatically enable roles
-
1: Automatically enable roles. With this setting, users do not need to run SET ROLE.
Default: 0 (disable)
-
- EnabledCipherSuites
- Specifies which SSL cipher suites to use for secure client-server communication. Changes to this parameter apply only to new connections.
Default: Vertica uses the Microsoft Schannel default cipher suites. For more information, see the Schannel documentation.
- EnableConnectCredentialForwarding
- When using CONNECT TO VERTICA, whether to use the password of the current user to authenticate to a target database.
Default: 0 (disable)
- EnableOAuth2JITCleanup
- If enabled, users created by just-in-time OAuth provisioning are automatically dropped if the user does not log in after the number of days specified by OAuth2UserExpiredInterval.
To view provisioned users, see USERS.
Default: 0 (disable)
- EncryptSpreadComm
- Enables Spread encryption on the control channel, set to one of the following strings:
-
vertica
: Specifies that Vertica generates the Spread encryption key for the database cluster. -
aws-kms|
key-name
, wherekey-name
is a named key in the iAWS Key Management Service (KMS). On database restart, Vertica fetches the named key from the KMS instead of generating its own.
If the parameter is empty, Spread communication is unencrypted. In general, you should enable this parameter before modifying other security parameters.
Enabling this parameter requires database restart.
-
- GlobalHeirUsername
- A string that specifies which user inherits objects after their owners are dropped. This setting ensures preservation of data that would otherwise be lost.
Set this parameter to one of the following string values:
-
Empty string: Objects of dropped users are removed from the database.
-
username
: Reassigns objects of dropped users tousername
. Ifusername
does not exist, Vertica creates that user and setsGlobalHeirUsername
to it. -
<auto>
: Reassigns objects of dropped LDAP or just-in-time-provisioned users to thedbadmin
user. The brackets (< and >) are required for this option.
For more information about usage, see Examples.
Default:
<auto>
-
- ImportExportTLSMode
- When using CONNECT TO VERTICA to connect to another Vertica cluster for import or export, specifies the degree of stringency for using TLS. Possible values are:
-
PREFER
: Try TLS but fall back to plaintext if TLS fails. -
REQUIRE
: Use TLS and fail if the server does not support TLS. -
VERIFY_CA
: Require TLS (as with REQUIRE), and also validate the other server's certificate using the CA specified by the "server" TLS Configuration's CA certificates (in this case, "ca_cert" and "ica_cert"):=> SELECT name, certificate, ca_certificate, mode FROM tls_configurations WHERE name = 'server'; name | certificate | ca_certificate | mode --------+------------------+--------------------+----------- server | server_cert | ca_cert,ica_cert | VERIFY_CA (1 row)
-
VERIFY_FULL
: Require TLS and validate the certificate (as with VERIFY_CA), and also validate the server certificate's hostname. -
REQUIRE_FORCE
,VERIFY_CA_FORCE
, andVERIFY_FULL_FORCE
: Same behavior asREQUIRE
,VERIFY_CA
, andVERIFY_FULL
, respectively, and cannot be overridden by CONNECT TO VERTICA.
Default:
PREFER
-
- InternodeTLSConfig
- The TLS Configuration to use for internode encryption.
For example:
=> ALTER DATABASE DEFAULT SET InternodeTLSConfig = my_tls_config;
Default:
data_channel
- LDAPAuthTLSConfig
- The TLS Configuration to use for TLS with LDAP authentication.
For example:
=> ALTER DATABASE DEFAULT SET LDAPAuthTLSConfig = my_tls_config;
Default:
ldapauth
- LDAPLinkTLSConfig
- The TLS Configuration to use for TLS for the LDAP Link service.
For example:
=> ALTER DATABASE DEFAULT SET LDAPLinkTLSConfig = my_tls_config;
Default:
ldaplink
- OAuth2JITClient
-
Deprecated
This parameter is deprecated. Use theOAuth2JITRolesClaimName
parameter instead.The client/application name that contains Vertica roles in the Keycloak identity provider. The Vertica roles under
resource_access.
OAuth2JITClient
.roles
are automatically granted to and set as default roles for users created by just-in-time provisioning. Roles that do not exist in Vertica are ignored.For details, see Just-in-time user provisioning.
Default:
vertica
- OAuth2JITRolesClaimName
- Specifies an IdP client with one or more roles that correspond to a Vertica database role. During just-in-time user provisioning, each client role that matches an existing Vertica role is automatically assigned to the user. Roles that do not exist in Vertica are ignored.
For authentication records that use JWT validation, Vertica retrieves the client roles from the access token.
To retrieve client roles for authentication records that use IdP validation, Vertica sends a request to either the
introspect_url
or theuserinfo_url
set in the authentication record. This parameter requires the full path to the roles claim in that request. For example, the full path to the roles claim in a Keycloak request uses the following format:resource_access.
clientName
.roles
For details, see Just-in-time user provisioning.
Default:
resource_access.vertica.roles
- OAuth2JITForbiddenRoles
- Vertica database roles that you do not want Vertica to automatically assign to users during just-in-time provisioning. This parameter accepts one or more roles as a comma-separated list.
- OAuth2JITGroupsClaimName
- The name of the IdP group whose name or role mappings correspond to Vertica database roles. During just-in-time user provisioning, each group name or group role mapping that matches an existing Vertica role is automatically assigned to the user. Roles that do not exist in Vertica are ignored.
For authentication records that use JWT validation, Vertica retrieves the JIT-provisioned user's groups from the access token.
To retrieve the JIT-provisioned user's groups for authentication records that use IdP validation, Vertica sends a request to either the
introspect_url
or theuserinfo_url
set in the authentication record.Default:
groups
- OAuth2UserExpiredInterval
- If EnableOAuthJITCleanup is enabled, users created by just-in-time OAuth provisioning are automatically dropped after not logging in for the number of days specified by OAuth2UserExpiredInterval. The number of days the user has not logged in is calculated relative to the
LAST_LOGIN_TIME
column in the USERS system table.Note
The
LAST_LOGIN_TIME
as recorded by the USERS system table is not persistent; if the database is restarted, theLAST_LOGIN_TIME
for users created by just-in-time user provisioning is set to the database start time (this appears as an empty value inLAST_LOGIN_TIME
).You can view the database start time by querying the DATABASES system table:
=> SELECT database_name, start_time FROM databases; database_name | start_time ---------------+------------------------------- VMart | 2023-02-06 14:26:50.630054-05 (1 row)
Default: 14
- PasswordLockTimeUnit
- The time units for which an account is locked by
PASSWORD_LOCK_TIME
afterFAILED_LOGIN_ATTEMPTS
, one of the following:-
'd'
: days (default) -
'h'
: hours -
'm'
: minutes -
's'
: seconds
For example, to configure the default profile to lock user accounts for 30 minutes after three unsuccessful login attempts:
=> ALTER DATABASE DEFAULT SET PasswordLockTimeUnit = 'm' => ALTER PROFILE DEFAULT LIMIT PASSWORD_LOCK_TIME 30;
-
- RequireFIPS
- Boolean, specifies whether the FIPS mode is enabled:
-
0 (disable)
-
1: (enable)
On startup, Vertica automatically sets this parameter from the contents of the file
crypto.fips_enabled
. You cannot modify this parameter.For details, see FIPS compliance for the Vertica server.
Default: 0
-
- SecurityAlgorithm
- Sets the algorithm for the function that hash authentication uses, one of the following:
-
SHA512
-
MD5
For example:
=> ALTER DATABASE DEFAULT SET SecurityAlgorithm = 'SHA512';
Default:
SHA512
-
- ServerTLSConfig
- The TLS Configuration to use for client-server TLS.
For example:
=> ALTER DATABASE DEFAULT SET ServerTLSConfig = my_tls_config;
Default:
server
- SystemCABundlePath
- The absolute path to a certificate bundle of trusted CAs. This CA bundle is used when establishing TLS connections to external services such as AWS or Azure through their respective SDKs and libcurl. The CA bundle file must be in the same location on all nodes.
If this parameter is empty, Vertica searches the "standard" paths for the CA bundles, which differs between distributions:
- Red Hat-based:
/etc/pki/tls/certs/ca-bundle.crt
- Debian-based:
/etc/ssl/certs/ca-certificates.crt
- SUSE:
/var/lib/ca-certificates/ca-bundle.pem
Example:
=> ALTER DATABASE DEFAULT SET SystemCABundlePath = 'path/to/ca_bundle.pem';
Default: Empty
- Red Hat-based:
TLS parameters
To set your Vertica database's TLSMode, private key, server certificate, and CA certificate(s), see TLS configurations. In versions prior to 11.0.0, these parameters were known as EnableSSL, SSLPrivateKey, SSLCertificate, and SSLCA, respectively.
Examples
Set the database parameter GlobalHeirUsername
:
=> \du
List of users
User name | Is Superuser
-----------+--------------
Joe | f
SuzyQ | f
dbadmin | t
(3 rows)
=> ALTER DATABASE DEFAULT SET PARAMETER GlobalHeirUsername='SuzyQ';
ALTER DATABASE
=> \c - Joe
You are now connected as user "Joe".
=> CREATE TABLE t1 (a int);
CREATE TABLE
=> \c
You are now connected as user "dbadmin".
=> \dt t1
List of tables
Schema | Name | Kind | Owner | Comment
--------+------+-------+-------+---------
public | t1 | table | Joe |
(1 row)
=> DROP USER Joe;
NOTICE 4927: The Table t1 depends on User Joe
ROLLBACK 3128: DROP failed due to dependencies
DETAIL: Cannot drop User Joe because other objects depend on it
HINT: Use DROP ... CASCADE to drop the dependent objects too
=> DROP USER Joe CASCADE;
DROP USER
=> \dt t1
List of tables
Schema | Name | Kind | Owner | Comment
--------+------+-------+-------+---------
public | t1 | table | SuzyQ |
(1 row)