Motivation

Kvrocks currently supports authentication through requirepass and namespace tokens, but it does not support Redis ACL users or fine-grained permission control.

This is something the Kvrocks community has needed for a long time and is eager to have.

This limits Redis compatibility and makes some production scenarios hard to secure, especially:

• read-only replication users
• command-level restrictions
• key-pattern restrictions
• per-user password management
• Redis client compatibility with ACL-aware workflows

Related discussions and issues:

• Support for Redis ACL #2415
• Proposal for Redis ACL #2938
• ACL Proposal #3234
• Proposal: Subcommand as a First-Class Abstraction in Kvrocks Command System #3382
• How to use non-default user for replication #2274

Scope

This tracking issue splits Redis ACL support into smaller sub-issues. The initial goal is not to support every Redis ACL edge case at once, but to build a maintainable foundation that can evolve safely.

High-Level Design Direction

• ACL users are managed by the admin user.
• Each ACL user maps to exactly one Kvrocks namespace.
• ACL data is persisted in storage instead of an external ACL file, so it can participate in replication.
• ACL rules are stored in a Redis-compatible ACL SETUSER rule-string form where practical.
• Runtime permission checks use parsed/cached ACL user objects.
• Command permissions should support command names, categories, and subcommands.
• Key/channel permissions should be enforced through the existing command key extraction path where possible.

Initial Non-Goals

• Do not support deprecated Redis first-argument ACL rules.
• Do not require a full ACL file implementation in the first phase.
• Do not refactor every command family before the ACL foundation lands.
• Do not change public command behavior unrelated to ACL.

Recommended implementation steps

• Finalize ACL semantics and namespace model
• Introduce subcommand as a first-class command abstraction #3517
• Add ACL user model, parser, serializer, and in-memory cache
• Persist and replicate ACL users
• Integrate ACL authentication with AUTH and HELLO AUTH
• Add command and category permission checking
• Add key and channel pattern permission checking
• Implement the initial ACL command set
• Add ACL denial logging and ACL DRYRUN
• Add integration tests against Redis ACL-compatible behavior
• Add documentation and migration notes

Acceptance Criteria

• Kvrocks can create, update, delete, and inspect ACL users.
• A non-admin ACL user can authenticate and is bound to the intended namespace.
• Command/category restrictions are enforced before command execution.
• Key-pattern restrictions are enforced for commands with known key specs.
• Replication can use a restricted ACL user where the required commands are allowed.
• ACL metadata is replicated consistently to replicas.
• Redis client workflows using HELLO ... AUTH default <password> remain compatible.
• Tests cover success and denial paths for authentication, command permissions, key permissions, and replication-sensitive cases.