zmuxuny opened a new issue, #6023: URL: https://github.com/apache/rocketmq-dashboard/issues/6023
### Before Creating the Enhancement Request - [x] I have confirmed this is an enhancement rather than a bug or a new feature. - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and believe this is not a duplicate. ### Summary ## Tracking continuation (2026-10-10) This replaces #5373, which was automatically closed by github-actions[bot] for inactivity on 2026-10-10. The issue's technical/design scope is preserved. Its current discussion and related issue/PR searches were rechecked before creating this continuation; no existing replacement issue was found. The encryption/key-lifecycle decision remains open. Existing PR #5377 only corrects documentation of current credential storage; it does not implement encryption or resolve this design question. No encryption rollout or key policy has been approved. The original report below retains its stated baseline and historical verification. It does not claim fresh test results, fully green CI, or new maintainer approval. Discussion and prior evidence remain available in #5373. Agree the key lifecycle before resubmitting application-managed cloud credential encryption. This follows the maintainer’s request in #4219, which is closed and unmerged. ### Motivation The maintainer identified a fixed fallback key and a migration that could make existing credentials unreadable after configuring a real key. The next implementation needs an agreed missing-key and upgrade policy before encryption is added. Reference: https://github.com/apache/rocketmq-dashboard/pull/4219#issuecomment-5694501541 ### Describe the Solution You'd Like Which rollout should a revised implementation target? 1. Explicit opt-in encryption (recommended for compatibility): retain existing storage until an operator configures an external key and explicitly enables encryption/migration. Never derive a fallback key. Once encrypted rows exist, a missing or wrong key must fail the affected secret-dependent operation clearly and must never rewrite those rows. 2. Required encryption for secret-bearing deployments: require an external key before accepting new persisted secrets, with a documented upgrade prerequisite for existing deployments. Never silently generate or derive a key. This gives a stricter default but changes first-run and upgrade behavior. For either option, can the first implementation cover only cloud credential secrets, as #4219 did, while other secret-bearing stores are separately inventoried and migrated? Its documentation should state that exact scope. Proposed acceptance criteria: - Key material managed outside the database/backups; no fixed production fallback - Versioned authenticated-encryption envelope with a key identifier; retain old decryption keys through an explicit, restart-safe rotation - Explicit resumable migration with backup/recovery instructions and per-row results; never overwrite on failure or describe partial migration as fully encrypted - Non-secret inventory metadata remains usable if one row cannot decrypt; only the affected secret-dependent operation fails, with no secret values in diagnostics - Tests for restart, absent/wrong key, tampering, interrupted migration, mixed formats, rotation and backup restore - Reveal re-authentication API changes stay separate from storage-only changes ### Describe Alternatives You've Considered Storage-level encryption and strict database/backup access remain deployment controls while the application design is agreed. API masking and Base64 encoding do not supply application-level encryption. A new fixed fallback or automatic migration without an operator-managed key would repeat the rejected design. ### Additional Context Searched open/closed issues and PRs for #4219, key policy and credential encryption; no follow-up design issue found. This proposal does not generate keys, change credentials or migrate data. A separate documentation-only correction will describe current storage behavior. ### Are You Willing to Submit a Pull Request? - [ ] Yes, I am willing to submit a pull request. -- 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]
