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]
