Bug 1975323
| Summary: | [KMS] Keys for OSDs in vault are not deleted during uninstall when kv-v2 is used | |||
|---|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat OpenShift Data Foundation | Reporter: | Rachael <rgeorge> | |
| Component: | rook | Assignee: | Sébastien Han <shan> | |
| Status: | CLOSED NOTABUG | QA Contact: | Shay Rozen <srozen> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 4.8 | CC: | agantony, madam, muagarwa, nberry, ocs-bugs, odf-bz-bot, olakra, rcyriac, shan, srozen | |
| Target Milestone: | --- | Keywords: | AutomationBackLog | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: |
.Keys for OSDs in the Vault are not deleted during uninstall when `kv-v2` is used
Key encryption keys *data* are soft-deleted from Vault during cluster deletion when the Vault K/V Secret engine is version 2. This means any version of the Key can be retrieved and so the deletion is undone.
The metadata is still visible so the key can be restored. If this is causing inconvenience, the key can still be deleted manually using the vault command with the "destroy" argument.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1993801 2015088 (view as bug list) | Environment: | ||
| Last Closed: | 2021-10-18 11:31:32 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1966894, 1993801 | |||
|
Description
Rachael
2021-06-23 12:23:14 UTC
Requires doc text as a known issue Rachael, can we get a mustgather or simply the rook-ceph-operator logs to understand a bit more what going on here? Thanks! The bug is not only affecting kv v2 but also v1. The bug is not experienced when the PVC reclaim policy is Retain. (In reply to Sébastien Han from comment #5) > The bug is not only affecting kv v2 but also v1. > The bug is not experienced when the PVC reclaim policy is Retain. **Disregard this comment**. I mixed things up, I'm still looking. Ok after some local debugging there is no bug per se. What we see is the remaining metadata but if you inspect the Secret, you won't see any data, for instance: BEFORE DELETION: runner@fv-az72-598:~/work/rook/rook$ kubectl exec -ti vault-0 -- vault kv get -ca-cert /vault/userconfig/vault-server-tls/vault.crt rook/ver2/mybucketkey ====== Metadata ====== Key Value --- ----- created_time 2021-06-24T10:20:52.07073694Z deletion_time n/a destroyed false version 1 === Data === Key Value --- ----- key IdCRBZ+sAA7D87dqUO6F+Hn7MQ24SDhb4lnTqB7QNf4= AFTER DELETION: runner@fv-az72-598:~/work/rook/rook$ kubectl exec -ti vault-0 -- vault kv get -ca-cert /vault/userconfig/vault-server-tls/vault.crt rook/ver2/mybucketkey ====== Metadata ====== Key Value --- ----- created_time 2021-06-24T12:33:02.669280958Z deletion_time 2021-06-24T12:40:46.483734597Z destroyed false version 1 Do not get confused "version 1" is the versioned number of the key, the revision if you will. Updated the doc text too. I'm moving this to MODIFIED since I believe the doc text is sufficient. Moving back to ASSIGNED for an eng fix, we also need a clone for the Doc I suppose? Ok final info on this one, the key is not deleted, it's a soft delete that can be undone. The docs are verified but I don't think it need to be in known issues but in some release notes. It's no so bad :) @olakra @muagarwa @ Agreed, that sounds good as a release note item. It's by-design so not really a known issue, depending on how you define "issue" though :) Known issues are put into release notes, so I am little confused here. Do you want to include this in documentation or just release notes? But we understand that it is not an issue but by design so isn't there any other place to put this information? Maybe add it as a note in uninstall instructions? @muagarwa Duplicated this BZ for documentation and closing it as not a bug. |