Configuration Options to Disable Optional Functionalities #6

New Issue

MrKalzu · 2025-09-12T22:33:44+03:00

MrKalzu commented

2025-09-12 22:33:44 +03:00

Configuration Options to Disable Optional Functionalities

Problem:
The KVS server currently includes several advanced features (authentication,
tamper-evident logging, clustering, rate limiting, revision history) that might
not be necessary for all deployment scenarios. For instance, a simple,
single-node, internal KVS might not need authentication or clustering,
while a high-performance, write-heavy application might want to disable revision
history to reduce write amplification. Without explicit configuration options to
disable these features, users are forced to run them, potentially incurring
unnecessary overhead or complexity.

Proposed Solution:
Introduce new boolean configuration parameters in the Config struct to enable/disable these features. The server's initialization and request handling logic should then respect these flags.

Disablement Options:

Authentication System (AuthEnabled bool):

    Implementation: Add AuthEnabled bool to Config. In setupRoutes, wrap all authentication-dependent handlers (KV, user, group, token, revision history, backup status) with authMiddleware only if AuthEnabled is true. If AuthEnabled is false, these endpoints would be publicly accessible (or protected by other means, like a reverse proxy).

    Impact:

        Pros: Simplifies setup for trusted, internal-only deployments. Reduces code path complexity and minor runtime overhead.

        Cons: Major security risk if exposed publicly without external authentication. All data and management APIs would be open.

Tamper-Evident Logging (TamperLoggingEnabled bool):

    Implementation: Add TamperLoggingEnabled bool to Config. Modify isActionLogged to return false immediately if TamperLoggingEnabled is false. The createTamperLogEntry and storeTamperLogEntry functions would then effectively become no-ops.

    Impact:

        Pros: Reduces disk I/O and storage consumption. Eliminates the overhead of hashing and JSON marshaling for log entries.

        Cons: No audit trail for data modifications, user/group changes, or authentication failures, making forensic analysis impossible.

Clustering (Gossip & Merkle Sync) (ClusteringEnabled bool):

    Implementation: Add ClusteringEnabled bool to Config. In startBackgroundTasks, wrap the calls to gossipRoutine, syncRoutine, and merkleTreeRebuildRoutine with a check for ClusteringEnabled. The bootstrap function should also check this flag before attempting to join seed nodes.

    Impact:

        Pros: Reduces network traffic and CPU usage associated with cluster communication and Merkle tree calculations. Simplifies deployment for standalone instances.

        Cons: The server will operate as a single, isolated node. No high availability, no automatic data replication, and no eventual consistency with other KVS instances.

Rate Limiting (RateLimitingEnabled bool):

    Implementation: The current implementation already implicitly disables it if RateLimitRequests <= 0. An explicit boolean flag could make it clearer.

    Impact:

        Pros: Reduces overhead for internal services or when external rate limiting is already in place.

        Cons: Vulnerability to abuse or Denial-of-Service attacks if exposed publicly without other protections.

Revision History (RevisionHistoryEnabled bool):

    Implementation: Add RevisionHistoryEnabled bool to Config. Modify storeRevisionHistory to only perform its logic if RevisionHistoryEnabled is true. The getRevisionHistoryHandler and getSpecificRevisionHandler should return a "Feature Disabled" error or an empty response if the feature is off.

    Impact:

        Pros: Saves significant disk space and reduces write amplification, especially for frequently updated keys. Improves write performance.

        Cons: Loses the ability to retrieve or revert to previous versions of data, which can be critical for auditing or data recovery.

Already Implemented (or implicitly handled):

Backup System: Already has BackupEnabled bool in Config and corresponding logic in initializeBackupScheduler.

Compression: Already has CompressionEnabled bool in Config and logic in NewServer, compressData, and decompressData.

Relevant Code Sections:

Config struct for new boolean flags.

defaultConfig function to set default values for new flags.

NewServer for conditional initialization (e.g., clustering routines).

setupRoutes for conditional middleware application (auth, rate limiting).

isActionLogged for tamper logging.

storeRevisionHistory, getRevisionHistoryHandler, getSpecificRevisionHandler for revision history.

# Configuration Options to Disable Optional Functionalities Problem: The KVS server currently includes several advanced features (authentication, tamper-evident logging, clustering, rate limiting, revision history) that might not be necessary for all deployment scenarios. For instance, a simple, single-node, internal KVS might not need authentication or clustering, while a high-performance, write-heavy application might want to disable revision history to reduce write amplification. Without explicit configuration options to disable these features, users are forced to run them, potentially incurring unnecessary overhead or complexity. Proposed Solution: Introduce new boolean configuration parameters in the Config struct to enable/disable these features. The server's initialization and request handling logic should then respect these flags. Disablement Options: Authentication System (AuthEnabled bool): Implementation: Add AuthEnabled bool to Config. In setupRoutes, wrap all authentication-dependent handlers (KV, user, group, token, revision history, backup status) with authMiddleware only if AuthEnabled is true. If AuthEnabled is false, these endpoints would be publicly accessible (or protected by other means, like a reverse proxy). Impact: Pros: Simplifies setup for trusted, internal-only deployments. Reduces code path complexity and minor runtime overhead. Cons: Major security risk if exposed publicly without external authentication. All data and management APIs would be open. Tamper-Evident Logging (TamperLoggingEnabled bool): Implementation: Add TamperLoggingEnabled bool to Config. Modify isActionLogged to return false immediately if TamperLoggingEnabled is false. The createTamperLogEntry and storeTamperLogEntry functions would then effectively become no-ops. Impact: Pros: Reduces disk I/O and storage consumption. Eliminates the overhead of hashing and JSON marshaling for log entries. Cons: No audit trail for data modifications, user/group changes, or authentication failures, making forensic analysis impossible. Clustering (Gossip & Merkle Sync) (ClusteringEnabled bool): Implementation: Add ClusteringEnabled bool to Config. In startBackgroundTasks, wrap the calls to gossipRoutine, syncRoutine, and merkleTreeRebuildRoutine with a check for ClusteringEnabled. The bootstrap function should also check this flag before attempting to join seed nodes. Impact: Pros: Reduces network traffic and CPU usage associated with cluster communication and Merkle tree calculations. Simplifies deployment for standalone instances. Cons: The server will operate as a single, isolated node. No high availability, no automatic data replication, and no eventual consistency with other KVS instances. Rate Limiting (RateLimitingEnabled bool): Implementation: The current implementation already implicitly disables it if RateLimitRequests <= 0. An explicit boolean flag could make it clearer. Impact: Pros: Reduces overhead for internal services or when external rate limiting is already in place. Cons: Vulnerability to abuse or Denial-of-Service attacks if exposed publicly without other protections. Revision History (RevisionHistoryEnabled bool): Implementation: Add RevisionHistoryEnabled bool to Config. Modify storeRevisionHistory to only perform its logic if RevisionHistoryEnabled is true. The getRevisionHistoryHandler and getSpecificRevisionHandler should return a "Feature Disabled" error or an empty response if the feature is off. Impact: Pros: Saves significant disk space and reduces write amplification, especially for frequently updated keys. Improves write performance. Cons: Loses the ability to retrieve or revert to previous versions of data, which can be critical for auditing or data recovery. Already Implemented (or implicitly handled): Backup System: Already has BackupEnabled bool in Config and corresponding logic in initializeBackupScheduler. Compression: Already has CompressionEnabled bool in Config and logic in NewServer, compressData, and decompressData. Relevant Code Sections: Config struct for new boolean flags. defaultConfig function to set default values for new flags. NewServer for conditional initialization (e.g., clustering routines). setupRoutes for conditional middleware application (auth, rate limiting). isActionLogged for tamper logging. storeRevisionHistory, getRevisionHistoryHandler, getSpecificRevisionHandler for revision history.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ryyst/kalzu-value-store#6