Redis 6.0 新特性 ACL 介紹 Intro 在 Redis 6.0 中引入了 ACL（Access Control List) 的支持，在此前的版本中 Redis 中是沒有用戶的概念的，其實沒有辦法很好的控制許可權，redis 6.0 開始支持用戶，可以給每個用戶分配不同的許可權來控制許可權。 ...
Redis 6.0 新特性 ACL 介紹
Intro
在 Redis 6.0 中引入了 ACL（Access Control List) 的支持，在此前的版本中 Redis 中是沒有用戶的概念的，其實沒有辦法很好的控制許可權，redis 6.0 開始支持用戶，可以給每個用戶分配不同的許可權來控制許可權。
下麵我們就來介紹一下 Redis 6.0 中的 ACL 吧，下麵的示例可以通過 docker 運行了一個 redis-6.0 的容器來實驗的
運行一個 redis 6.0 的 docker 容器
因為我本地已經裝了一個 redis，6379 埠已經被禁用了，所以使用了 16379 埠
docker run -d --name=redis-server-6.0 -p 16379:6379 redis:6.0-alpine
創建成功之後就可以使用 redis-cli 連上去了
我是直接用的本地的 redis-cli，如果本地沒有也可以使用 docker 容器內部的 redis-cli，
docker exec -it redis-server-6.0 redis-cli
AUTH
在 redis 的之前版本中是有一個 “AUTH” 命令，但是之前的版本只是支持一個 Password，是沒有用戶的概念的，這就導致所有的客戶端相當於是使用同一個賬戶來操作 redis 的，redis 6.0 擴展了 AUTH 的語法:
AUTH <username> <password>
同時也相容了舊版本的 AUTH
AUTH <password>
使用這種方式時，也就是只提供密碼，相當於使用了一個預設的用戶 “default”，通過這樣的方式，實現了對低版本的相容
ACL
ACL 使用場景
在使用 ACL 之前，您可能會問自己，這個功能主要用來幹嘛，它能幫我實現什麼，ACL 可以幫助你實現下麵兩個主要目標：
- 通過限制對命令和密鑰的訪問來提高安全性，以使不受信任的客戶端無法訪問，而受信任的客戶端僅具有對資料庫的最低訪問級別才能執行所需的工作。例如，某些客戶端可能僅能夠執行只讀命令，
- 提高操作安全性，以防止由於軟體錯誤或人為錯誤而導致進程或人員訪問 Redis，從而損壞數據或配置。例如，沒有必要讓工作人員從 Redis 調用
FLUSHALL命令。
ACL 的另一種典型用法與托管Redis實例有關。Redis通常由管理內部Redis基礎結構的內部公司團隊為其所擁有的其他內部客戶提供的一項托管服務，或者由雲提供商在軟體即服務設置中提供。
在這兩種設置中，我們都希望確保為客戶排除配置命令。過去，通過命令重命名來完成此操作的方法是一種技巧，它使我們可以長時間不用 ACL 生存，但使用體驗並不理想。
通過 ACL 命令來配置 ACL 規則
ACL是使用 DSL（domain specific language）定義的，該 DSL 描述了給定用戶能夠執行的操作。此類規則始終從左到右從第一個到最後一個實施，因為有時規則的順序對於理解用戶的實際能力很重要。
預設情況下，有一個用戶定義，稱為default。
我們可以使用 ACL LIST 命令來檢查當前啟用的 ACL 規則
127.0.0.1:6379> ACL LIST
1) "user default on nopass ~* +@all"
參數說明：
| 參 數 | 說明 |
|---|---|
| user | 用戶 |
| default | 表示預設用戶名，或則自己定義的用戶名 |
| on | 表示是否啟用該用戶，預設為off（禁用） |
| #... | 表示用戶密碼，nopass表示不需要密碼 |
| ~* | 表示可以訪問的Key（正則匹配） |
| +@ | 表示用戶的許可權，“+”表示授權許可權，有許可權操作或訪問，“-”表示還是沒有許可權； @為許可權分類，可以通過 ACL CAT 查詢支持的分類。+@all 表示所有許可權，nocommands 表示不給與任何命令的操作許可權 |
許可權對key的類型和命令的類型進行了分類，如有對數據類型進行分類：string、hash、list、set、sortedset，和對命令類型進行分類：connection、admin、dangerous。
執行 ACL CAT 可以查看支持的許可權分類列表
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"
-- 返回指定類別中的命令
> 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"
配置用戶許可權
我們可以通過兩種主要方式創建和修改用戶：
- 使用 ACL 命令及其 ACL SETUSER 子命令。
- 修改伺服器配置（可以在其中定義用戶）並重新啟動伺服器，或者如果我們使用的是外部
ACL文件，則只需發出ACL LOAD即可。
+<command>：將命令添加到用戶可以調用的命令列表中，如+@hash
-<command>: 將命令從用戶可以調用的命令列表中移除
+@<category>: 添加一類命令，如：@admin, @set, @hash ... 可以`ACL CAT` 查看具體的操作指令。特殊類別@all表示所有命令，包括當前在伺服器中存在的命令，以及將來將通過模塊載入的命令
-@<category>: 類似+@<category>，從客戶端可以調用的命令列表中刪除命令
+<command>|subcommand: 允許否則禁用特定子命令。註意，這種形式不允許像-DEBUG | SEGFAULT那樣，而只能以“ +”開頭
allcommands：+@all的別名，允許所有命令操作執行。註意，這意味著可以執行將來通過模塊系統載入的所有命令。
nocommands：-@all的別名，不允許所有命令操作執行。
使用 ACL SETUSER 命令
首先，讓我們嘗試最簡單的 ACL SETUSER 命令調用：
> ACL SETUSER alice
OK
在上面的示例中，我根本沒有指定任何規則。如果用戶不存在，這將使用just created的預設屬性來創建用戶。如果用戶已經存在，則上面的命令將不執行任何操作。
讓我們檢查一下預設的用戶狀態：
> ACL LIST
1) "user alice off -@all"
2) "user default on nopass ~* +@all"
剛創建的用戶“ alice”為：
處於關閉狀態，即已禁用。 AUTH 將不起作用。
無法訪問任何命令。請註意，預設情況下，該用戶是預設創建的，無法訪問任何命令，因此-@all可以忽略上面輸出中的，但是 ACL LIST 嘗試是顯式的，而不是隱式的。
最後，沒有用戶可以訪問的密鑰模式。
用戶也沒有設置密碼。
這樣的用戶是完全無用的。讓我們嘗試定義用戶，使其處於活動狀態，具有密碼，並且僅可以使用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 or its subcommand
事情按預期進行。為了檢查用戶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) 1) "cached:*"
如果我們使用RESP3，則輸出的可讀性可能更高，因此將其作為地圖回覆返回：
> ACL GETUSER alice
1# "flags" => 1~ "on"
2# "passwords" => 1) "2d9c75..."
3# "commands" => "-@all +get"
4# "keys" => 1) "cached:*"
多次調用ACL SETUSER會發生什麼
瞭解多次調用 ACL SETUSER 會發生什麼非常重要。重要的是要知道，每個SETUSER調用都不會重置用戶，而只會將ACL規則應用於現有用戶。
僅在之前不知道的情況下才重置用戶：
在這種情況下，將使用歸零的ACL創建一個全新的用戶，即該用戶無法執行任何操作，被禁用，沒有密碼等等：為了安全起見，最佳預設值。
但是，以後的調用只會逐步修改用戶，因此例如以下調用順序將導致 myuser 能夠同時調用 GET 和 SET：
> ACL SETUSER myuser +set
OK
> ACL SETUSER myuser +get
OK
> ACL LIST
1) "user default on nopass ~* +@all"
2) "user myuser off -@all +set +get"
使用外部 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 文件內容的正確性 - 使用
ACL SAVE將當前 ACL 配置保存到一個外部文件
More
redis 6.0 的 ACL 特性為我們帶來了更好的許可權控制方案，安全性更好，有需要的快來體驗一下吧
Reference
- https://redis.io/topics/acl
- https://redis.io/commands/auth
- https://www.cnblogs.com/zhoujinyi/p/13222464.html
