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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to