THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Code Block | ||
|---|---|---|
| ||
# CIDR authorization backend, implementing ICIDRAuthorizer; used to restrict user
# access from certain CIDRs
# Out of the box, Cassandra provides org.apache.cassandra.auth.{AllowAllCIDRAuthorizer,
# CassandraCIDRAuthorizer}.
# - AllowAllCIDRAuthorizer allows access from any CIDR to any user - set it to disable CIDR authorization.
# - CassandraCIDRAuthorizer stores user's CIDR permissions in system_auth.cidr_permissions table. Please
# increase system_auth keyspace replication factor if you use this authorizer, otherwise any changes to
# system_auth tables being used by this feature may be lost when a host goes down.
cidr_authorizer:
class_name: AllowAllCIDRAuthorizer
# Below parameters are used only when CIDR authorizer is enabled
# parameters:
# CIDR authorizer when enabled, i.e, CassandraCIDRAuthorizer, is applicable for non-superusers only by default.
# Set this setting to true, to enable CIDR authorization for superusers as well.
# Note: CIDR checks cannot be performed for JMX calls
# cidr_checks_for_superusers: true
# CIDR authorizer when enabled, supports MONITOR and ENFORCE modes. Default mode is MONITOR
# In MONITOR mode, CIDR checks are NOT enforced. Instead, CIDR groups of users accesses are logged using
# nospamlogger. A warning message would be logged if a user accesses from unauthorized CIDR group (but access won't
# be rejected). An info message would be logged otherwise.
# In ENFORCE mode, CIDR checks are enforced, i.e, users accesses would be rejected if attempted from unauthorized
# CIDR groups.
# cidr_authorizer_mode: MONITOR
# Refresh interval for CIDR groups cache, this value is considered in minutes
# cidr_groups_cache_refresh_interval: 5
# Maximum number of entries an IP to CIDR groups cache can accommodate
# ip_cache_max_size: 100 |
New CQL data type - CIDR
...
| Code Block |
|---|
CREATE TABLE system_auth.cidr_groups (
cidr_group text PRIMARY KEY,
cidrs_list frozen<set<tuple<inet, smallint>>>
) |
After introducing the new CQL data type CIDR, we will modify the code to create a new table with new data type. Schema of the table after introducing new data type would be as below.
| Code Block |
|---|
CREATE TABLE system_auth.cidr_groups_mapping (
cidr_group text PRIMARY KEY,
cidrs_list frozen<set<CIDR>>
) |
After this data type change, we can either migrate the data from the old table to the new table, or populate the new table with mappings and discard the old table. Assuming this table usually contains tens to hundreds records (usually an organization’s CIDR groups to CIDRs mapping records are very few), this migration shouldn’t be a problem.
Compatibility, Deprecation, and Migration Plan
...
- Unit tests added to test the new and changed code
- Ran Cassandra server with CIDR filtering disabled and tested no change in existing behavior
- Ran Cassandra server with CIDR filtering enabled, populated CIDR groups mappings, created users with different CIDR permissions and tested users accesses. Verified CIDR authorizer working as expected
- Developed JMH benchmark to measure impact of CIDR authorizer on Cassandra server authorization latency (Please see Benchmarks section)
- Plan is to run Cassandra upgrade test, from older version to new version with this feature and ensure no change in the functionality for existing usersClients to C* server compatibility testing will be done after introducing new CQL data type CIDR.
Benchmarks
Below are results of benchmark of CIDR authorizer in ENFORCE mode (measured using JMH benchmark test on single C* instance). This score indicates additional nanoseconds to the current latency during C* server authorization path, when CIDR authorizer is enabled.
...