Introduction to the new feature ACL of redis 6.0
Intro
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-alpineAfter 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
AUTH
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
AUTHIt is also compatible with the old version ofAUTH
AUTHWhen 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
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 redis
FLUSHALLOrders.
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
127.0.0.1:6379> 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
127.0.0.1:6379> 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 server
ACLDocuments, 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:
> ACL SETUSER alice
OKIn 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:
> ACL LIST
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
OKNow, the user can perform some operations, but will refuse to perform other operations without permission:
> AUTH alice p1pp0
OK
> GET foo
(error) NOPERM this user has no permissions to access one of the keys used as arguments
> GET cached:1234
(nil)
> SET cached:1234 zap
(error) NOPERM this user has no permissions to run the 'set' command or its subcommandThings went as expected. To check the configuration of user Alice (remember that user names are case sensitive), you can useACL LISTAlternative methods forACL GETUSER
> ACL GETUSER alice
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:
> ACL GETUSER alice
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
OK
> ACL SETUSER myuser +get
OK
> ACL LIST
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 >ffa9203c493aa99When you want to use an external ACL file, you need to specify a configuration directive namedaclfile, as follows:
aclfile /etc/redis/users.aclIf 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:
- use
ACL 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 - use
ACL SAVESave the current ACL configuration to an external file
More
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