You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2022/12/30 01:09:26 UTC
[GitHub] [apisix-website] SylviaBABY opened a new pull request, #1461: docs: add APISIX 3.1.0 release blog
SylviaBABY opened a new pull request, #1461:
URL: https://github.com/apache/apisix-website/pull/1461
Changes: add APISIX 3.1.0 release blog
<!-- Add here what changes were made in this pull request and if possible provide links showcasing the changes. -->
Screenshots of the change:
<!-- Add screenshots depicting the changes. -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-website] netlify[bot] commented on pull request #1461: docs: add APISIX 3.1.0 release blog
Posted by GitBox <gi...@apache.org>.
netlify[bot] commented on PR #1461:
URL: https://github.com/apache/apisix-website/pull/1461#issuecomment-1367670866
### <span aria-hidden="true">👷</span> Deploy Preview for *apache-apisix* processing.
| Name | Link |
|---------------------------------|------------------------|
|<span aria-hidden="true">🔨</span> Latest commit | b248ce8831aa8de2acf0ff279b0555116f0d7d6a |
|<span aria-hidden="true">🔍</span> Latest deploy log | https://app.netlify.com/sites/apache-apisix/deploys/63ae3a4679e40600094beaa2 |
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-website] juzhiyuan commented on a diff in pull request #1461: docs: add APISIX 3.1.0 release blog
Posted by GitBox <gi...@apache.org>.
juzhiyuan commented on code in PR #1461:
URL: https://github.com/apache/apisix-website/pull/1461#discussion_r1059211186
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level, and adds a built-in debugging plugin to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level, and adds a built-in debugging plugin to optimize the experience of using APISIX.
Review Comment:
ditto
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level, and adds a built-in debugging plugin to optimize the experience of using APISIX.
Review Comment:
```suggestion
description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin to optimize the experience when debugging APISIX.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-website] juzhiyuan commented on a diff in pull request #1461: docs: add APISIX 3.1.0 release blog
Posted by GitBox <gi...@apache.org>.
juzhiyuan commented on code in PR #1461:
URL: https://github.com/apache/apisix-website/pull/1461#discussion_r1059211008
##########
blog/zh/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,214 @@
+---
+title: "Apache APISIX 3.1.0 正式发布"
+authors:
+ - name: "罗泽轩"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- 插件配置
+- 安全
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 版本正式发布！此版本带来很多关于安全层面的功能支持，同时新增内置调试插件，旨在优化对 APISIX 的使用体验。
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 版本正式发布！此版本带来很多关于安全层面的功能支持，同时新增内置调试插件，旨在优化对 APISIX 的使用体验。
+
+<!--truncate-->
+
+时隔一个月，新版本又来了。这次的 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` 插件新增了如下的标记：
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+当我们在 `config.yaml` 里开启了字段的加密功能：
+
+```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 实例启动前创建环境变量
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+第二步：在 `key-auth` 插件中引用环境变量
+
+```shell
+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 中创建对应的配置，可以使用如下命令：
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+第二步：通过 Admin API 添加 Secret 资源，配置 Vault 的地址等连接信息：
+
+```shell
+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 中的位置：
+
+```shell
+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`：
+
+```yaml
+ 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` 文件中启用该服务发现：
+
+```yaml
+discovery:
+ consul:
+ servers:
+ - "http://127.0.0.1:8500"
+
+```
+
+然后在具体的 upstream 中配置对应的 `service_name` 和 `discovery_type`：
+
+```shell
+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 调试器插件，支持动态设置断点、添加回调等等。
+
+默认的配置如下：
+
+```yaml
+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`。
+
+```lua
+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)
+```
+
+## 新功能：优化以及更多小功能
+
+除了上面提到的几个大的功能外，此次发布也包含许多值得述说的改动：
+
+- 优化 Prometheus 指标采集的资源占用
+- 支持在 L4 的代理中，配置域名作为上游
+
+如果你对新版本的完整更新细节感兴趣，请参考 3.1.0 发布的 [changelog](https://github.com/apache/apisix/blob/release/3.1/docs/zh/latest/CHANGELOG.md#310)。
Review Comment:
```suggestion
如果你对新版本的完整更新细节感兴趣，请参考 3.1.0 发布的 [CHANGELOG](https://github.com/apache/apisix/blob/release/3.1/docs/zh/latest/CHANGELOG.md#310)。
```
##########
blog/zh/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,214 @@
+---
+title: "Apache APISIX 3.1.0 正式发布"
+authors:
+ - name: "罗泽轩"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- 插件配置
+- 安全
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 版本正式发布！此版本带来很多关于安全层面的功能支持，同时新增内置调试插件，旨在优化对 APISIX 的使用体验。
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 版本正式发布！此版本带来很多关于安全层面的功能支持，同时新增内置调试插件，旨在优化对 APISIX 的使用体验。
+
+<!--truncate-->
+
+时隔一个月，新版本又来了。这次的 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` 插件新增了如下的标记：
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+当我们在 `config.yaml` 里开启了字段的加密功能：
+
+```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 实例启动前创建环境变量
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+第二步：在 `key-auth` 插件中引用环境变量
+
+```shell
+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 中创建对应的配置，可以使用如下命令：
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+第二步：通过 Admin API 添加 Secret 资源，配置 Vault 的地址等连接信息：
+
+```shell
+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 中的位置：
+
+```shell
+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`：
+
+```yaml
+ 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` 文件中启用该服务发现：
+
+```yaml
+discovery:
+ consul:
+ servers:
+ - "http://127.0.0.1:8500"
+
Review Comment:
```suggestion
```
##########
blog/zh/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,214 @@
+---
+title: "Apache APISIX 3.1.0 正式发布"
+authors:
+ - name: "罗泽轩"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- 插件配置
+- 安全
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 版本正式发布！此版本带来很多关于安全层面的功能支持，同时新增内置调试插件，旨在优化对 APISIX 的使用体验。
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 版本正式发布！此版本带来很多关于安全层面的功能支持，同时新增内置调试插件，旨在优化对 APISIX 的使用体验。
+
+<!--truncate-->
+
+时隔一个月，新版本又来了。这次的 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` 插件新增了如下的标记：
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+当我们在 `config.yaml` 里开启了字段的加密功能：
+
+```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 实例启动前创建环境变量
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+第二步：在 `key-auth` 插件中引用环境变量
+
+```shell
+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 中创建对应的配置，可以使用如下命令：
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+第二步：通过 Admin API 添加 Secret 资源，配置 Vault 的地址等连接信息：
+
+```shell
+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 中的位置：
+
+```shell
+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`：
+
+```yaml
+ 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` 文件中启用该服务发现：
+
+```yaml
+discovery:
+ consul:
+ servers:
+ - "http://127.0.0.1:8500"
+
+```
+
+然后在具体的 upstream 中配置对应的 `service_name` 和 `discovery_type`：
+
+```shell
+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 调试器插件，支持动态设置断点、添加回调等等。
+
+默认的配置如下：
+
+```yaml
+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`。
Review Comment:
```suggestion
APISIX 在启动后，会定期查看配置的 hooks_file （这里是 `/usr/local/apisix/plugin_inspect_hooks.lua`），如果文件里面有内容，就会根据里面的内容设置断点和回调。比如下方内容会给 `limit-req.lua` 的 88 行上设置一个断点，并在该断点上注册了回调函数 `function(info) ... end`。
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-website] SylviaBABY merged pull request #1461: docs: add APISIX 3.1.0 release blog
Posted by GitBox <gi...@apache.org>.
SylviaBABY merged PR #1461:
URL: https://github.com/apache/apisix-website/pull/1461
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-website] SkyeYoung commented on a diff in pull request #1461: docs: add APISIX 3.1.0 release blog
Posted by GitBox <gi...@apache.org>.
SkyeYoung commented on code in PR #1461:
URL: https://github.com/apache/apisix-website/pull/1461#discussion_r1059224835
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
Review Comment:
```suggestion
Then the `secret` and `private_key` in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
Review Comment:
```suggestion
In version 3.1, we introduced a feature called "APISIX Secret", which allows users to store secrets in APISIX through some key management services (`Vault`, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
Review Comment:
```suggestion
Step 1: Create the corresponding configuration in `Vault`, which can be done with the following command.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
Review Comment:
```suggestion
#### `Vault`-based storage of sensitive information
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+Step 2: Add the Secret resource via the Admin API and configure the Vault's address and other connection information.
+
+```shell
+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"
+}'
+```
+
+Step 3: Refer to the APISIX Secret resource in the `key-auth` plugin and populate the location in the Vault with the following configuration.
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+With the above steps, you can save the key configuration in the `key-auth` plugin in the Vault instead of explicitly displaying it when configuring it.
+
+## New Feature: Experimental gRPC-based etcd Configuration Synchronization
+
+In this new release, we have also introduced experimental gRPC-based etcd configuration synchronization. The current APISIX configuration for synchronizing etcd is based on HTTP long pulling, which requires etcd to have gRPC-gateway enabled (fortunately, it is enabled by default).
+
+In practice, we encountered problems with etcd's HTTP API, perhaps because synchronizing the configuration via HTTP is not the mainstream way of using etcd, so it is more likely to encounter bugs.
+
+In addition, since gRPC itself provides multiplexing support, switching to gRPC synchronization can significantly reduce the number of APISIX connections to etcd.
+
+Currently, APISIX synchronization requires a separate HTTP connection for each type of configuration. Switching to gRPC results in only one connection per process for configuration synchronization (two if the L4 proxy is enabled).
+
+To enable experimental gRPC-based configuration synchronization, set `use_grpc: true` in the configuration file `config.yaml`.
+
+```yaml
+ etcd:
+ use_grpc: true
+ timeout: 3600
+ host:
+ - "http://127.0.0.1:2379"
+ prefix: "/apisix"
+```
+
+## New Feature: Consul-based Service Discovery
Review Comment:
```suggestion
## New Feature: `Consul`-based Service Discovery
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+Step 2: Add the Secret resource via the Admin API and configure the Vault's address and other connection information.
+
+```shell
+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"
+}'
+```
+
+Step 3: Refer to the APISIX Secret resource in the `key-auth` plugin and populate the location in the Vault with the following configuration.
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+With the above steps, you can save the key configuration in the `key-auth` plugin in the Vault instead of explicitly displaying it when configuring it.
+
+## New Feature: Experimental gRPC-based etcd Configuration Synchronization
+
+In this new release, we have also introduced experimental gRPC-based etcd configuration synchronization. The current APISIX configuration for synchronizing etcd is based on HTTP long pulling, which requires etcd to have gRPC-gateway enabled (fortunately, it is enabled by default).
+
+In practice, we encountered problems with etcd's HTTP API, perhaps because synchronizing the configuration via HTTP is not the mainstream way of using etcd, so it is more likely to encounter bugs.
+
+In addition, since gRPC itself provides multiplexing support, switching to gRPC synchronization can significantly reduce the number of APISIX connections to etcd.
+
+Currently, APISIX synchronization requires a separate HTTP connection for each type of configuration. Switching to gRPC results in only one connection per process for configuration synchronization (two if the L4 proxy is enabled).
+
+To enable experimental gRPC-based configuration synchronization, set `use_grpc: true` in the configuration file `config.yaml`.
+
+```yaml
+ etcd:
+ use_grpc: true
+ timeout: 3600
+ host:
+ - "http://127.0.0.1:2379"
+ prefix: "/apisix"
+```
+
+## New Feature: Consul-based Service Discovery
+
+In previous versions of APISIX, enthusiastic contributors provided a Consul KV-based service discovery implementation. However, Consul KV is a bit different from Consul's own service discovery, which supports additional features such as health checks for registered services, so it is more widely used.
+
+In this 3.1 release, another enthusiastic contributor has provided Consul-based service discovery to fill this gap.
Review Comment:
```suggestion
In this 3.1 release, another enthusiastic contributor has provided `Consul`-based service discovery to fill this gap.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+Step 2: Add the Secret resource via the Admin API and configure the Vault's address and other connection information.
Review Comment:
```suggestion
Step 2: Add the Secret resource via the Admin API and configure the `Vault`'s address and other connection information.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+Step 2: Add the Secret resource via the Admin API and configure the Vault's address and other connection information.
+
+```shell
+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"
+}'
+```
+
+Step 3: Refer to the APISIX Secret resource in the `key-auth` plugin and populate the location in the Vault with the following configuration.
Review Comment:
```suggestion
Step 3: Refer to the `APISIX Secret` resource in the `key-auth` plugin and populate the location in the Vault with the following configuration.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+Step 2: Add the Secret resource via the Admin API and configure the Vault's address and other connection information.
+
+```shell
+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"
+}'
+```
+
+Step 3: Refer to the APISIX Secret resource in the `key-auth` plugin and populate the location in the Vault with the following configuration.
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+With the above steps, you can save the key configuration in the `key-auth` plugin in the Vault instead of explicitly displaying it when configuring it.
+
+## New Feature: Experimental gRPC-based etcd Configuration Synchronization
+
+In this new release, we have also introduced experimental gRPC-based etcd configuration synchronization. The current APISIX configuration for synchronizing etcd is based on HTTP long pulling, which requires etcd to have gRPC-gateway enabled (fortunately, it is enabled by default).
+
+In practice, we encountered problems with etcd's HTTP API, perhaps because synchronizing the configuration via HTTP is not the mainstream way of using etcd, so it is more likely to encounter bugs.
+
+In addition, since gRPC itself provides multiplexing support, switching to gRPC synchronization can significantly reduce the number of APISIX connections to etcd.
+
+Currently, APISIX synchronization requires a separate HTTP connection for each type of configuration. Switching to gRPC results in only one connection per process for configuration synchronization (two if the L4 proxy is enabled).
+
+To enable experimental gRPC-based configuration synchronization, set `use_grpc: true` in the configuration file `config.yaml`.
+
+```yaml
+ etcd:
+ use_grpc: true
+ timeout: 3600
+ host:
+ - "http://127.0.0.1:2379"
+ prefix: "/apisix"
+```
+
+## New Feature: Consul-based Service Discovery
+
+In previous versions of APISIX, enthusiastic contributors provided a Consul KV-based service discovery implementation. However, Consul KV is a bit different from Consul's own service discovery, which supports additional features such as health checks for registered services, so it is more widely used.
Review Comment:
```suggestion
In previous versions of APISIX, enthusiastic contributors provided a `Consul KV`-based service discovery implementation. However, `Consul KV` is a bit different from `Consul`'s own service discovery, which supports additional features such as health checks for registered services, so it is more widely used.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+Step 2: Add the Secret resource via the Admin API and configure the Vault's address and other connection information.
+
+```shell
+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"
+}'
+```
+
+Step 3: Refer to the APISIX Secret resource in the `key-auth` plugin and populate the location in the Vault with the following configuration.
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+With the above steps, you can save the key configuration in the `key-auth` plugin in the Vault instead of explicitly displaying it when configuring it.
+
+## New Feature: Experimental gRPC-based etcd Configuration Synchronization
+
+In this new release, we have also introduced experimental gRPC-based etcd configuration synchronization. The current APISIX configuration for synchronizing etcd is based on HTTP long pulling, which requires etcd to have gRPC-gateway enabled (fortunately, it is enabled by default).
+
+In practice, we encountered problems with etcd's HTTP API, perhaps because synchronizing the configuration via HTTP is not the mainstream way of using etcd, so it is more likely to encounter bugs.
+
+In addition, since gRPC itself provides multiplexing support, switching to gRPC synchronization can significantly reduce the number of APISIX connections to etcd.
+
+Currently, APISIX synchronization requires a separate HTTP connection for each type of configuration. Switching to gRPC results in only one connection per process for configuration synchronization (two if the L4 proxy is enabled).
+
+To enable experimental gRPC-based configuration synchronization, set `use_grpc: true` in the configuration file `config.yaml`.
+
+```yaml
+ etcd:
+ use_grpc: true
+ timeout: 3600
+ host:
+ - "http://127.0.0.1:2379"
+ prefix: "/apisix"
+```
+
+## New Feature: Consul-based Service Discovery
+
+In previous versions of APISIX, enthusiastic contributors provided a Consul KV-based service discovery implementation. However, Consul KV is a bit different from Consul's own service discovery, which supports additional features such as health checks for registered services, so it is more widely used.
+
+In this 3.1 release, another enthusiastic contributor has provided Consul-based service discovery to fill this gap.
+
+Consul-based service discovery has a similar configuration to Consul KV-based service discovery in previous versions. First, the service discovery needs to be enabled in the `config.yaml` file.
Review Comment:
```suggestion
`Consul`-based service discovery has a similar configuration to `Consul KV`-based service discovery in previous versions. First, the service discovery needs to be enabled in the `config.yaml` file.
```
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level and adds a built-in debugging plugin, to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## New feature: storing sensitive information in an external security service
+
+In addition to storing sensitive information encrypted in etcd, there is also the option to dynamically retrieve sensitive information from another system instead of requiring it to be stored in APISIX's configuration store (e.g. etcd).
+
+In version 3.1, we introduced a feature called APISIX Secret, which allows users to store secret in APISIX through some key management services (Vault, etc.) and read it according to the key at the time of use, ensuring that the secret does not exist in plaintext throughout the platform.
+
+APISIX currently supports storing secret through the following methods.
+
+- Environment variables
+- HashiCorp Vault
+
+### Related examples
+
+Using the `key-auth` plugin as an example, let's demonstrate how to use the feature.
+
+#### Environment variable-based sensitive information storage
+
+Step 1: Create environment variables before starting the APISIX instance
+
+```shell
+export JACK_AUTH_KEY=abc
+```
+
+Step 2: Reference the environment variables in the `key-auth` plugin
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+The above steps allow you to save the key configuration in the `key-auth` plugin in an environment variable instead of explicitly displaying it when configuring it.
+
+#### Vault-based storage of sensitive information
+
+Step 1: Create the corresponding configuration in Vault, which can be done with the following command.
+
+```shell
+vault kv put apisix/jack auth-key=value
+```
+
+Step 2: Add the Secret resource via the Admin API and configure the Vault's address and other connection information.
+
+```shell
+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"
+}'
+```
+
+Step 3: Refer to the APISIX Secret resource in the `key-auth` plugin and populate the location in the Vault with the following configuration.
+
+```shell
+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"
+ }
+ }
+}'
+```
+
+With the above steps, you can save the key configuration in the `key-auth` plugin in the Vault instead of explicitly displaying it when configuring it.
Review Comment:
```suggestion
With the above steps, you can save the key configuration in the `key-auth` plugin in the `Vault` instead of explicitly displaying it when configuring it.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [apisix-website] SkyeYoung commented on a diff in pull request #1461: docs: add APISIX 3.1.0 release blog
Posted by GitBox <gi...@apache.org>.
SkyeYoung commented on code in PR #1461:
URL: https://github.com/apache/apisix-website/pull/1461#discussion_r1059209978
##########
blog/en/blog/2022/12/30/release-apache-apisix-3.1.0.md:
##########
@@ -0,0 +1,220 @@
+---
+title: "Release Apache APISIX 3.1.0"
+authors:
+ - name: "Zexuan Luo"
+ title: "Author"
+ url: "https://github.com/spacewander"
+ image_url: "https://github.com/spacewander.png"
+ - name: "Sylvia"
+ title: "Technical Writer"
+ url: "https://github.com/SylviaBABY"
+ image_url: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- Apache APISIX
+- security
+- Custom plugin
+- gRPC
+- Consul
+description: Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level, and adds a built-in debugging plugin to optimize the experience of using APISIX.
+tags: [Community]
+---
+
+> Apache APISIX 3.1.0 is officially released! This version brings a lot of functional support on the security level, and adds a built-in debugging plugin to optimize the experience of using APISIX.
+
+<!--truncate-->
+
+After a month, a new version is here. This time APISIX 3.1.0 is the first new version since the big 3.0 release. As always, in the new era of 3.x, we present you with more new features in each version.
+
+This release, 3.1.0, adds support for encrypted storage of plugin configurations and storage on external security services, focusing on enabling users to use their configurations more securely and with greater confidence. On top of this, we have also introduced several new features designed to optimize your experience with APISIX.
+
+## New feature: encrypted storage of plugin configuration
+
+The new version supports encrypted storage of plugin-specific fields in etcd.
+
+In previous versions, APISIX provided a `key_encrypt_salt` configuration item to support encryption of SSL keys stored inside etcd to avoid storing private key data in plaintext.
+
+After all, for sensitive data such as private keys, one less place to store plaintext can provide more peace of mind. So for other equally sensitive configurations, such as the secret in the `jwt-auth` plugin, can we also encrypt it to avoid storing it in plaintext in etcd?
+
+Version 3.1 extends the encrypted storage feature to other fields. With this feature, we can specify the fields that need to be encrypted on a particular plugin and then turn on encryption in the config.yaml file to avoid storing plaintext.
+
+As an example, we add the following token to the `jwt-auth` plugin.
+
+```lua
+ encrypt_fields = {"secret", "private_key"},
+```
+
+When we enable encryption of fields in `config.yaml`:
+
+```yaml
+apisix:
+ data_encryption:
+ enable: true
+ keyring:
+ - edd1c9f0985e76a2
+```
+
+Then the secret and private_key in the configuration of the `jwt-auth` plugin written to etcd will be stored encrypted. The configuration seen via `etcdctl get --prefix /` will be something like ""secret": "77+NmbYqNfN+oL..."" Instead of the original configuration information, this is the data.
+
+## `New feature: storing sensitive information in an external security service
Review Comment:
```suggestion
## New feature: storing sensitive information in an external security service
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org