You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "thatguyatgithub (via GitHub)" <gi...@apache.org> on 2026/02/10 13:24:41 UTC
[I] superset re-encrypt-secrets effectively not working [superset]
thatguyatgithub opened a new issue, #37842:
URL: https://github.com/apache/superset/issues/37842
### Bug description
As instructed by [documentation here](https://superset.apache.org/docs/configuration/configuring-superset/#rotating-to-a-newer-secret_key), I've change the `superset_config.py` so that PREVIOUS_SECRET_KEY contained the intended-to-be-replaced secret and created a new `SECRET_KEY` entry with a new key.
After starting superset main process, I executed `superset re-encrypt-secrets`, which did not complain at all about anything.
```
# superset --debug re-encrypt-secrets
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]
2026-02-10 13:15:28,470:DEBUG:superset.utils.logging_configurator:logging was configured successfully
2026-02-10 13:15:28,537:DEBUG:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
2026-02-10 13:15:28,543:DEBUG:superset.initialization:Setting database isolation level to READ COMMITTED
/app/.venv/lib/python3.10/site-packages/flask_limiter/extension.py:324: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
warnings.warn(
2026-02-10 13:15:29,181:INFO:alembic.runtime.migration:Context impl PostgresqlImpl.
2026-02-10 13:15:29,181:INFO:alembic.runtime.migration:Will assume transactional DDL.
2026-02-10 13:15:29,714:INFO:superset.app:Syncing configuration to database...
2026-02-10 13:15:29,724:DEBUG:superset.commands.theme.seed:Updated system theme: THEME_DEFAULT
2026-02-10 13:15:29,733:DEBUG:superset.commands.theme.seed:Updated system theme: THEME_DARK
2026-02-10 13:15:29,735:INFO:superset.app:Configuration sync to database completed successfully
2026-02-10 13:15:30,516:INFO:superset.utils.encrypt:Collecting info for re encryption
2026-02-10 13:15:30,517:INFO:superset.utils.encrypt:All tables processed
```
But after that, restarting the superset process produced any opening of secrets related to databases to fail
```
File "/app/.venv/lib/python3.10/site-packages/sqlalchemy_utils/types/encrypted/encrypted_type.py", line 424, in process_result_value
decrypted_value = self.engine.decrypt(value)
File "/app/.venv/lib/python3.10/site-packages/sqlalchemy_utils/types/encrypted/encrypted_type.py", line 128, in decrypt
raise ValueError('Invalid decryption key')
ValueError: Invalid decryption key
```
### Screenshots/recordings
_No response_
### Superset version
master / latest-dev
### Python version
3.9
### Node version
16
### Browser
Chrome
### Additional context
_No response_
### Checklist
- [ ] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [ ] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
--
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@superset.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "thatguyatgithub (via GitHub)" <gi...@apache.org>.
thatguyatgithub commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3879092095
thanks @hainenber
Yes, literally same output, from the time it takes it appears to an untrained eye like mine that it does not actually perform anything since it almost immediately finishes.
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "thatguyatgithub (via GitHub)" <gi...@apache.org>.
thatguyatgithub commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3877876473
The bot missinterpreted the output. The `re-encrypt-secrets` did NOT throw any errors, it finished with exit code 0 and no errors, as shown before:
```
# superset --debug re-encrypt-secrets
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]
2026-02-10 13:15:28,470:DEBUG:superset.utils.logging_configurator:logging was configured successfully
2026-02-10 13:15:28,537:DEBUG:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
2026-02-10 13:15:28,543:DEBUG:superset.initialization:Setting database isolation level to READ COMMITTED
/app/.venv/lib/python3.10/site-packages/flask_limiter/extension.py:324: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
warnings.warn(
2026-02-10 13:15:29,181:INFO:alembic.runtime.migration:Context impl PostgresqlImpl.
2026-02-10 13:15:29,181:INFO:alembic.runtime.migration:Will assume transactional DDL.
2026-02-10 13:15:29,714:INFO:superset.app:Syncing configuration to database...
2026-02-10 13:15:29,724:DEBUG:superset.commands.theme.seed:Updated system theme: THEME_DEFAULT
2026-02-10 13:15:29,733:DEBUG:superset.commands.theme.seed:Updated system theme: THEME_DARK
2026-02-10 13:15:29,735:INFO:superset.app:Configuration sync to database completed successfully
2026-02-10 13:15:30,516:INFO:superset.utils.encrypt:Collecting info for re encryption
2026-02-10 13:15:30,517:INFO:superset.utils.encrypt:All tables processed
```
The errors raise at the main superset node process when any operation from the webui attempts to gather either DB connections or anything like that.
If I go back and restore the superset_config.py with the original SECRET_KEY, everything goes back to normal, meaning
It looks like `superset re-encrypt-secrets` is not performing any actions at all from the get go.
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "hainenber (via GitHub)" <gi...@apache.org>.
hainenber commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3878456607
Can you run `superset re-encypt-secrets` without the `--debug` arg? You can use SUPERSET_LOG_LEVEL env var to toggle logging level.
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "jcjveraa (via GitHub)" <gi...@apache.org>.
jcjveraa commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3890624171
Hi there, chipping in as I'm hitting the exact same with a fresh install, I suggest this is a rather critical bug.
Reproducer:
Set up a fresh install using the Helm chart, with a custom override in the helm chart for setting the key. I have verified that this key is indeed the one loaded using the 'get current config' commands [from here](https://superset.apache.org/docs/configuration/configuring-superset/#rotating-to-a-newer-secret_key).
```yaml
configOverrides:
secretKey: |
# ref https://superset.apache.org/docs/security/securing_superset/#superset_secret_key-management-critical
SECRET_KEY = 'thisIsABadKey'
```
Try to rotate the key by setting these
```yaml
configOverrides:
secretKey: |
# ref https://superset.apache.org/docs/security/securing_superset/#superset_secret_key-management-critical
PREVIOUS_SECRET_KEY = 'thisIsABadKey'
SECRET_KEY = '2cM+byann7KQHENZ2CTOWX2RcHYqMBlR7HPKitTXyU90Libl+QeKmDNb' # randomly generated for this example of course
```
verify again that these variables are loaded in the flask app, and run `superset re-encrypt-secrets`.
Result the same as the poster of this issue: it finishes rather quickly with no errors, but when I try to load data it fails. After rolling back to the old `thisIsABadKey` I can load data again.
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
dosubot[bot] commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3877908684
<!-- Answer -->
This behavior is almost always due to a config or environment mismatch: the re-encrypt command only updates secrets if it can decrypt them with the PREVIOUS_SECRET_KEY, and will silently skip rows if it can't. If reverting to the old SECRET_KEY restores access, your secrets were never re-encrypted—they're still using the old key, and the rotation didn't actually happen.
Here’s what to check and try:
- Make sure the PREVIOUS_SECRET_KEY is *exactly* the key that was used to encrypt your secrets (no typos, whitespace, or encoding issues). Even a single character difference will break decryption [reference](https://github.com/apache/superset/issues/36139).
- In recent Superset versions, the SUPERSET_SECRET_KEY environment variable takes precedence over SECRET_KEY in the config file. Double-check which one is actually being loaded by running `superset shell` and printing both keys:
```python
from flask import current_app
print(current_app.config["SECRET_KEY"])
print(current_app.config.get("PREVIOUS_SECRET_KEY"))
```
Do this in the same environment/container where you run the re-encrypt command and where you start the main Superset process [reference](https://github.com/apache/superset/discussions/23598).
- Try running the command with the CLI option to rule out config loading issues:
```
superset re-encrypt-secrets --previous_secret_key=your_previous_secret_key
```
- Increase the logging level for `superset.utils.encrypt` to DEBUG to see if any rows are being skipped or if the current key is able to decrypt values (which would cause the command to skip re-encryption for those rows) [reference](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/utils/encrypt.py#L92-L208).
- If you’re using Docker, Helm, or Kubernetes, ensure there’s only one configOverrides block, and that your config isn’t mounted read-only [reference](https://github.com/apache/superset/discussions/23598).
- If all else fails and you can’t recover the previous key, the only recovery is to clear encrypted fields (like `password` and `encrypted_extra` in the `dbs` table) and re-enter credentials [reference](https://github.com/apache/superset/issues/33595).
This is a common pain point, especially in containerized environments where config/env propagation can be tricky. If you confirm the keys are loaded as expected and still see no effect, it’s almost certainly a key mismatch or config not being picked up at runtime.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/cc37f8f0-abc1-427e-ab78-627b7aff4af9?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/cc37f8f0-abc1-427e-ab78-627b7aff4af9?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/cc37f8f0-abc1-427e-ab78-627b7aff4af9?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/cc37f8f0-abc1-427e-ab78-627b7aff4af9?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/cc37f8f0-abc1-427e-ab78-627b7aff4af9?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/cc37f8f0-abc1-427e-ab78-627b7aff4af9?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/cc37f8f0-abc1-427e-ab78-627b7aff4af9?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=This%20behavior%20is%20almost%20always%20due%20to%20a%20config%20or%20environment%20mismatch%3A%20the%20re-encrypt%20command%20only%20updates%20secrets%20if%20it%20can%20decrypt%20them%20with%20the%20PREVIOUS_SECRET_KEY%2C%20and%20will%20silently%20skip%20rows%20if%20it%20can%27t.%20If%20reverting%20to%20the%20old%20SECRET_KEY%20restores%20access%2C%20your%20secrets%20were%20never%20re-encrypted%E2%80%94they%27re%20still%20using%20the%20old%20key%2C%20and%20the%20rotation%20didn%27t%20actually%20happen.%0A%0AHere%E2%80%99s%20what%20to%20check%20and%20try%3A%0A%0A-%20Make%20sure%20the%20PREVIOUS_SECRET_KEY%20is%20%2Aexactly%2A%20the%20key%20that%20was%20used%20to%20encrypt%20your%20secrets%20%28no%20typos%2C%20whitespace%2C%20or%20encoding%20issues%
29.%20Even%20a%20single%20character%20difference%20will%20break%20decryption%C2%A0%5Breference%5D%28https%3A//github.com/apache/superset/issues/36139%29.%0A-%20In%20recent%20Superset%20versions%2C%20the%20SUPERSET_SECRET_KEY%20environment%20variable%20takes%20precedence%20over%20SECRET_KEY%20in%20the%20config%20file.%20Double-check%20which%20one%20is%20actually%20being%20loaded%20by%20running%20%60superset%20shell%60%20and%20printing%20both%20keys%3A%0A%20%20%60%60%60python%0A%20%20from%20flask%20import%20current_app%0A%20%20print%28current_app.config%5B%22SECRET_KEY%22%5D%29%0A%20%20print%28current_app.config.get%28%22PREVIOUS_SECRET_KEY%22%29%29%0A%20%20%60%60%60%0A%20%20Do%20this%20in%20the%20same%20environment/container%20where%20you%20run%20the%20re-encrypt%20command%20and%20where%20you%20start%20the%20main%20Superset%20process%C2%A0%5Breference%5D%28https%3A//github.com/apache/superset/discussions/23598%29.%0A-%20Try%20running%20the%20command%20with%20the%20CLI%20option%20to%2
0rule%20out%20config%20loading%20issues%3A%0A%20%20%60%60%60%0A%20%20superset%20re-encrypt-secrets%20--previous_secret_key%3Dyour_previous_secret_key%0A%20%20%60%60%60%0A-%20Increase%20the%20logging%20level%20for%20%60superset.utils.encrypt%60%20to%20DEBUG%20to%20see%20if%20any%20rows%20are%20being%20skipped%20or%20if%20the%20current%20key%20is%20able%20to%20decrypt%20values%20%28which%20would%20cause%20the%20command%20to%20skip%20re-encryption%20for%20those%20rows%29%C2%A0%5Breference%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/utils/encrypt.py%23L92-L208%29.%0A-%20If%20you%E2%80%99re%20using%20Docker%2C%20Helm%2C%20or%20Kubernetes%2C%20ensure%20there%E2%80%99s%20only%20one%20configOverrides%20block%2C%20and%20that%20your%20config%20isn%E2%80%99t%20mounted%20read-only%C2%A0%5Breference%5D%28https%3A//github.com/apache/superset/discussions/23598%29.%0A-%20If%20all%20else%20fails%20and%20you%20can%E2%80%99t%20recover%20the%20previo
us%20key%2C%20the%20only%20recovery%20is%20to%20clear%20encrypted%20fields%20%28like%20%60password%60%20and%20%60encrypted_extra%60%20in%20the%20%60dbs%60%20table%29%20and%20re-enter%20credentials%C2%A0%5Breference%5D%28https%3A//github.com/apache/superset/issues/33595%29.%0A%0AThis%20is%20a%20common%20pain%20point%2C%20especially%20in%20containerized%20environments%20where%20config/env%20propagation%20can%20be%20tricky.%20If%20you%20confirm%20the%20keys%20are%20loaded%20as%20expected%20and%20still%20see%20no%20effect%2C%20it%E2%80%99s%20almost%20certainly%20a%20key%20mismatch%20or%20config%20not%20being%20picked%20up%20at%20runtime.) [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/issues/37842)
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "rusackas (via GitHub)" <gi...@apache.org>.
rusackas closed issue #37842: superset re-encrypt-secrets effectively not working
URL: https://github.com/apache/superset/issues/37842
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
dosubot[bot] commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3878452405
<!-- Answer -->
Given that both keys are correct and visible in the config, but re-encryption does not occur and no errors are shown, this matches a known behavior in Superset: the re-encryption command will silently skip any row if the current key can already decrypt the value, or if the previous key fails and the current key also fails, it raises an error. If reverting to the old key restores access, your secrets are still encrypted with the old key and the rotation did not actually happen. This can occur if the previous key used during re-encryption was not the actual key used to encrypt the secrets, even if it appears correct in the config or shell ([reference](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/utils/encrypt.py#L100-L208)).
To diagnose further:
- Enable DEBUG-level logging for `superset.utils.encrypt` when running `superset re-encrypt-secrets` to see which rows/columns are being processed or skipped.
- Manually inspect the encrypted fields (like `dbs.password` and `dbs.encrypted_extra`) in your metadata DB using a Python shell, and try decrypting them with both the old and new keys to confirm which key actually works.
- Double-check that the environment variable `SUPERSET_SECRET_KEY` is not overriding your config file, as it takes precedence over `SECRET_KEY` ([reference](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/config.py#L191-L2008)).
- If you are in a containerized or Helm environment, ensure only one configOverrides block is present and that your config is not mounted read-only.
If all diagnostics confirm the keys are correct and the process still skips all rows, the only recovery is to clear encrypted fields in the database and re-enter credentials ([reference](https://github.com/apache/superset/issues/33595)). This issue is known to affect some Kubernetes/Helm setups even when the keys appear correct in the shell.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/ba613902-8aa7-4025-9704-cf016feffe24?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/ba613902-8aa7-4025-9704-cf016feffe24?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/ba613902-8aa7-4025-9704-cf016feffe24?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/ba613902-8aa7-4025-9704-cf016feffe24?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/ba613902-8aa7-4025-9704-cf016feffe24?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/ba613902-8aa7-4025-9704-cf016feffe24?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/ba613902-8aa7-4025-9704-cf016feffe24?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=Given%20that%20both%20keys%20are%20correct%20and%20visible%20in%20the%20config%2C%20but%20re-encryption%20does%20not%20occur%20and%20no%20errors%20are%20shown%2C%20this%20matches%20a%20known%20behavior%20in%20Superset%3A%20the%20re-encryption%20command%20will%20silently%20skip%20any%20row%20if%20the%20current%20key%20can%20already%20decrypt%20the%20value%2C%20or%20if%20the%20previous%20key%20fails%20and%20the%20current%20key%20also%20fails%2C%20it%20raises%20an%20error.%20If%20reverting%20to%20the%20old%20key%20restores%20access%2C%20your%20secrets%20are%20still%20encrypted%20with%20the%20old%20key%20and%20the%20rotation%20did%20not%20actually%20happen.%20This%20can%20occur%20if%20the%20previous%20key%20used%20during%20re-encryption%20was%20not%20t
he%20actual%20key%20used%20to%20encrypt%20the%20secrets%2C%20even%20if%20it%20appears%20correct%20in%20the%20config%20or%20shell%C2%A0%28%5Breference%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/utils/encrypt.py%23L100-L208%29%29.%0A%0ATo%20diagnose%20further%3A%0A%0A-%20Enable%20DEBUG-level%20logging%20for%20%60superset.utils.encrypt%60%20when%20running%20%60superset%20re-encrypt-secrets%60%20to%20see%20which%20rows/columns%20are%20being%20processed%20or%20skipped.%0A-%20Manually%20inspect%20the%20encrypted%20fields%20%28like%20%60dbs.password%60%20and%20%60dbs.encrypted_extra%60%29%20in%20your%20metadata%20DB%20using%20a%20Python%20shell%2C%20and%20try%20decrypting%20them%20with%20both%20the%20old%20and%20new%20keys%20to%20confirm%20which%20key%20actually%20works.%0A-%20Double-check%20that%20the%20environment%20variable%20%60SUPERSET_SECRET_KEY%60%20is%20not%20overriding%20your%20config%20file%2C%20as%20it%20takes%20precedence%20
over%20%60SECRET_KEY%60%20%28%5Breference%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/config.py%23L191-L2008%29%29.%0A-%20If%20you%20are%20in%20a%20containerized%20or%20Helm%20environment%2C%20ensure%20only%20one%20configOverrides%20block%20is%20present%20and%20that%20your%20config%20is%20not%20mounted%20read-only.%0A%0AIf%20all%20diagnostics%20confirm%20the%20keys%20are%20correct%20and%20the%20process%20still%20skips%20all%20rows%2C%20the%20only%20recovery%20is%20to%20clear%20encrypted%20fields%20in%20the%20database%20and%20re-enter%20credentials%20%28%5Breference%5D%28https%3A//github.com/apache/superset/issues/33595%29%29.%20This%20issue%20is%20known%20to%20affect%20some%20Kubernetes/Helm%20setups%20even%20when%20the%20keys%20appear%20correct%20in%20the%20shell.) [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/issues/37842)
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "thatguyatgithub (via GitHub)" <gi...@apache.org>.
thatguyatgithub commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3878311221
No useful, as previously stated, PREVIOUS_SECRET_KEY and SECRET_KEY read from `flask import current_app` are and were always shown as expected. The rotation does not seem to take place at all.
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "Ujjwaljain16 (via GitHub)" <gi...@apache.org>.
Ujjwaljain16 commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3903247968
I’ve done a deep dive into this and believe I’ve found the root cause.
`EncryptedType` is currently initialized with a static value of `SECRET_KEY` at model import time. That means the encryption engine can stay permanently bound to the old key, even after rotation.
During re-encrypt-secrets:
Decryption with PREVIOUS_SECRET_KEY succeeds
Re-encryption uses the model’s existing EncryptedType
If that instance still holds the old key, the data gets written back unchanged
The command exits successfully but effectively does nothing
After restart with the new SECRET_KEY, decryption fails which matches what everyone is seeing.
The fix is to pass a callable instead of a static string:
```python
EncryptedType(*args, lambda: app_config["SECRET_KEY"], **kwargs)
```
`sqlalchemy-utils` supports this natively and resolves the key on every encrypt/decrypt call, so it ensures the correct key is always used at runtime.
I’ll open a PR with this change and updated tests shortly.
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "dosubot[bot] (via GitHub)" <gi...@apache.org>.
dosubot[bot] commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3877623102
<!-- Answer -->
The "Invalid decryption key" error after running `superset re-encrypt-secrets` is almost always due to a mismatch or misconfiguration of the keys used for rotation. The re-encryption command tries to decrypt each secret with the previous key, and if that fails, with the current key. If neither works, you get the error; if the current key works, it silently skips re-encryption for that row, which can make the command appear to succeed even if nothing was actually re-encrypted ([source](https://github.com/apache/superset/discussions/23598), [source](https://github.com/apache/superset/issues/36139), [source](https://github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/utils/encrypt.py#L92-L208)).
Here’s a checklist to help you troubleshoot:
1. **Double-check your keys**: Make sure `PREVIOUS_SECRET_KEY` is exactly the key that was used to encrypt your secrets, and `SECRET_KEY` (or `SUPERSET_SECRET_KEY` env var, which is now preferred) is your new key. Even a single character difference or whitespace will break decryption ([source](https://github.com/apache/superset/discussions/36340#discussioncomment-15122338)).
2. **Verify loaded values**: Use `superset shell` and run:
```python
from flask import current_app
print(current_app.config["SECRET_KEY"])
print(current_app.config.get("PREVIOUS_SECRET_KEY"))
```
Do this both in the environment where you run the re-encrypt command and after restart, to confirm the correct keys are loaded.
3. **Try the CLI option**: You can pass the previous key directly to the command:
```
superset re-encrypt-secrets --previous_secret_key=your_previous_secret_key
```
This can help if your config file isn’t being picked up as expected ([source](https://github.com/apache/superset/issues/32375)).
4. **Restart all processes**: After rotation, make sure all Superset processes/pods are restarted so they pick up the new key(s).
5. **Check for config issues**: If you’re using Helm or Kubernetes, ensure only one `configOverrides` block is present, and that your config is not mounted read-only if you need to update it ([source](https://github.com/apache/superset/discussions/23598)).
6. **If you can’t recover the previous key**: The only recovery is to clear encrypted fields (like `password` and `encrypted_extra` in the `dbs` table) and re-enter credentials ([source](https://github.com/apache/superset/discussions/36340#discussioncomment-15122338)).
If you follow these steps and still see the error, please share the output of the config check from `superset shell` and any relevant logs. That will help pinpoint where the key mismatch is happening.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback/099761c7-4670-4327-b97c-87cca955ab86?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/099761c7-4670-4327-b97c-87cca955ab86?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/099761c7-4670-4327-b97c-87cca955ab86?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/099761c7-4670-4327-b97c-87cca955ab86?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/099761c7-4670-4327-b97c-87cca955ab86?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/099761c7-4670-4327-b97c-87cca955ab86?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/099761c7-4670-4327-b97c-87cca955ab86?feedback_type=other)</sup>
[](https://app.dosu.dev/a28d3c7e-a9d3-459e-9fb6-3a6f9ff4f357/ask?utm_source=github) [](https://cursor.com/link/prompt?text=The%20%22Invalid%20decryption%20key%22%20error%20after%20running%20%60superset%20re-encrypt-secrets%60%20is%20almost%20always%20due%20to%20a%20mismatch%20or%20misconfiguration%20of%20the%20keys%20used%20for%20rotation.%20The%20re-encryption%20command%20tries%20to%20decrypt%20each%20secret%20with%20the%20previous%20key%2C%20and%20if%20that%20fails%2C%20with%20the%20current%20key.%20If%20neither%20works%2C%20you%20get%20the%20error%3B%20if%20the%20current%20key%20works%2C%20it%20silently%20skips%20re-encryption%20for%20that%20row%2C%20which%20can%20make%20the%20command%20appear%20to%20succeed%20even%20if%20nothing%20was%20actually%20re-encrypted%C2%A0%28%5Bsource%5D%28https%3A//github.com/apache/superset/discussions/23598%29%2C%20%5Bsource%5D%28https
%3A//github.com/apache/superset/issues/36139%29%2C%20%5Bsource%5D%28https%3A//github.com/apache/superset/blob/829e4d92d91ceae4b43b1ed3b063ffe45377799c/superset/utils/encrypt.py%23L92-L208%29%29.%0A%0AHere%E2%80%99s%20a%20checklist%20to%20help%20you%20troubleshoot%3A%0A%0A1.%20%2A%2ADouble-check%20your%20keys%2A%2A%3A%20Make%20sure%20%60PREVIOUS_SECRET_KEY%60%20is%20exactly%20the%20key%20that%20was%20used%20to%20encrypt%20your%20secrets%2C%20and%20%60SECRET_KEY%60%20%28or%20%60SUPERSET_SECRET_KEY%60%20env%20var%2C%20which%20is%20now%20preferred%29%20is%20your%20new%20key.%20Even%20a%20single%20character%20difference%20or%20whitespace%20will%20break%20decryption%C2%A0%28%5Bsource%5D%28https%3A//github.com/apache/superset/discussions/36340%23discussioncomment-15122338%29%29.%0A2.%20%2A%2AVerify%20loaded%20values%2A%2A%3A%20Use%20%60superset%20shell%60%20and%20run%3A%0A%20%20%20%60%60%60python%0A%20%20%20from%20flask%20import%20current_app%0A%20%20%20print%28current_app.config%5B%22SECR
ET_KEY%22%5D%29%0A%20%20%20print%28current_app.config.get%28%22PREVIOUS_SECRET_KEY%22%29%29%0A%20%20%20%60%60%60%0A%20%20%20Do%20this%20both%20in%20the%20environment%20where%20you%20run%20the%20re-encrypt%20command%20and%20after%20restart%2C%20to%20confirm%20the%20correct%20keys%20are%20loaded.%0A3.%20%2A%2ATry%20the%20CLI%20option%2A%2A%3A%20You%20can%20pass%20the%20previous%20key%20directly%20to%20the%20command%3A%0A%20%20%20%60%60%60%0A%20%20%20superset%20re-encrypt-secrets%20--previous_secret_key%3Dyour_previous_secret_key%0A%20%20%20%60%60%60%0A%20%20%20This%20can%20help%20if%20your%20config%20file%20isn%E2%80%99t%20being%20picked%20up%20as%20expected%C2%A0%28%5Bsource%5D%28https%3A//github.com/apache/superset/issues/32375%29%29.%0A4.%20%2A%2ARestart%20all%20processes%2A%2A%3A%20After%20rotation%2C%20make%20sure%20all%20Superset%20processes/pods%20are%20restarted%20so%20they%20pick%20up%20the%20new%20key%28s%29.%0A5.%20%2A%2ACheck%20for%20config%20issues%2A%2A%3A%20If%20you%E2%
80%99re%20using%20Helm%20or%20Kubernetes%2C%20ensure%20only%20one%20%60configOverrides%60%20block%20is%20present%2C%20and%20that%20your%20config%20is%20not%20mounted%20read-only%20if%20you%20need%20to%20update%20it%C2%A0%28%5Bsource%5D%28https%3A//github.com/apache/superset/discussions/23598%29%29.%0A6.%20%2A%2AIf%20you%20can%E2%80%99t%20recover%20the%20previous%20key%2A%2A%3A%20The%20only%20recovery%20is%20to%20clear%20encrypted%20fields%20%28like%20%60password%60%20and%20%60encrypted_extra%60%20in%20the%20%60dbs%60%20table%29%20and%20re-enter%20credentials%C2%A0%28%5Bsource%5D%28https%3A//github.com/apache/superset/discussions/36340%23discussioncomment-15122338%29%29.%0A%0AIf%20you%20follow%20these%20steps%20and%20still%20see%20the%20error%2C%20please%20share%20the%20output%20of%20the%20config%20check%20from%20%60superset%20shell%60%20and%20any%20relevant%20logs.%20That%20will%20help%20pinpoint%20where%20the%20key%20mismatch%20is%20happening.) [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/apache/superset/issues/37842)
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [I] superset re-encrypt-secrets effectively not working [superset]
Posted by "jcjveraa (via GitHub)" <gi...@apache.org>.
jcjveraa commented on issue #37842:
URL: https://github.com/apache/superset/issues/37842#issuecomment-3890688837
> Can you run `superset re-encypt-secrets` without the `--debug` arg? You can use SUPERSET_LOG_LEVEL env var to toggle logging level.
>
> Edit: I can sorta reproduce the issue. Inspecting further
By the way, `SUPERSET_LOG_LEVEL` is also not doing anything, perhaps that helps debug somehow? My pod was started with
`SUPERSET_LOG_LEVEL=DEBUG`, but no debug logging is happening - unless I specify the `--debug` flag directly.
```
$ env | grep SUPERSET_LOG_LEVEL
SUPERSET_LOG_LEVEL=DEBUG
$ superset re-encrypt-secrets
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]
2026-02-12 12:30:19,865:INFO:alembic.runtime.migration:Context impl PostgresqlImpl.
2026-02-12 12:30:19,866:INFO:alembic.runtime.migration:Will assume transactional DDL.
2026-02-12 12:30:20,303:INFO:superset.app:Syncing configuration to database...
2026-02-12 12:30:20,317:INFO:superset.app:Configuration sync to database completed successfully
2026-02-12 12:30:21,330:INFO:superset.utils.encrypt:Collecting info for re encryption
2026-02-12 12:30:21,331:INFO:superset.utils.encrypt:All tables processed
$ superset --debug re-encrypt-secrets
Loaded your LOCAL configuration at [/app/pythonpath/superset_config.py]
2026-02-12 12:30:38,176:DEBUG:superset.utils.logging_configurator:logging was configured successfully
2026-02-12 12:30:38,234:DEBUG:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
2026-02-12 12:30:38,251:DEBUG:superset.initialization:Setting database isolation level to READ COMMITTED
2026-02-12 12:30:39,049:INFO:alembic.runtime.migration:Context impl PostgresqlImpl.
2026-02-12 12:30:39,049:INFO:alembic.runtime.migration:Will assume transactional DDL.
2026-02-12 12:30:39,476:INFO:superset.app:Syncing configuration to database...
2026-02-12 12:30:39,484:DEBUG:superset.commands.theme.seed:Updated system theme: THEME_DEFAULT
2026-02-12 12:30:39,490:DEBUG:superset.commands.theme.seed:Updated system theme: THEME_DARK
2026-02-12 12:30:39,491:INFO:superset.app:Configuration sync to database completed successfully
2026-02-12 12:30:40,534:INFO:superset.utils.encrypt:Collecting info for re encryption
2026-02-12 12:30:40,535:INFO:superset.utils.encrypt:All tables processed
$
```
--
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@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org