Configuring Cache Settings
By default, DataStax Enterprise (DSE) caches the login user’s roles and corresponding permissions.
Caching allows multiple connection requests to occur within the specified period without repeating the entire authorization process (querying the system_auth
tables) for every action.
Security-related cache settings
-
Locate the
cassandra.yaml
file. The location of this file depends on the type of installation:-
Package installations:
/etc/dse/cassandra/cassandra.yaml
-
Tarball installations:
<installation_location>/resources/cassandra/conf/cassandra.yaml
-
-
Adjust settings in the
cassandra.yaml
file:- roles_validity_in_ms
-
Validity period for roles cache in milliseconds. Determines how long to cache the list of roles assigned to the user; users may have several roles, either through direct assignment or inheritance (a role that has been granted to another role). Adjust this setting based on the complexity of your role hierarchy, tolerance for role changes, the number of nodes in your environment, and activity level of the cluster.
Fetching permissions can be an expensive operation, so this setting allows flexibility. Granted roles are cached for authenticated sessions in
AuthenticatedUser
. After the specified time elapses, role validity is rechecked. Disabled automatically when internal authentication is not enabled when usingDseAuthenticator
.-
0 - Disable role caching
-
milliseconds - how long to cache the list of roles assigned to the user
Default:
120000
(2 minutes) -
- roles_update_interval_in_ms
-
Refresh interval for roles cache. After this interval, cache entries become eligible for refresh. On next access, the database schedules an async reload, and returns the old value until the reload completes. If
roles_validity_in_ms
is non-zero, then this value must also be non-zero. When not set, the default is the same value asroles_validity_in_ms
. -
Default:
120000
- permissions_validity_in_ms
-
How long permissions in cache remain valid to manage performance impact of permissions queries. Fetching permissions can be resource intensive. Set the cache validity period to your security tolerances. The cache is used for the standard authentication and the row-level access control (RLAC) cache. The cache is quite effective at small durations.
-
0
- Disable permissions cache. -
milliseconds
- Time that permissions in cache remain valid.
-
|
-
Default:
120000
(2 minutes) - permissions_update_interval_in_ms
-
Refresh interval for the standard authentication cache and the row-level access control (RLAC) cache. After this interval, cache entries become eligible for refresh. On next access, the database schedules an async reload and returns the old value until the reload completes. If
permissions_validity_in_ms
is non-zero, the value forroles_update_interval_in_ms
must also be non-zero. When not set, the default is the same value as permissions_validity_in_ms.Default:
2000
- permissions_cache_max_entries
-
The maximum number of entries that are held by the standard authentication cache and row-level access control (RLAC) cache. With the default value of
1000
, the RLAC permissions cache can have up to 1000 entries in it, and the standard authentication cache can have up to 1000 entries. This single option applies to both caches. To size the permissions cache for use with Setting up Row Level Access Control (RLAC), use this formula:numRlacUsers * numRlacTables + 100
If this option is not present in the
cassandra.yaml
configuration file, manually enter it to use a value other than1000
. See Enabling DSE Unified Authentication.Default:
1000
Disabling Authentication and Authorization caching
To disable configuration of authorization caches (for roles and permissions), uncomment the following line in the jvm-server.options
file:
-Dcassandra.disable_auth_caches_remote_configuration=true
After setting this option, cache
options can be set only in the cassandra.yaml
file.
To make the new setting take effect, restart Cassandra.