ACL （前交叉韧带）

Redis 访问控制列表

Redis ACL 是 Access Control List 的缩写，是允许某些 连接，以限制可执行的命令和 可以访问的键。它的工作原理是，在连接后，客户端 需要提供用户名和有效密码才能进行身份验证。如果身份验证成功，则连接将与给定的 user 和用户拥有的限制。Redis 可以配置为新的 连接已使用“默认”用户（即 default configuration）的 S Mc.配置默认用户具有副作用 能够仅向 Connections 提供特定的功能子集 未明确进行身份验证。

在默认配置中，Redis 6（第一个具有 ACL 的版本）有效 与旧版本的 Redis 完全相同。每个新连接都是 能够调用所有可能的命令并访问每个 key，因此 ACL 功能向后兼容旧客户端和应用程序。也 使用 requirePass 配置密码的旧方法 指令，仍会按预期工作。然而，它现在 为默认用户设置密码。

雷迪斯AUTH命令在 Redis 6 中进行了扩展，因此现在可以 以两个参数的形式使用它：

AUTH <username> <password>

下面是旧形式的一个示例：

AUTH <password>

发生的情况是用于身份验证的用户名是 “default”，因此 仅指定密码意味着我们要进行身份验证 默认用户。这提供了向后兼容性。

当 ACL 有用时

在使用 ACL 之前，您可能需要问问自己，您想要的目标是什么 通过实施此保护层来实现。通常有 ACL 很好地实现了两个主要目标：

1. 您希望通过限制对命令和密钥的访问来提高安全性，以便不受信任的客户端没有访问权限，而受信任的客户端仅具有执行所需工作所需的数据库的最低访问级别。例如，某些客户端可能只能执行只读命令。
2. 您希望提高作安全性，以便不允许访问 Redis 的进程或人员因软件错误或手动错误而损坏数据或配置。例如，从 Redis 获取延迟作业的工作程序没有理由能够调用FLUSHALL命令。

ACL 的另一种典型用法与托管 Redis 实例有关。Redis 是 通常由处理 他们拥有的其他内部客户的 Redis 基础设施，或者是 在云提供商的软件即服务设置中提供。在两者中 setups，我们希望确保 客户。

使用 ACL 命令配置 ACL

ACL 是使用 DSL（域特定语言）定义的，该语言描述了 允许给定用户执行此作。此类规则始终从 从第一个到最后一个，从左到右，因为有时规则的顺序是 了解用户真正能够做什么很重要。

默认情况下，有一个用户定义的用户，称为 default。我们 可以使用ACL LIST命令以检查当前活动的 ACL 并验证新启动的 defaults-configured 的 Redis 实例为：

> ACL LIST
1) "user default on nopass ~* &* +@all"

上面的命令以相同的格式报告用户列表，即 在 Redis 配置文件中使用，通过转换当前 ACL 集 对于用户返回到其描述中。

每行中的前两个单词是 “user” 后跟 username。这 接下来的单词是描述不同事物的 ACL 规则。我们将详细展示规则的工作原理，但现在只需说默认的 用户配置为 active （on）、不需要密码 （nopass）、to 访问所有可能的键 （） 和 Pub/Sub 频道 （），并能够 调用所有可能的命令 （~*&*+@all).

此外，在默认用户的特殊情况下，具有 nopass 规则意味着 新连接会自动使用默认用户进行身份验证 没有任何显式的AUTH需要打电话。

ACL 规则

以下是有效 ACL 规则的列表。某些规则只是 用于激活或删除标志的单个单词，或者用于 对用户 ACL 执行给定的更改。其他规则是 char 前缀，这些 与命令或类别名称、键模式和 等等。

启用和禁止用户：

• on：启用用户：可以以此用户身份进行身份验证。
• off：不允许该用户：无法再使用此用户进行身份验证;但是，以前经过身份验证的连接仍将有效。请注意，如果默认用户被标记为 off，则新连接将以未验证状态开始，并要求用户发送AUTH或HELLO使用 AUTH 选项进行身份验证，以便以某种方式进行身份验证，而不管默认用户配置如何。

允许和禁止命令：

• +<command>：将命令添加到用户可以调用的命令列表中。可与|允许子命令（例如 “+config|get”）。
• -<command>：将命令删除到用户可以调用的命令列表中。从 Redis 7.0 开始，它可以与|用于阻止子命令（例如 “-config|set”）。
• +@<category>：添加该类别中要由用户调用的所有命令，有效类别为 @admin、@set、@sortedset 等依此类推，通过调用ACL CAT命令。特殊类别 @all 表示所有命令，包括当前存在于服务器中的命令，以及将来将通过模块加载的命令。
• -@<category>：喜欢+@<category>但会从客户端可以调用的命令列表中删除命令。
• +<command>|first-arg：允许其他禁用的命令的特定第一个参数。它仅在没有子命令的命令上受支持，并且不允许作为 -SELECT|1 等否定形式，只能以 “+” 开头的加法形式。此功能已弃用，将来可能会删除。
• allcommands：+@all 的别名。请注意，它意味着能够执行通过 modules 系统加载的所有未来命令。
• nocommands：-@all 的别名。

允许和禁止某些键和键权限：

• ~<pattern>：添加可以作为命令的一部分提及的键模式。例如，允许所有键。该模式是 glob 样式的模式，类似于~*KEYS.可以指定多个模式。
• %R~<pattern>：（在 Redis 7.0 及更高版本中提供）添加指定的读取键模式。这类似于常规键模式，但仅授予从与给定模式匹配的键中读取的权限。有关更多信息，请参阅密钥权限。
• %W~<pattern>：（Redis 7.0 及以上版本提供）添加指定的写键模式。这类似于常规密钥模式，但仅授予写入与给定模式匹配的密钥的权限。有关更多信息，请参阅密钥权限。
• %RW~<pattern>：（在 Redis 7.0 及更高版本中可用）别名~<pattern>.
• allkeys：的别名。~*
• resetkeys：刷新允许的键模式列表。例如，ACL~foo:* ~bar:* resetkeys ~objects:*将只允许客户端访问与模式匹配的密钥objects:*.

允许和禁止 Pub/Sub 渠道：

• &<pattern>：（在 Redis 6.2 及更高版本中可用）添加用户可访问的 Pub/Sub 渠道的 glob 样式模式。可以指定多个通道模式。请注意，模式匹配仅对PUBLISH和SUBSCRIBE而PSUBSCRIBE要求其通道模式与 User 允许的通道模式之间的文本匹配。
• allchannels：允许用户访问所有 Pub/Sub 渠道的别名。&*
• resetchannels：刷新允许的频道模式列表，并断开用户的 Pub/Sub 客户端（如果这些客户端无法再访问其各自的频道和/或频道模式）。

为用户配置有效密码：

• ><password>：将此密码添加到用户的有效密码列表中。例如>mypass会将 “mypass” 添加到有效密码列表中。此指令清除 nopass 标志（请参阅后面）。每个用户都可以拥有任意数量的密码。
• <<password>：从有效密码列表中删除此密码。如果您尝试删除的密码实际上未设置，则发出错误。
• #<hash>：将此 SHA-256 哈希值添加到用户的有效密码列表中。此哈希值将与为 ACL 用户输入的密码的哈希值进行比较。这允许用户在acl.conf文件，而不是存储明文密码。仅接受 SHA-256 哈希值，因为密码哈希必须为 64 个字符，并且仅包含小写十六进制字符。
• !<hash>：从有效密码列表中删除此哈希值。当您不知道哈希值指定的密码，但想要删除用户的密码时，这非常有用。
• nopass：删除用户的所有设置密码，并将用户标记为不需要密码：这意味着每个密码都将对该用户起作用。如果此指令用于 default 用户，则每个新连接将立即使用 default 用户进行身份验证，而无需任何显式的 AUTH 命令。请注意，resetpass 指令将清除此条件。
• resetpass：刷新允许的密码列表并删除 nopass 状态。在 resetpass 之后，用户没有关联的密码，如果不添加一些密码（或稍后将其设置为 nopass），则无法进行身份验证。

注意：如果用户没有使用 nopass 进行标记，并且没有有效密码列表，则该用户实际上是不可能的，因为无法以该用户身份登录。

为用户配置选择器：

• (<rule list>)：（在 Redis 7.0 及更高版本中可用）创建一个新选择器以匹配规则。选择器在用户权限之后进行评估，并根据其定义的顺序进行评估。如果命令与用户权限或任何选择器匹配，则允许该命令。有关更多信息，请参阅 选择器 。
• clearselectors：（在 Redis 7.0 及更高版本中可用）删除附加到用户的所有选择器。

重置用户：

• reset执行以下作：resetpass、resetkeys、resetchannels、allchannels（如果设置了 acl-pubsub-default）、off、clearselectors、-@all。用户将返回到创建后立即出现的相同状态。

使用 ACL SETUSER 命令创建和编辑用户 ACL

可以通过两种主要方式创建和修改用户：

1. 使用 ACL 命令及其ACL SETUSER子命令。
2. 修改服务器配置（可在其中定义用户），然后重新启动服务器。使用外部 ACL 文件，只需调用ACL LOAD.

在本节中，我们将学习如何使用ACL命令。 有了这些知识，通过 配置文件。在配置中定义用户应该有自己的 部分，稍后将单独讨论。

首先，尝试最简单的ACL SETUSER命令调用：

> ACL SETUSER alice
OK

这ACL SETUSERcommand 获取用户名和要应用的 ACL 规则列表 给用户。但是，上面的示例根本没有指定任何规则。 如果用户不存在，这将只创建用户，并使用 new 的默认值 用户。如果用户已经存在，则上面的命令将不执行任何作。

检查默认用户状态：

> ACL LIST
1) "user alice off resetchannels -@all"
2) "user default on nopass ~* &* +@all"

新用户 “alice” 是：

• 在 off 状态下，因此AUTH对用户 “alice” 不起作用。
• 用户也没有设置密码。
• 无法访问任何命令。请注意，默认情况下，该用户是创建的，无法访问任何命令，因此-@all在上面的输出中可以省略;然而ACL LIST尝试明确而不是隐含。
• 用户无法访问任何密钥模式。
• 用户无法访问 Pub/Sub 频道。

默认情况下，新用户是使用限制性权限创建的。从 Redis 6.2 开始，ACL 还提供 Pub/Sub 通道访问管理。为了确保在升级到 Redis 6.2 时与版本 6.0 的向后兼容性，默认情况下会向新用户授予“allchannels”权限。默认值可以设置为resetchannels通过acl-pubsub-defaultconfiguration 指令。

从 7.0 开始，acl-pubsub-default值设置为resetchannels默认限制 channels 访问，以提供更好的安全性。 默认值可以设置为allchannels通过acl-pubsub-defaultconfiguration 指令与以前的版本兼容。

这样的用户完全没用。让我们尝试定义用户，以便 它是活动的，有密码，并且只能使用GET命令 设置为以字符串 “cached：” 开头的键名称。

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

现在用户可以做某事，但会拒绝做其他事情：

> 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

一切按预期进行。为了检查 用户 alice（请记住，用户名区分大小写），则可以 使用 替代项ACL LIST它的设计更适合 computers 进行读取，而ACL GETUSER更易读。

> ACL GETUSER alice
1) "flags"
2) 1) "on"
3) "passwords"
4) 1) "2d9c75..."
5) "commands"
6) "-@all +get"
7) "keys"
8) "~cached:*"
9) "channels"
10) ""
11) "selectors"
12) (empty array)

这ACL GETUSER返回一个字段值数组，该数组以更可解析的术语描述用户。输出包括标志集、密钥模式列表、密码等。如果我们使用 RESP3，输出可能更具可读性，因此它作为 map 回复返回：

> ACL GETUSER alice
1# "flags" => 1~ "on"
2# "passwords" => 1) "2d9c75273d72b32df726fb545c8a4edc719f0a95a6fd993950b10c474ad9c927"
3# "commands" => "-@all +get"
4# "keys" => "~cached:*"
5# "channels" => ""
6# "selectors" => (empty array)

注意：从现在开始，我们将继续使用 Redis 默认协议版本 2

使用另一个ACL SETUSER命令（因为 Alice 无法运行ACL命令），我们可以向用户添加多个模式：

> ACL SETUSER alice ~objects:* ~items:* ~public:*
OK
> ACL LIST
1) "user alice on #2d9c75... ~cached:* ~objects:* ~items:* ~public:* resetchannels -@all +get"
2) "user default on nopass ~* &* +@all"

内存中的用户表示形式现在符合我们的预期。

多次调用 ACL SETUSER

了解何时会发生什么非常重要ACL SETUSER称为 多次。关键是要知道，每个ACL SETUSERcall 将 不会重置用户，而只会将 ACL 规则应用于现有用户。 仅当以前不知道用户时，才会重置用户。在这种情况下，一个全新的 user 是使用 zeroed-ACL 创建的。用户无法执行任何作，即 disallowed、没有密码，等等。这是安全性的最佳默认值。

但是，稍后的调用只会以增量方式修改用户。例如 以下序列：

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

将导致 myuser 能够同时调用GET和SET:

> ACL LIST
1) "user default on nopass ~* &* +@all"
2) "user myuser off resetchannels -@all +get +set"

命令类别

通过依次指定所有命令来设置用户 ACL 是 真的很烦人，所以我们反而做这样的事情：

> ACL SETUSER antirez on +@all -@dangerous >42a979... ~*

通过说 +@all 和 -@dangerous，我们包含了所有命令，后来又删除了 Redis 命令表中标记为危险的所有命令。 请注意，命令类别从不包含 modules 命令 +@all 例外。如果你说 +@all，所有命令都可以由 用户，甚至是通过 Modules 系统加载的未来命令。但是，如果您 使用 ACL 规则 +@read 或任何其他规则，则 modules 命令始终为 排除。这非常重要，因为您应该只信任 Redis 内部命令表。模块可能会暴露危险的东西，并在 ACL 的情况只是累加的，即以+@all -...你应该绝对确保你永远不会包含你不想要的内容 自。

以下是命令类别及其含义的列表：

• admin - 管理命令。普通应用程序永远不需要使用 这些。包括REPLICAOF,CONFIG,DEBUG,SAVE,MONITOR,ACL,SHUTDOWN等。
• bitmap - 数据类型：与位图相关。
• blocking - 可能阻止连接，直到被另一个人释放 命令。
• connection - 影响连接或其他连接的命令。 这包括AUTH,SELECT,COMMAND,CLIENT,ECHO,PING等。
• dangerous - 具有潜在危险的命令（每个命令都应谨慎考虑 各种原因）。这包括FLUSHALL,MIGRATE,RESTORE,SORT,KEYS,CLIENT,DEBUG,INFO,CONFIG,SAVE,REPLICAOF等。
• geo - 数据类型：与地理空间索引相关。
• hash - 数据类型：与哈希相关。
• hyperloglog - 数据类型：hyperloglog 相关。
• fast - Fast O（1） 命令。可以循环参数的数量，但不能循环 键中的元素数。
• keyspace - 从键、数据库或其元数据中写入或读取 以一种类型不可知的方式。包括DEL,RESTORE,DUMP,RENAME,EXISTS,DBSIZE,KEYS,EXPIRE,TTL,FLUSHALL等。可以修改键空间的命令， 键，或者元数据也将具有write类别。仅读取 keyspace、key 或 metadata 将具有read类别。
• list - 数据类型：列出相关。
• pubsub - 与 PubSub 相关的命令。
• read - 从键（值或元数据）读取。请注意，不执行 与 keys 交互，都不会有read或write.
• scripting - 与脚本相关。
• set - 数据类型：sets related。
• sortedset - 数据类型：与排序集相关。
• slow - 所有不是的命令fast.
• stream - 数据类型：与流相关。
• string - 数据类型：字符串相关。
• 交易 - WATCH / MULTI / EXECrelated commands.
• write - 写入键（值或元数据）。

Redis 还可以使用 Redis 向您显示所有类别的列表以及每个类别包含的确切命令ACL CAT命令。它可以以两种形式使用：

ACL CAT -- Will just list all the categories available
ACL CAT <category-name> -- Will list all the commands inside the category

例子：

 > 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"

如您所见，到目前为止有 21 个不同的类别。现在让我们看看 command 是 geo 类别的一部分：

 > ACL CAT geo
 1) "geohash"
 2) "georadius_ro"
 3) "georadiusbymember"
 4) "geopos"
 5) "geoadd"
 6) "georadiusbymember_ro"
 7) "geodist"
 8) "georadius"
 9) "geosearch"
10) "geosearchstore"

请注意，命令可能是多个类别的一部分。例如， ACL 规则，如+@geo -@read将导致某些 geo 命令为 excluded，因为它们是只读命令。

允许/阻止子命令

从 Redis 7.0 开始，可以像其他命令一样允许/阻止子命令 命令（通过使用分隔符|在命令和子命令之间，对于 例：+config|get或-config|set)

除了 DEBUG 之外的所有命令都是如此。为了允许/阻止特定 DEBUG 子命令，请参阅下一节。

允许被阻止的命令的 first-arg

注意：此功能自 Redis 7.0 起已弃用，将来可能会删除。

有时，仅能排除或包含命令或子命令作为整体的能力是不够的。 许多部署可能不愿意提供执行SELECT对于任何 DB，但可以 仍然希望能够运行SELECT 0.

在这种情况下，我们可以通过以下方式更改用户的 ACL：

ACL SETUSER myuser -select +select|0

首先，删除SELECT命令，然后添加允许的 first-arg 的请注意，由于 first-args 只能添加，不能排除。指定所有 first-args 更安全 对某些用户有效，因为 将来可能会添加新的 first-args。

另一个例子：

ACL SETUSER myuser -debug +debug|digest

请注意，first-arg 匹配可能会增加一些性能损失;但是，即使使用综合基准测试也很难衡量。这 额外的 CPU 成本仅在调用此类命令时支付，而不是 调用其他命令。

可以使用此机制来允许 Redis 中的子命令 7.0 之前的版本（请参阅上一节）。

+@all VS -@all

在上一节中，观察到如何定义 command 基于添加 / 删除单个命令的 ACL。

选择

从 Redis 7.0 开始，Redis 支持添加多组规则，这些规则彼此独立地进行评估。 这些辅助权限集称为选择器，并通过将一组规则括在括号内来添加。 要执行命令，root 权限（在括号外定义的规则）或任何选择器（在括号内定义的规则）必须与给定的命令匹配。 在内部，首先检查 root 权限，然后按添加顺序检查 selector。

例如，假设用户具有 ACL 规则+GET ~key1 (+SET ~key2). 此用户能够执行GET key1和SET key2 hello，但不是GET key2或SET key1 world.

与用户的 root 权限不同，选择器在添加后无法修改。 相反，可以使用clearselectorskeyword，这将删除所有添加的选择器。 请注意，clearselectors不会删除 root 权限。

密钥权限

从 Redis 7.0 开始，键模式还可用于定义命令如何接触键。 这是通过定义密钥权限的规则实现的。 关键权限规则采用%(<permission>)~<pattern>. 权限定义为映射到以下关键权限的单个字符：

• W （Write）：密钥中存储的数据可能会被更新或删除。
• R （Read）：处理、复制或返回用户从密钥提供的数据。请注意，这不包括元数据，例如大小信息（示例STRLEN）、键入信息（示例TYPE）或有关集合中是否存在值的信息（示例SISMEMBER).

可以通过指定多个字符将权限组合在一起。 将权限指定为 'RW' 被视为完全访问权限，类似于仅传入~<pattern>.

有关具体示例，请考虑具有 ACL 规则的用户+@all ~app1:* (+@read ~app2:*). 此用户对 具有完全访问权限app1:*和 readonly 访问权限app2:*. 但是，某些命令支持从一个键读取数据、进行一些转换并将其存储到另一个键中。 其中一个命令是COPY命令，它将数据从源密钥复制到目标密钥中。 ACL 规则示例集无法处理从app2:user到app1:user，因为 root 权限和选择器都与命令不完全匹配。 但是，使用键选择器，您可以定义一组可以处理此请求的 ACL 规则+@all ~app1:* %R~app2:*. 第一个模式能够匹配app1:user并且第二个模式能够匹配app2:user.

命令需要哪种类型的权限通过关键规范进行记录。 权限类型基于 keys 逻辑作标志。 insert、update 和 delete 标志映射到写入键权限。 访问标志映射到读取密钥权限。 如果键没有逻辑作标志，例如EXISTS，则用户仍需要密钥读取或密钥写入权限才能执行命令。

注意：在评估执行命令是否需要读取权限时，将忽略用于访问用户数据的侧通道。 这意味着，某些返回有关已修改键的元数据的写入命令只需要对键的写入权限即可执行。 例如，请考虑以下两个命令：

• LPUSH key1 data：修改 “key1”，但只返回有关它的元数据，即推送后列表的大小，因此该命令只需要对 “key1” 的写入权限即可执行。
• LPOP key2：修改 “key2”，但也从中返回数据，即列表中最左侧的项目，因此该命令需要对 “key2” 的读取和写入权限才能执行。

如果应用程序需要确保没有数据从键（包括侧信道）访问，则建议不要提供对该键的任何访问权限。

密码如何在内部存储

Redis 在内部存储使用 SHA256 哈希的密码。如果您设置了密码 并检查ACL LIST或ACL GETUSER，您将看到一个长十六进制 字符串，看起来是伪随机的。下面是一个例子，因为在前面的 例如，为了简洁起见，长十六进制字符串被修剪了：

> ACL GETUSER default
1) "flags"
2) 1) "on"
3) "passwords"
4) 1) "2d9c75273d72b32df726fb545c8a4edc719f0a95a6fd993950b10c474ad9c927"
5) "commands"
6) "+@all"
7) "keys"
8) "~*"
9) "channels"
10) "&*"
11) "selectors"
12) (empty array)

使用 SHA256 可以避免以明文形式存储密码 同时仍然允许非常快速的AUTH命令，这是一个非常重要的 Redis 的功能，并且与客户对 Redis 的期望一致。

但是，ACL 密码并不是真正的密码。它们是共享密钥 在服务器和客户端之间，因为密码是 不是人类使用的身份验证令牌。例如：

• 没有长度限制，密码只会在某些客户端软件中被记住。在这种情况下，没有人需要回忆起密码。
• ACL 密码不保护任何其他事物。例如，它永远不会是某些电子邮件帐户的密码。
• 通常，当您能够通过完全访问给定服务器的 Redis 命令或损坏系统本身来访问散列密码本身时，您已经可以访问密码所保护的内容：Redis 实例稳定性及其包含的数据。

因此，为了使用 利用时间和空间使密码破解变得困难的算法， 是一个非常糟糕的选择。相反，我们建议生成强大的 passwords，这样就没有人能够使用 字典或暴力攻击，即使他们有哈希值。为此，有一个特殊的 ACL 命令ACL GENPASS使用系统加密伪随机生成密码 发电机：

> ACL GENPASS
"dd721260bfe1b3d9601e7fbab36de6d04e2e67b0ef1c53de59d45950db0dd3cc"

该命令输出一个 32 字节（256 位）伪随机字符串，该字符串转换为 64 字节的字母数字字符串。这足够长以避免攻击，而 足够易于管理、剪切和粘贴、存储等。这就是 您应该使用 以生成 Redis 密码。

使用外部 ACL 文件

有两种方法可以在 Redis 配置中存储用户：

1. 用户可以直接在redis.conf文件。
2. 可以指定外部 ACL 文件。

这两种方法互不兼容，因此 Redis 会要求您使用其中一种 或另一个。指定内部用户redis.conf是 适用于简单的用例。当有多个用户需要定义时，在 复杂环境，建议您改用 ACL 文件。

内部使用的格式redis.conf，而在外部 ACL 文件中恰好是 相同，因此从一个切换到另一个是微不足道的，并且是 以下内容：

user <username> ... acl rules ...

例如：

user worker +@list +@connection ~jobs:* on >ffa9203c493aa99

如果要使用外部 ACL 文件，则需要指定 名为aclfile喜欢这个：

aclfile /etc/redis/users.acl

当您只是直接在redis.conf文件中，您可以使用CONFIG REWRITE为了存储新用户配置 通过重写文件来访问它。

但是，外部 ACL 文件功能更强大。您可以执行以下作：

• 用ACL LOAD如果您手动修改了 ACL 文件，并且希望 Redis 重新加载新配置。请注意，仅当正确指定了所有用户时，此命令才能加载文件。否则，将向用户报告错误，并且旧配置将保持有效。
• 用ACL SAVE将当前 ACL 配置保存到 ACL 文件中。

请注意，CONFIG REWRITE不会同时触发ACL SAVE.当您使用 ACL 文件，则配置和 ACL 将单独处理。

Sentinel 和副本的 ACL 规则

如果您不想提供 Redis 副本和 Redis Sentinel 实例 对 Redis 实例的完全访问权限，以下是命令集 必须允许这样做，才能使一切正常工作。

对于 Sentinel，允许用户在主实例和副本实例中访问以下命令：

• 身份验证、客户端、订阅、脚本、发布、PING、信息、多、SLAVEOF、配置、客户端、执行。

Sentinel 不需要访问数据库中的任何键，但使用 Pub/Sub，因此 ACL 规则如下（注意：AUTH不需要，因为它始终是允许的）：

ACL SETUSER sentinel-user on >somepassword allchannels +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill

Redis 副本要求在主实例上允许以下命令：

• PSYNC、REPLCONF、PING

不需要访问任何键，因此这转换为以下规则：

ACL setuser replica-user on >somepassword +psync +replconf +ping

请注意，您无需配置副本以允许 master 能够执行任何命令集。从副本的角度来看，主服务器始终作为 root 用户进行身份验证。