Bug description
I originally set up a metadatabase using Docker Compose. In that environment, I rolled the key once without any issues. Now we are deploying Superset in Kubernetes.
I tried following the documented process for rolling the secret key.
configOverrides: my_override: | PREVIOUS_SECRET_KEY = 'YOUR_PREVIOUS_SECRET_KEY' SECRET_KEY = 'YOUR_OWN_RANDOM_GENERATED_SECRET_KEY' init: command: - /bin/sh - -c - | . {{ .Values.configMountPath }}/superset_bootstrap.sh superset re-encrypt-secrets . {{ .Values.configMountPath }}/superset_init.sh
When running superset re-encrypt-secrets, no error logs appear. However, the init command exits with an error code, stating that the decryption key is invalid. I also cannot use the application anymore—it shows “invalid decryption key” errors. Inside the Superset shell, both the old and new values for SECRET_KEY and PREVIOUS_SECRET_KEY are correct.
I also tried skipping the init script and performing the key rotation during runtime inside the Superset container. I let Python read the values from the environment variables and set them via the console. The Superset shell again returns the correct values. But when I access the application, I still get “wrong decryption key” errors.
If you need any more information about our setup, please let me know.
Screenshots/recordings
No response
Superset version
5.0.0
Python version
I don't know
Node version
I don't know
Browser
Firefox
Additional context
No response
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] 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.
Comment From: dosubot[bot]
Hi @TobSchwa94! I'm Dosu and I’m helping the superset team.
The "invalid decryption key" error during secret key rotation in Kubernetes usually means Superset can't decrypt existing secrets with the provided PREVIOUS_SECRET_KEY. Here are the most common pitfalls and how to address them:
- For Superset 5.0.0, set the new key using SUPERSET_SECRET_KEY (not just SECRET_KEY) in your environment or Helm values. The config reads SECRET_KEY from SUPERSET_SECRET_KEY in the environment, so using only SECRET_KEY may not work as expected reference.
- Make sure PREVIOUS_SECRET_KEY is exactly the key that was used to encrypt secrets in your metadata DB. If you originally set up with Docker Compose, double-check that you are using the same value as before.
- Only use a single configOverrides block in your Helm values.yaml. Multiple blocks can cause config issues and pod crashes reference.
- After updating the keys, ensure all Superset pods are restarted so they pick up the new environment variables.
- You can also pass the previous key directly to the re-encrypt command:
superset re-encrypt-secrets --previous_secret_key=your_previous_secret_keyreference. - If you still get errors, exec into the pod and run
envto confirm the environment variables are set as expected. Also, check pod logs for any stack traces or permission errors.
If you confirm all of the above and still see the error, please share the exact way you're setting these keys in your Helm values or manifests, and any relevant pod logs. This will help pinpoint if it's a config propagation issue or something else.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other