moonming opened a new issue, #1033:
URL: https://github.com/apache/apisix-helm-chart/issues/1033
## Summary
APISIX encrypts sensitive plugin fields before storing them (for example the
credentials of authentication plugins), using `apisix.data_encryption.keyring`.
The built-in default keyring is a fixed, public value. The `apisix` chart used
to expose this setting (#622), but the option was dropped when the v2 chart was
promoted (#738). Today every install uses the public default keyring unless the
user switches to `apisix.fullCustomConfig`.
## Current behavior
- APISIX defaults to `enable_encrypt_fields = true` and `keyring = {
"qeddd145sfvddff3", "edd1c9f0985e76a2" }`
([apisix/cli/config.lua#L79-L82](https://github.com/apache/apisix/blob/2b6d519a01e446b5b1d98168cedf9a7a4daa40b6/apisix/cli/config.lua#L79-L82)).
- Chart master
[`60efe58`](https://github.com/apache/apisix-helm-chart/tree/60efe5831a95e39b539d9ba2b6fdd2342e4c1bf4)
has no `data_encryption` value or template. A default render (`helm template`,
Helm 4.2.4) produces a config without `data_encryption`, so the defaults above
apply.
- `apisix.data_encryption.keyring` was added in #622 (2023-09-27) and is not
present after #738 (2024-03-20).
## Why it matters
Encryption at rest only protects the data if the key is secret. With the
public default keyring, anyone who can read the stored configuration can
decrypt these fields. With the default etcd deployment, that currently means
any pod in the cluster (see #1032).
The keyring also cannot change freely. APISIX encrypts with the first key
and tries every key when decrypting
([apisix/core/data_encryption.lua#L73-L115](https://github.com/apache/apisix/blob/2b6d519a01e446b5b1d98168cedf9a7a4daa40b6/apisix/core/data_encryption.lua#L73-L115)).
Replacing the keyring without keeping the old key makes existing encrypted
data unreadable, so a rotation has to add the new key first and keep the old
one until the data is re-encrypted.
## Suggested direction
- Bring back a `data_encryption` value (the keyring and
`enable_encrypt_fields`), plus an option to read the keyring from an existing
Secret.
- Decide whether the chart should generate a keyring when none is given. If
it does, it must never regenerate one silently: fail on upgrade when the
generated Secret is missing, and require an existing Secret with tools that
render offline (for example Argo CD, where `lookup` returns nothing).
- Reject the public default keyring values when they are set explicitly.
## Related: deprecated apisix-dashboard chart
The deprecated `apisix-dashboard` chart (`deprecated: true` since #831)
still defaults to `authentication.secret: secret` and the user `admin` /
`admin`
([values.yaml#L120-L128](https://github.com/apache/apisix-helm-chart/blob/60efe5831a95e39b539d9ba2b6fdd2342e4c1bf4/charts/apisix-dashboard/values.yaml#L120-L128)).
Since that chart is deprecated, documenting this, or removing the chart, may
be enough.
--
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]
