Redis: Using Access Control List (ACL) part2

Introduction

In the first part with have seen what are Redis ACL and why we are using it.WE also have seen how to list users with the ACL LIST command.

Let’s continue and go deeper with command usage and also how to use an external file.

So let’s go for Redis ACL part two !

Multiple calls to ACL SETUSER

When ACL SETUSER is called multiple times every ACL SETUSER call will NOT reset the user, but will just apply incrementally the ACL rules to the existing user.

The user is reset only if it was not known before, it cannot do anything, is disallowed, has no passwords, and so forth. This is the best default for safety

• Below an example of ACL rights incremental method:

We can see that the command add SET rights and GET rights , in that order because sometimes order can have its importance when configuring ACL for a user.

You also notice that there is the off option which means user is disabled so we will turn it on.

So to sum up you can now call both SET and GET commands for that user.

Command categories

Now we know how to add rights but there are many commands so it can be fastidious to add it one by one.why not use directly the command categories ?

First of all we will list the command categories which include a bunch of common command like get but also it can include critical commands.

The following is a list of command categories and their meanings:

• admin – Administrative commands. Normal applications will never need to use these. Includes REPLICAOF, CONFIG, DEBUG, SAVE, MONITOR, ACL, SHUTDOWN, etc.
• bitmap – Data type: bitmaps related.
• blocking – Potentially blocking the connection until released by another command.
• connection – Commands affecting the connection or other connections. This includes AUTH, SELECT, COMMAND, CLIENT, ECHO, PING, etc.
• dangerous – Potentially dangerous commands (each should be considered with care for various reasons). This includes FLUSHALL, MIGRATE, RESTORE, SORT, KEYS, CLIENT, DEBUG, INFO, CONFIG, SAVE, REPLICAOF, etc.
• geo – Data type: geospatial indexes related.
• hash – Data type: hashes related.
• hyperloglog – Data type: hyperloglog related.
• fast – Fast O(1) commands. May loop on the number of arguments, but not the number of elements in the key.
• keyspace – Writing or reading from keys, databases, or their metadata in a type agnostic way. Includes DEL, RESTORE, DUMP, RENAME, EXISTS, DBSIZE, KEYS, EXPIRE, TTL, FLUSHALL, etc. Commands that may modify the keyspace, key, or metadata will also have the write category. Commands that only read the keyspace, key, or metadata will have the read category.
• list – Data type: lists related.
• pubsub – PubSub-related commands.
• read – Reading from keys (values or metadata). Note that commands that don’t interact with keys, will not have either read or write.
• scripting – Scripting related.
• set – Data type: sets related.
• sortedset – Data type: sorted sets related.
• slow – All commands that are not fast.
• stream – Data type: streams related.
• string – Data type: strings related.
• transaction – WATCH / MULTI / EXEC related commands.
• write – Writing to keys (values or metadata).

Below you will have an example of a user with a restriction to the blocking category

When using +@all command it will allow all commands , then you can restrict the category you want jsut after like @Blocking commands or @dangerous commands .

List the command categories

Use the ACL CAT command to list all the categories

List the sub-commands

Now you have identified the categories you can list them and see the sub-commands inside

Use the command

ACL CAT [ categoryname ]

This example lists the sub-commands within the dangerous category

Inside there is common but critical commands such as KEYS, SAVE, RESTORE, ACL commands BUT ALSO THE FLUSHALL command , I guess it should be only dedicated to the Redis admin.

Aim is to get the Redis infra secure by avoiding blocking or dangerous commands, indeed it can slow the server or even worse harm it and delete data.

Allow/block subcommands

Starting from Redis 7.0 version , subcommands can be allowed/blocked just like other commands (by using the separator | between the command and subcommand, for example: +config|get or -config|set)

That is true for all commands except DEBUG. In order to allow/block specific DEBUG sub-commands

My current configuration doesn’t allow me to give examples as I am on Redis 6 but I will upgrade and show it in another incoming post 🙂

Allow the first-arg of a blocked command

Note that this feature is deprecated since Redis 7.0 and may be removed in the future.

( I am on Redis 6 version so we can test the command )

Exclude or include a command or a subcommand as a whole may find some limits. For example many deployments may not be happy providing the ability to execute a SELECT for any DB, but may still want to be able to run SELECT 0.

Example:

We could alter the ACL of a user as the following way

ACL SETUSER myuser -select +select|0

This command will remove the SELECT command and then add the allowed first-arg.

Note that it is not possible to do the reverse since first-args can be only added, not excluded.

Best practice for more security is to specify all the first-args that are valid for some user since it is possible that new first-args may be added in the future.

Selectors

I will upgrade my Redis to 7.0 and test it in another post , for teh moment you can get the definition and method to understand the principle below ( from the Redis site )

“Starting with Redis 7.0, Redis supports adding multiple sets of rules that are evaluated independently of each other. These secondary sets of permissions are called selectors and added by wrapping a set of rules within parentheses. In order to execute a command, either the root permissions (rules defined outside of parenthesis) or any of the selectors (rules defined inside parenthesis) must match the given command. Internally, the root permissions are checked first followed by selectors in the order they were added.

For example, consider a user with the ACL rules +GET ~key1 (+SET ~key2). This user is able to execute GET key1 and SET key2 hello, but not GET key2 or SET key1 world.”

Key permissions

Need Redis 7.0 version minimum so it will be discussed during a next post 🙂

Passwords storage method

SHA256 is the method to store internally Redis hashed passwords .

When you check your password by using ACL LIST or ACL GETUSER, you’ll see a long hex string that looks pseudo random.

Example:

Using SHA256 provides the ability to avoid storing the password in clear text while still allowing for a very fast AUTH command, which is a very important feature of Redis and is coherent with what clients expect from Redis.

Note that “ACL passwords are not really passwords. They are shared secrets between the server and the client, because the password is not an authentication token used by a human being”.

For instance:

• There are no length limits, the password will just be memorized in some client software. There is no human that needs to recall a password in this context.
• The ACL password does not protect any other thing. For example, it will never be the password for some email account.
• Often when you are able to access the hashed password itself, by having full access to the Redis commands of a given server, or corrupting the system itself, you already have access to what the password is protecting: the Redis instance stability and the data it contains.

Security matters

For the above reasons, slowing down the password authentication, in order to use an algorithm that uses time and space to make password cracking hard, is a very poor choice.

We can instead generate strong passwords, so that nobody will be able to crack it using a dictionary or a brute force attack even if they have the hash.

To perform that we can use the ACL command ACL GENPASS that generates passwords using the system cryptographic pseudorandom generator:

Syntax:

127.0.0.1:6379> ACL GENPASS [ bits ]

Example:

By default this command outputs a 32-byte (256-bit) pseudorandom string converted to a 64-byte alphanumerical string but you can add the bit number as an argument like above 128 bits

This password complexity is enough to avoid bruteforce attacks and short enough to be easy to manage, cut & paste, store, and so forth.

This is the recommended method you should use in order to generate Redis passwords.

Use an external ACL file

We got 2 methods to store Redis users :

• First is to specify them directly in the redis.conf file.
• The second is to specify an external ACL file.

As these two options can’t work together, You will have to make your choice.

1st choice: Use redis.conf file

For simple use cases it is the best choice.

2nd choice: Use the ACL file

Use the ACL file when there are multiple users to define, in a complex environment.

User definition format in redis.conf and external ACL file:

redis.conf and in the external ACL file use exactly the same format to define users:

user [username] acl rules …

Example:

"user USER_RESTRICTED on #e198a9a8a4a2a5be789e9a11ecf8a48b9f2ed6a2293c99d56d31c74f3d1c43c8 ~* &* +@all -@blocking"

When you want to use an external ACL file, you must specify the configuration directive called aclfile, by adding the absolute path of the file.

127.0.0.1:6379> aclfile /etc/redis/users.acl

When you are just specifying a few users directly inside the redis.conf file, you can use CONFIG REWRITE in order to store the new user configuration inside the file by rewriting it.

The external ACL file has more capabilities and allow you useful commands such as ACL LOAD /SAVE.

You can do the following:

• Use ACL LOAD if you modified the ACL file manually and you want Redis to reload the new configuration. Note that this command is able to load the file only if all the users are correctly specified. Otherwise, an error is reported to the user, and the old configuration will remain valid.
• Use ACL SAVE to save the current ACL configuration to the ACL file.

Note that CONFIG REWRITE does not also trigger ACL SAVE. When you use an ACL file, the configuration and the ACLs are handled separately.

Conclusion

That conclude the Redis ACL part.The secutrity topic is huge and we will probably come bakc to it another time.

Thanks to the Redis site which is fantastic and well documented.

Feel free to take a look on it and also don’t forget to visit my other topics here and the dbi bloggers here .