Apache APISIX 3.1.0 版本正式釋出

Apache_APISIX發表於2022-12-30
ApacheAPI

時隔一個月，新版本又來了。這次的 APISIX 3.1.0 是 3.0 大版本以來的第一個新版本，在 3.x 的新時代裡，我們一如既往地在每個版本中給大家奉上更多的新功能。

此次釋出的 3.1.0 版本，新增了對外掛配置的加密儲存和儲存在外部安全服務的支援，著重於讓使用者能夠更安全、更放心地使用他們的配置。在這之外，我們還引入了許多新的特性，旨在最佳化對 APISIX 的使用體驗。

新特性：外掛配置的加密儲存

新版本支援將外掛的特定欄位加密儲存到 etcd 中。

在之前的版本中，APISIX 提供了一個 key_encrypt_salt 的配置項，支援對 etcd 裡面儲存的 SSL key 進行加密，避免明文儲存私鑰資料。畢竟像私鑰這樣的敏感資料，少一個地方儲存明文，就能多一份安心。那麼對於其他同樣敏感的配置，比如 jwt-auth 外掛中的 secret，我們能不能也加密起來，避免在 etcd 裡面儲存明文呢？

3.1 版本中就把加密儲存的功能擴充到其他欄位上。有了這個功能，我們可以在某個特定的外掛上指定需要加密的欄位，然後在 config.yaml 檔案中開啟加密，即可避免明文儲存。

舉個例子，我們給 jwt-auth 外掛新增瞭如下的標記：

     encrypt_fields = {"secret", "private_key"},

當我們在 config.yaml 裡開啟了欄位的加密功能：

apisix:
    data_encryption:
        enable: true
        keyring:
            - edd1c9f0985e76a2

那麼寫入到 etcd 的 jwt-auth 外掛的配置中的 secret 和 private_key，就會被加密儲存。透過 etcdctl get --prefix / 看到的配置，會是諸如 “"secret":"77+NmbYqNfN+oL..."” 這樣的資料，而不是原始的配置資訊。

新特性：將敏感資訊儲存在外部安全服務

除了可以將敏感資訊加密儲存在 etcd 之外，還可以選擇從別的系統中動態獲取敏感資訊，而不再要求敏感資訊必須儲存在 APISIX 的配置儲存（如 etcd）中。

在 3.1 版本中，我們上線了名為 APISIX Secret 的功能。APISIX Secret 允許使用者在 APISIX 中透過一些金鑰管理服務（Vault 等）來儲存 secret，在使用的時候根據 key 進行讀取，確保 secret 在整個平臺中不以明文的形式存在。

APISIX 目前支援透過以下方式儲存 secret：

  • 環境變數
  • HashiCorp Vault

相關示例

以 key-auth 外掛為例，我們來簡單示範下如何使用該特性。

基於環境變數的敏感資訊儲存

第一步：APISIX 例項啟動前建立環境變數

export JACK_AUTH_KEY=abc

第二步：在 key-auth 外掛中引用環境變數

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "$ENV://JACK_AUTH_KEY"
        }
    }
}'

透過以上步驟，可以將 key-auth 外掛中的 key 配置儲存在環境變數中，而不是在配置外掛時明文顯示。

基於 Vault 的敏感資訊儲存

第一步：在 Vault 中建立對應的配置，可以使用如下命令：

vault kv put apisix/jack auth-key=value

第二步：透過 Admin API 新增 Secret 資源，配置 Vault 的地址等連線資訊：

curl http://127.0.0.1:9180/apisix/admin/secrets/vault/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "https://127.0.0.1:8200"，
    "prefix": "apisix",
    "token": "root"
}'

第三步：在 key-auth 外掛中引用 APISIX Secret 資源，填充配置在 Vault 中的位置：

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "$secret://vault/1/jack/auth-key"
        }
    }
}'

透過以上步驟，可以將 key-auth 外掛中的 key 配置儲存在 Vault 中，而不是在配置外掛時明文顯示。

新特性：實驗性基於 gRPC 的 etcd 配置同步

在本次新版本中，我們還引入了實驗性的基於 gRPC 的 etcd 配置同步。當前 APISIX 同步 etcd 的配置，是基於 HTTP long pulling，這就要求 etcd 開啟 gRPC-gateway （所幸的是預設就是開啟的）。

在實踐過程中，我們遇到了 etcd 的 HTTP API 出現問題，也許是因為透過 HTTP 同步配置並非 etcd 的主流使用方式，所以會更容易遇到 bug。透過把 etcd 配置同步由 HTTP long pulling 切換到 gRPC 上面來，APISIX 實現了同步方式與主流接軌。

另外由於 gRPC 本身提供了多路複用的支援，改用 gRPC 同步配置能大幅降低 APISIX 到 etcd 的連線數。當前 APISIX 同步每一類配置都要有獨立的 HTTP 連線，切換到 gRPC 後每個程式只有一條用於配置同步的連線（如果開啟了 L4 代理，那麼是兩條）。

啟用實驗性的基於 gRPC 的配置同步，需要在配置檔案 config.yaml 中設定 use_grpc: true，如下所示：

  etcd:
    use_grpc: true
    timeout: 3600
    host:
      - "http://127.0.0.1:2379"
    prefix: "/apisix"

新特性：基於 Consul 的服務發現

在 APISIX 之前的版本里，有熱心的貢獻者提供了基於 Consul KV 的服務發現實現。不過 Consul KV 跟 Consul 自身的服務發現功能有些不同，Consul 自身的服務發現支援額外的一些功能，比如對註冊服務的健康檢查，所以在使用上會更為廣泛些。本次 3.1 版本中，另一位熱心貢獻者提供了基於 Consul 的服務發現，填補了這一空缺。

基於 Consul 的服務發現和之前版本里基於 Consul KV 的服務發現有著相似的配置。首先，需要在 config.yaml 檔案中啟用該服務發現：

discovery:
  consul:
    servers:
      - "http://127.0.0.1:8500"

然後在具體的 upstream 中配置對應的 service_name 和 discovery_type：

curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "service_name": "service_a",
    "discovery_type": "consul"
}'

對應的 upstream 在使用過程中，就會根據 Consul 裡面配置的值去得到真正的上游節點。

新特性：內建的除錯外掛

工欲善其事，必先利其器，除錯是程式設計師日常工作的一部分。作為注重除錯體驗的閘道器，APISIX 在 3.1 版本中以外掛的形式內建了一個 Lua 偵錯程式外掛，支援動態設定斷點、新增回撥等等。

預設的配置如下：

plugins:
    ...
    - inspect
    ...

plugin_attr:
  inspect:
    delay: 3
    hooks_file: "/usr/local/apisix/plugin_inspect_hooks.lua"

APISIX 在啟動後，會定期檢視配置的 hooks_file （這裡是 "/usr/local/apisix/plugin_inspect_hooks.lua"），如果檔案中有內容，就會根據裡面的內容設定斷點和回撥。比如下方內容會給 limit-req.lua 的 88 行上設定一個斷點，並在該斷點上註冊了回撥函式 function(info) ... end。

local dbg = require "apisix.inspect.dbg"

dbg.set_hook("limit-req.lua", 88, require("apisix.plugins.limit-req").access, function(info)
    ngx.log(ngx.INFO, debug.traceback("foo traceback", 3))
    return true
end)

新功能：最佳化以及更多小功能

除了上面提到的幾個大的功能外，此次釋出也包含許多值得述說的改動，比如：

相關文章