Configure security cache settings
By default, Hyper-Converged Database (HCD) 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.yamlfile.The location of the
cassandra.yamlfile depends on your installation type:-
Package installations:
/etc/hcd/cassandra/cassandra.yaml -
Tarball installations:
INSTALL_DIRECTORY/resources/cassandra/conf/cassandra.yaml
-
-
Adjust settings in the
cassandra.yamlfile:- roles_update_interval
-
Refresh interval for roles cache, expressed as a duration (for example,
2000ms). 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. Ifroles_validityis non-zero, then this value must also be non-zero. When not set, the default is the same value asroles_validity. - roles_validity
-
Validity period for roles cache, expressed as a duration (for example,
2000ms). 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 using HcdAuthenticator.-
0: Disable role caching. -
Duration (for example,
2000ms): How long to cache the list of roles assigned to the user. -
Default:
2000ms
-
- permissions_validity
-
How long permissions in cache remain valid, expressed as a duration (for example,
2000ms).Fetching permissions can be resource intensive. Set the cache validity period to your security tolerances. The cache is used for the standard authentication. The cache is quite effective at small durations.
-
0: Disable permissions cache. -
Duration (for example,
2000ms): How long permissions remain valid. -
Default:
2000msREVOKE does not automatically invalidate cached permissions. Permissions are invalidated the next time they are refreshed.
-
- permissions_update_interval
-
Refresh interval for the standard authentication cache, expressed as a duration (for example,
2000ms). 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. Ifpermissions_validityis non-zero, the value forroles_update_intervalmust also be non-zero. When not set, the default is the same value aspermissions_validity.Default:
2000ms - permissions_cache_max_entries
-
The maximum number of entries that are held by the standard authentication cache.
Default: 1000 (The standard authentication cache can have up to 1000 entries)
If this option is not present in cassandra.yaml, manually enter it to use a value other than 1000.
Enable auth cache warming
By default, HCD waits until a client connects before loading auth caches.
On a node restart with many clients reconnecting simultaneously, this can cause a burst of cache-miss queries against the system_auth tables, increasing startup latency.
To warm auth caches before the node accepts client connections, set auth_cache_warming_enabled to true in cassandra.yaml:
auth_cache_warming_enabled: trueWhen enabled, HCD populates the roles and permissions caches during startup before opening the native transport port. This reduces authentication latency for the first wave of reconnecting clients after a restart.
Configure native transport rate limiting
To protect the cluster from request overload, HCD can limit the rate of native transport requests processed per second.
When the limit is reached, behavior depends on the THROW_ON_OVERLOAD flag set by the client driver:
-
If
THROW_ON_OVERLOADis enabled, HCD drops the request and returns anOverloadedException. -
If
THROW_ON_OVERLOADis disabled, HCD stops consuming messages from the connection, applying backpressure to the client.
To enable rate limiting, set the following options in cassandra.yaml:
native_transport_rate_limiting_enabled: true
native_transport_max_requests_per_second: 1000000-
native_transport_rate_limiting_enabled: Enables rate limiting for native transport requests. Default:false. -
native_transport_max_requests_per_second: Maximum number of native transport requests to process per second across the node. Default:1000000.
Disable 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=trueAfter setting this option, cache options can be set only in the cassandra.yaml file.
To make the new setting take effect, restart HCD.
