ACL

Redis 访问控制列表

Redis ACL，全称为访问控制列表，是一项允许限制某些连接可以执行的命令和可以访问的键的功能。其工作方式是，连接后，客户端需要提供用户名和有效密码进行身份验证。如果身份验证成功，连接将与给定用户及其限制相关联。Redis可以配置为使用“默认”用户对新连接进行身份验证（这是默认配置）。配置默认用户的副作用是，能够仅为未明确验证的连接提供特定功能子集。

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

Redis 的 AUTH 命令在 Redis 6 中得到了扩展，因此现在可以使用双参数形式：

AUTH <username> <password>

这是旧表单的示例：

AUTH <password>

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

何时使用ACLs

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

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

ACL的另一个典型用途与托管的Redis实例相关。Redis通常作为托管服务提供，无论是公司内部团队为其他内部客户处理Redis基础设施，还是云提供商在软件即服务（SaaS）设置中提供。在这两种设置中，我们都希望确保为客户排除配置命令。

使用ACL命令配置ACL

ACL（访问控制列表）是使用一种特定领域语言（DSL）定义的，该语言描述了给定用户被允许执行的操作。这些规则总是从左到右、从上到下依次执行，因为有时规则的顺序对于理解用户真正能够执行的操作非常重要。

默认情况下，有一个名为default的用户定义。我们可以使用ACL LIST命令来检查当前活动的ACL，并验证一个新启动的、默认配置的Redis实例的配置是什么：

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

上述命令以Redis配置文件中使用的相同格式报告用户列表，通过将当前为用户设置的ACL转换回其描述。

每行的前两个词是“user”后跟用户名。接下来的词是描述不同事物的ACL规则。我们将详细展示这些规则的工作原理，但目前只需知道默认用户被配置为激活状态（on），不需要密码（nopass），可以访问所有可能的键（~*）和Pub/Sub频道（&*），并且能够调用所有可能的命令（+@all）。

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

ACL规则

以下是有效的ACL规则列表。某些规则只是单个单词，用于激活或移除标志，或对用户ACL执行特定更改。其他规则是字符前缀，与命令或类别名称、键模式等连接使用。

启用和禁止用户：

• on: 启用用户：可以以此用户身份进行认证。
• off: 禁止用户：此用户将无法再进行身份验证；然而，之前已经通过身份验证的连接仍然有效。请注意，如果默认用户被标记为off，新连接将开始为未认证状态，并且无论默认用户配置如何，用户都需要发送AUTH或HELLO并带有AUTH选项以某种方式进行身份验证。

允许和禁止命令：

• +: 将命令添加到用户可以调用的命令列表中。可以与 | 一起使用以允许子命令（例如 "+config|get"）。
• -: 从用户可以调用的命令列表中移除该命令。从 Redis 7.0 开始，它可以与 | 一起用于阻塞子命令（例如 "-config|set"）。
• +@: 添加该类别中的所有命令以供用户调用，有效类别包括 @admin、@set、@sortedset 等，可以通过调用 ACL CAT 命令查看完整列表。特殊类别 @all 表示所有命令，包括服务器中当前存在的命令以及将来通过模块加载的命令。
• -@: 类似于 +@，但从客户端可以调用的命令列表中移除这些命令。
• +|first-arg: 允许一个特定命令的第一个参数，即使该命令在其他情况下被禁用。此功能仅支持没有子命令的命令，并且不允许使用负形式，如 -SELECT|1，只能以“+”开头添加。此功能已被弃用，未来可能会被移除。
• allcommands: +@all 的别名。请注意，它意味着能够执行通过模块系统加载的所有未来命令。
• nocommands: -@all 的别名。

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

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

允许和禁止 Pub/Sub 频道：

• &: （在 Redis 6.2 及更高版本中可用）添加用户可以访问的 Pub/Sub 通道的全局样式模式。可以指定多个通道模式。请注意，模式匹配仅适用于由 PUBLISH 和 SUBSCRIBE 提到的通道，而 PSUBSCRIBE 需要其通道模式与允许用户的通道模式之间进行字面匹配。
• allchannels: &* 的别名，允许用户访问所有 Pub/Sub 频道。
• resetchannels: 刷新允许的频道模式列表，如果用户的Pub/Sub客户端不再能够访问它们各自的频道和/或频道模式，则断开连接。

为用户配置有效密码：

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

注意：如果用户没有被标记为nopass并且没有有效的密码列表，那么该用户实际上无法使用，因为无法以该用户身份登录。

为用户配置选择器：

• (): （在 Redis 7.0 及更高版本中可用）创建一个新的选择器以匹配规则。选择器在用户权限之后进行评估，并根据它们定义的顺序进行评估。如果命令匹配用户权限或任何选择器，则允许执行。有关更多信息，请参阅selectors。
• 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 SETUSER 命令接受用户名和要应用于用户的ACL规则列表。然而，上面的示例根本没有指定任何规则。如果用户不存在，这将仅使用新用户的默认设置创建用户。如果用户已经存在，上面的命令将不会执行任何操作。

检查默认用户状态：

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

新用户 "alice" 是：

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

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

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

这样的用户完全没用。让我们尝试定义用户，使其处于活动状态，拥有密码，并且只能使用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的替代方案，该方案设计得更适合计算机阅读，而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，输出可能更易读，因为它会以映射回复的形式返回：

> 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 SETUSER调用都不会重置用户，而是将ACL规则应用于现有用户。只有在用户之前未知的情况下，用户才会被重置。在这种情况下，会创建一个全新的用户，其ACL为零。该用户无法执行任何操作，被禁止，没有密码等等。这是为了安全考虑的最佳默认设置。

然而，后续的调用将只是逐步修改用户。例如，以下序列：

> 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命令表中标记为危险的所有命令。请注意，命令类别从不包含模块命令，除了+@all。如果你使用+@all，用户可以执行所有命令，甚至包括通过模块系统加载的未来命令。然而，如果你使用ACL规则+@read或其他任何规则，模块命令总是被排除在外。这一点非常重要，因为你应该只信任Redis内部命令表。模块可能暴露危险的内容，在ACL规则仅为加法形式的情况下，即+@all -...，你必须绝对确保不会包含你不打算包含的内容。

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

• admin - 管理命令。普通应用程序通常不需要使用这些命令。包括 REPLICAOF, CONFIG, DEBUG, SAVE, MONITOR, ACL, SHUTDOWN 等。
• bitmap - 数据类型：与位图相关。
• blocking - 可能会阻塞连接，直到被另一个命令释放。
• connection - 影响连接或其他连接的命令。 这包括 AUTH, SELECT, COMMAND, CLIENT, ECHO, PING 等。
• 危险的 - 潜在危险的命令（每个命令都应因各种原因谨慎考虑）。这包括 FLUSHALL, MIGRATE, RESTORE, SORT, KEYS, CLIENT, DEBUG, INFO, CONFIG, SAVE, REPLICAOF, 等。
• geo - 数据类型：与地理空间索引相关。
• hash - 数据类型：与哈希相关。
• hyperloglog - 数据类型：与hyperloglog相关。
• fast - 快速的O(1)命令。可能会在参数数量上循环，但不会在键中的元素数量上循环。
• keyspace - 以类型无关的方式写入或读取键、数据库或其元数据。包括 DEL, RESTORE, DUMP, RENAME, EXISTS, DBSIZE, KEYS, EXPIRE, TTL, FLUSHALL, 等。可能修改键空间、键或元数据的命令也将具有 write 类别。仅读取键空间、键或元数据的命令将具有 read 类别。
• list - 数据类型：与列表相关。
• pubsub - 与发布订阅相关的命令。
• read - 从键中读取（值或元数据）。请注意，不与键交互的命令不会有read或write。
• scripting - 与脚本相关。
• set - 数据类型：与集合相关。
• sortedset - 数据类型：与有序集合相关。
• 慢 - 所有不是fast的命令。
• stream - 数据类型：与流相关的。
• string - 数据类型：与字符串相关的。
• 事务 - WATCH / MULTI / EXEC 相关命令。
• 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个不同的类别。现在让我们检查一下哪些命令属于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"

请注意，命令可能属于多个类别。例如，像+@geo -@read这样的ACL规则将导致某些地理命令被排除，因为它们是只读命令。

允许/阻止子命令

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

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

允许被阻止命令的第一个参数

注意：此功能自 Redis 7.0 起已弃用，未来可能会被移除。

有时，排除或包含整个命令或子命令的能力是不够的。 许多部署可能不希望提供执行SELECT任何数据库的能力，但可能仍然希望能够运行SELECT 0。

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

ACL SETUSER myuser -select +select|0

首先，移除SELECT命令，然后添加允许的first-arg。请注意，无法进行反向操作，因为first-args只能添加，不能排除。为某些用户指定所有有效的first-args更安全，因为未来可能会添加新的first-args。

另一个例子：

ACL SETUSER myuser -debug +debug|digest

请注意，第一个参数匹配可能会增加一些性能开销；然而，即使使用合成基准测试也很难衡量。只有在调用此类命令时才会支付额外的CPU成本，而在调用其他命令时则不会。

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

+@all 对比 -@all

在上一节中，我们观察了如何通过添加/删除单个命令来定义命令ACL。

选择器

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

例如，考虑一个具有ACL规则+GET ~key1 (+SET ~key2)的用户。 该用户能够执行GET key1和SET key2 hello，但不能执行GET key2或SET key1 world。

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

关键权限

从 Redis 7.0 开始，键模式也可以用于定义命令如何能够访问键。 这是通过定义键权限的规则来实现的。 键权限规则的形式为 %()~。 权限被定义为映射到以下键权限的单个字符：

• W (写): 存储在键中的数据可能会被更新或删除。
• R (读取): 用户提供的键中的数据被处理、复制或返回。请注意，这不包括元数据，如大小信息（例如 STRLEN）、类型信息（例如 TYPE）或关于值是否存在于集合中的信息（例如 SISMEMBER）。

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

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

命令所需的权限类型通过关键规格进行记录。 权限类型基于键的逻辑操作标志。 插入、更新和删除标志映射到写键权限。 访问标志映射到读键权限。 如果键没有逻辑操作标志，例如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实例的稳定性及其包含的数据。

因此，为了使用一种利用时间和空间来增加密码破解难度的算法而减慢密码验证速度，是一个非常糟糕的选择。我们建议的是生成强密码，这样即使有人拥有哈希值，也无法通过字典或暴力攻击来破解它。为此，有一个特殊的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文件并希望Redis重新加载新配置，请使用ACL LOAD。请注意，此命令仅在所有用户都正确指定的情况下才能加载文件。否则，将向用户报告错误，并且旧配置将保持有效。
• 使用 ACL SAVE 将当前的 ACL 配置保存到 ACL 文件中。

请注意，CONFIG REWRITE 不会触发 ACL SAVE。当您使用 ACL 文件时，配置和 ACL 是分开处理的。

Sentinel 和副本的 ACL 规则

如果您不希望Redis副本和Redis Sentinel实例对您的Redis实例拥有完全访问权限，以下是必须允许的命令集，以确保一切正常工作。

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

• AUTH, CLIENT, SUBSCRIBE, SCRIPT, PUBLISH, PING, INFO, MULTI, SLAVEOF, CONFIG, CLIENT, EXEC.

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

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