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