Proposal for Redis ACL

[Yangsx-1]

Introduction

ACL (Access Control List) in Redis is a system for managing user authentication and controlling which commands and keys each user can access. Redis introduced ACL support starting from version 6.0.

It enables the creation of multiple users, each with configurable access rights, including which commands they are allowed to execute and which key patterns they are permitted to access. Users can be enabled or disabled, assigned one or more passwords for authentication, and restricted to specific operations and key namespaces.

The ACL system can be configured through the Redis configuration file or dynamically at runtime using dedicated ACL commands.

This feature provides fine-grained access control for multi-tenant or security-sensitive Redis deployments, ensuring users interact only with the commands and data they are explicitly authorized to access.

Key-Value Design

In Redis, user information is stored in the ACL table (within the server.acl struct), while regular keys are stored in the database dictionary. These two belong to separate, independent namespaces and do not interfere with each other. For example, a username can also be a key in Redis. Therefore, to maintain consistent behavior with Redis, ACL users in Kvrocks should be stored within a separate namespace only for ACL command.

Here is the key-value design for ACL user:

                  +----------------------+-------------------+-----------------+----------------+----------------+----------------+-----------------+-----------+
key(username) =>  |  password_hash_len   |  password_hash    |  command_count  |  commandX_len  |    commandX    |  pattern_count |  patternX_len   | patternX  |
                  |       (1byte)        |      (Ebyte)      |     (1byte)     |    (1byte)     |    (Ebyte)     |     (1byte)    |     (1byte)     |  (Ebyte)  |
                  +----------------------+-------------------+-----------------+----------------+----------------+----------------+-----------------+-----------+

For example, here is a typical ACL command in redis:

user alice on >alice123 +get +set ~foo* ~goo*

• user alice: Creates or modifies a user named alice.

• >alice123: Sets the password for the user to alice123.

• +get +set: Grants permission to execute only the GET and SET commands.

• ~foo* ~goo*: Restricts key access to keys matching the patterns foo* and goo*. The user cannot access keys outside these patterns, even if the command itself is permitted.

We can store all of the information using the above encode method:

alice => | password_hash_len | password_hash | command_count(2) | command1_len(3) | command1(get) | command2_len(3) | command2(set) | pattern_count(2) | pattern1_len(4) | pattern1(foo*) | pattern2_len(4) | pattern2(goo*) |

[git-hulk]

@Yangsx-1 Thanks for proposing this.

For the encoding part, I'm wondering if we could reserve a byte to store the version so we can change the format in the future. Others are good to me.

To see if others have any suggestions. cc @apache/kvrocks-committers

[PragmaTwice]

Several questions:

• Which column family should it be stored in?
• How does it interactive with the namespace feature in Kvrocks? One user to one namespace? to all namespace? to selected namespace? how to store this information?
• Is this encoding an efficient one?
• Do we need to call rocksdb GET operation every time we need to check one user's permission? i.e. should we have a cache mechanism besides the block/row cache in rocksdb?
• Should we support more ACL features like +@<category>, +<command>|first-arg, -<command>, pub/sub patterns, more complicated password checks?
• How to extend the design (e.g. to support more features) in the future while compatible to old ACL data?
• Should we just store the ACL rule string in the storage and cache the parsed ACL objects?

cc @mapleFU