fix: rename EDA_SECRET_KEY to EDA_DB_ROTATION_KEY in rotate command#1610
fix: rename EDA_SECRET_KEY to EDA_DB_ROTATION_KEY in rotate command#1610B-Whitt wants to merge 1 commit into
Conversation
EDA_SECRET_KEY serves double duty via dynaconf: it sets settings.SECRET_KEY (the decryption key) AND is read by rotate_db_encryption_key as the new encryption key. Old == new causes "rotation aborted". This mirrors AWX's pattern of using TOWER_SECRET_KEY (not AWX_SECRET_KEY) to avoid the same collision. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
/run-e2e |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/aap_eda/core/management/commands/rotate_db_encryption_key.py`:
- Around line 111-115: The custom-key path in rotate_db_encryption_key currently
only reads EDA_DB_ROTATION_KEY, but downstream deployments still provide
EDA_SECRET_KEY, so the command will fail in those environments. Update the
affected deployment wiring to set EDA_DB_ROTATION_KEY alongside the existing
consumers, or add a temporary fallback in the command’s new_key lookup so it can
still use EDA_SECRET_KEY during the migration. Reference the
rotate_db_encryption_key command and the manifests that inject the env var to
keep the rename consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 910fde76-0176-4fa7-a73b-4bd3b03900cc
📒 Files selected for processing (2)
src/aap_eda/core/management/commands/rotate_db_encryption_key.pytests/unit/commands/test_rotate_db_encryption_key.py
| self.new_key = os.environ.get("EDA_DB_ROTATION_KEY") | ||
| if not self.new_key: | ||
| raise CommandError( | ||
| "--use-custom-key was specified but " | ||
| "EDA_SECRET_KEY is not set in the environment." | ||
| "EDA_DB_ROTATION_KEY is not set in the environment." |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Update the env wiring with this rename.
--use-custom-key now hard-requires EDA_DB_ROTATION_KEY, but the supplied downstream consumers still inject only EDA_SECRET_KEY (tools/deploy/eda-api/deployment.yaml:33-40, tools/docker/docker-compose-dev.yaml:20-24). In those environments this command will now fail every time on the custom-key path. Please either update those manifests in the same PR or keep a temporary fallback to EDA_SECRET_KEY during the migration.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/aap_eda/core/management/commands/rotate_db_encryption_key.py` around
lines 111 - 115, The custom-key path in rotate_db_encryption_key currently only
reads EDA_DB_ROTATION_KEY, but downstream deployments still provide
EDA_SECRET_KEY, so the command will fail in those environments. Update the
affected deployment wiring to set EDA_DB_ROTATION_KEY alongside the existing
consumers, or add a temporary fallback in the command’s new_key lookup so it can
still use EDA_SECRET_KEY during the migration. Reference the
rotate_db_encryption_key command and the manifests that inject the env var to
keep the rename consistent.
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #1610 +/- ##
=======================================
Coverage 92.48% 92.48%
=======================================
Files 244 244
Lines 11244 11244
=======================================
Hits 10399 10399
Misses 845 845
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
2 participants
Summary
rotate_db_encryption_key --use-custom-keyfromEDA_SECRET_KEYtoEDA_DB_ROTATION_KEYEDA_SECRET_KEYserves double duty via dynaconf: it setssettings.SECRET_KEY(the decryption key) AND is read by the command as the new encryption key — making old == new, which aborts rotationTOWER_SECRET_KEY(notAWX_SECRET_KEY) to avoid the same dynaconf prefix collisionProblem
When running:
EDA_SECRET_KEY='new-key' aap-eda-manage rotate_db_encryption_key --use-custom-keyDynaconf loads
EDA_SECRET_KEYassettings.SECRET_KEYat process startup. The command then readssettings.SECRET_KEYas the old key andos.environ['EDA_SECRET_KEY']as the new key — they're identical, so rotation aborts with "New encryption key is identical to the current SECRET_KEY."Validated against a live AAP 2.7 instance.
Fix
Rename the env var to
EDA_DB_ROTATION_KEYwhich does not collide with dynaconf'sEDA_prefix mapping tosettings.SECRET_KEY.Test plan
EDA_DB_ROTATION_KEYdoes not overridesettings.SECRET_KEYRelated
TOWER_SECRET_KEYAssisted by Claude Code
Summary by CodeRabbit