Introduction to the new feature ACL of redis 6.0


Introduction to the new feature ACL of redis 6.0


In redis 6.0, ACL (access control list) support was introduced. In previous versions, there was no concept of user in redis. In fact, there was no good way to control permissions. Redis 6.0 began to support users, and each user could be assigned different permissions to control permissions.

Now let’s introduce ACL in redis 6.0. The following example can be tested by running a redis-6.0 container through docker

Run a docker container of redis 6.0

Because I have installed a redis locally, port 6379 has been disabled, so port 16379 is used

docker run -d --name=redis-server-6.0 -p 16379:6379 redis:6.0-alpine

After the creation is successful, you can use redis cli to connect it

I use the local redis cli directly. If I don’t have it locally, I can also use the redis cli inside the docker container,

docker exec -it redis-server-6.0 redis-cli


In the previous version of redis, there was an “auth” command, but the previous version only supported a password, which did not have the concept of a user. As a result, all the clients used the same account to operate redis. Redis 6.0 extended the syntax of auth


It is also compatible with the old version ofAUTH


When using this method, that is, only the password is provided, which is equivalent to using a default user “default”. In this way, low version compatibility is realized


ACL usage scenarios

Before using ACL, you may ask yourself what this function is mainly used for and what it can help me achieve. ACL can help you achieve the following two main goals:

  • The security is improved by limiting the access to commands and keys, so that the untrusted client can not access, and the trusted client can only perform the required work with the lowest access level to the database. For example, some clients may only be able to execute read-only commands,
  • Improve operation security to prevent process or personnel from accessing redis due to software errors or human errors, thus damaging data or configuration. For example, there is no need for staff to call from redisFLUSHALLOrders.

Another typical use of ACL is related to hosting redis instances. Redis is usually a hosted service provided by the internal company team that manages the internal redis infrastructure for other internal customers, or provided by the cloud provider in software as a service settings.
In both settings, we want to make sure that configuration commands are excluded for the customer. In the past, it was a skill to complete this operation by command renaming, which enabled us to survive without ACL for a long time, but the experience was not ideal.

Configure ACL rules through ACL commands

ACL is defined by using DSL (domain specific language), which describes the operations that a given user can perform. Such rules are always enforced from left to right, from first to last, because sometimes the order of rules is important to understand the actual capabilities of users.

By default, there is a user definition called default.

We can use itACL LISTCommand to check the currently enabled ACL rules> ACL LIST
1) "user default on nopass ~* [email protected]"

Parameter Description:

Parameters explain
user user
default Represents the default user name, or a user name defined by yourself
on Indicates whether to enable the user. The default value is off
#… Represents the user password, nopass represents no password required
~* Represents the accessible key (regular matching)
[email protected] Indicates the user’s permission, “+” indicates the authorized permission, has the permission to operate or access, and “-” indicates that there is still no permission; @ is the permission classification, which can be accessed through theACL CATQuery supported categories. [email protected] Represents all permissions, and nocommands represents no command operation permissions

Permissions classify the types of key and command, such as string, hash, list, set, sortedset, and connection, admin, dangerous.
implementACL CATYou can view the list of supported permission categories> ACL CAT
 1) "keyspace"
 2) "read"
 3) "write"
 4) "set"
 5) "sortedset"
 6) "list"
 7) "hash"
 8) "string"
 9) "bitmap"
10) "hyperloglog"
11) "geo"
12) "stream"
13) "pubsub"
14) "admin"
15) "fast"
16) "slow"
17) "blocking"
18) "dangerous"
19) "connection"
20) "transaction"
21) "scripting"

--Returns the command in the specified category
> ACL CAT hash
 1) "hsetnx"
 2) "hset"
 3) "hlen"
 4) "hmget"
 5) "hincrbyfloat"
 6) "hgetall"
 7) "hvals"
 8) "hscan"
 9) "hkeys"
10) "hstrlen"
11) "hget"
12) "hdel"
13) "hexists"
14) "hincrby"
15) "hmset"

Configure user permissions

We can create and modify users in two main ways:

  • Use the ACL command and its ACL setup subcommand.
  • Modify the server configuration (where users can be defined) and restart the server, or if we are using an external serverACLDocuments, you just need to send themACL LOADThat’s it.
+: adds a command to the list of commands that users can call, such as [email protected]
-: removes a command from the list of commands that users can call
[email protected]: add a class of commands, such as: @ admin, @ set, @ hash... To view the specific operation instructions by 'ACL cat'. The special category @ all represents all commands, including those currently in the server and those that will be loaded through the module in the future
[email protected]: similar to + @, delete commands from the list of commands that can be called by the client
+|Subcommand: allow or disable specific subcommands. Note that this form is not allowed to start with "+" like - debug | segfail
allcommands: [email protected] To allow all command operations to be executed. Note that this means that all commands that will be loaded through the module system in the future can be executed.
nocommands: [email protected] Is not allowed to execute all command operations.

useACL SETUSERcommand

First, let’s try the simplestACL SETUSERCommand call:


In the example above, I didn’t specify any rules at all. If the user does not exist, this creates the user using the default property of just created. If the user already exists, the above command will not do anything.

Let’s check the default user status:

1) "user alice off [email protected]"
2) "user default on nopass ~* [email protected]"

The newly created user “Alice” is:

Is off, that is, disabled.AUTHIt will not work.
No commands can be accessed. Note that by default, the user is created by default and cannot access any commands, so [email protected] You can ignore the above output, butACL LISTThe attempt is explicit, not implicit.
Finally, there is no key mode that users can access.
The user did not set a password.

Such users are totally useless. Let’s try to define a user so that it is active, has a password, and can only access key names starting with the string “cached:” using the get command.

> ACL SETUSER alice on >p1pp0 ~cached:* +get

Now, the user can perform some operations, but will refuse to perform other operations without permission:

> AUTH alice p1pp0
> GET foo
(error) NOPERM this user has no permissions to access one of the keys used as arguments
> GET cached:1234
> SET cached:1234 zap
(error) NOPERM this user has no permissions to run the 'set' command or its subcommand

Things went as expected. To check the configuration of user Alice (remember that user names are case sensitive), you can useACL LISTAlternative methods forACL GETUSER

1) "flags"
2) 1) "on"
3) "passwords"
4) 1) "2d9c75..."
5) "commands"
6) "[email protected] +get"
7) "keys"
8) 1) "cached:*"

If we use resp3, the output may be more readable, so we return it as a map reply:

1# "flags" => 1~ "on"
2# "passwords" => 1) "2d9c75..."
3# "commands" => "[email protected] +get"
4# "keys" => 1) "cached:*"

What happens when ACL setup is called more than once

Understanding multiple callsACL SETUSERWhat happens is very important. It’s important to know that everySETUSERThe call does not reset the user, but only applies ACL rules to existing users.
Reset user only if previously unknown:
In this case, the zero ACL will be used to create a new user, that is, the user cannot perform any operation, is disabled, has no password, and so on: for security reasons, the best default value.

However, subsequent calls will only gradually modify the user, so for example, the following order of calls will result inmyuserCan be called at the same timeGETandSET

> ACL SETUSER myuser +set
> ACL SETUSER myuser +get

1) "user default on nopass ~* [email protected]"
2) "user myuser off [email protected] +set +get"

Use externalACLfile

There are two ways to store users in redis configuration. One is to store users in redis configurationredis.confOne is to use an independent external ACL file. The two methods are not compatible and only one can be selected
Generally, external files are more flexible and recommended.

inside redis.conf And the format used in the external ACL file is exactly the same, so it’s easy to switch from one to another

The configuration is as follows:

user  ... acl rules ...

Let’s take an example

user worker [email protected] [email protected] ~jobs:* on >ffa9203c493aa99

When you want to use an external ACL file, you need to specify a configuration directive namedaclfile, as follows:

aclfile /etc/redis/users.acl

If only in redis.conf When several users are directly specified in the file, you can use config rewrite to store the new user configuration in the file by rewriting.

However, external ACL files are more powerful. You can do the following:

  • useACL LOADTo reload an external ACL file, it is usually used when you manually modify the file and want redis to reload. It is important to ensure the correctness of the ACL file content
  • useACL SAVESave the current ACL configuration to an external file


The ACL feature of redis 6.0 brings us a better access control scheme with better security. If you need it, come and experience it