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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
