For safe housekeeping of secrets in Secrets Manager the following approach is necessary.
1) Deactivate a deprecated secret
2) Hyper care phase, see if there are any issues with the application
3) Delete the secret after successful hyper care phase
At the moment a deactivate-functionality is not available at the Secrets Manager. This was confirmed in a Support Case
This means, it is very dangerous for a business-critical / availability-critical application to housekeep the secrets.
That’s why I’m requesting the deactivate-functionality for the Secrets Manager.
Extra information: In Key Protect and HPCS, there is a deactivate-functionality.
| Idea priority | High |
| Needed By | Quarter |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
Customer response provided by @Oliver Rebmann
Please clarify if the requirement is only to allow a non-reversible deactivate operation where the secret cannot be transitioned back to an active state and can only be later deleted, or the requirement is to provide a disable/enable feature with the secret being able to transition back to an active state? Key Protect referenced as an example for supporting such functionality in the aha! Idea offers key disable/enable api, so I assume the later.
The requirement includes the deactivation and also the activation. In case of issues during hypercare phase after deactivating a secret, it must be possible to activate the secret again to solve the incident.
Add API and UI support for disable/enable of secrets in Secrets Manager.
required
Disabled secrets will include their metadata but not include its credentials when obtained from Secrets Manager.
I do not fully understand this, but it must be possible to enable/activate the secret again as is was before.
Secret types that are managing credentials in integrated services that supports disabling credentials such as IAM Credentials will disable the secret API Keys in IAM.
I do not fully understand this dependency.
Secrets configured with auto-rotation enabled and are disabled at rotation time will not auto rotate. Auto-rotation will resume if the secret will be enabled later and the secret will transition into an active state.
Sounds plausible.
Manual rotation of disabled secrets will not be possible.
Sounds plausible.
Disabled secrets will not send secret life-cycle event notifications (such as secret about to expire, or secret expired). Notifications will resume if the secret will be enabled later.
Sounds plausible.
Additional clarifications and technical information are required for the Secrets Manager team to properly scope and assess the idea. Let me know if the following assumptions are in line with the customer ask:
Please clarify if the requirement is only to allow a non-reversible deactivate operation where the secret cannot be transitioned back to an active state and can only be later deleted, or the requirement is to provide a disable/enable feature with the secret being able to transition back to an active state? Key Protect referenced as an example for supporting such functionality in the aha! Idea offers key disable/enable api, so I assume the later.
Add API and UI support for disable/enable of secrets in Secrets Manager.
Disabled secrets will include their metadata but not include its credentials when obtained from Secrets Manager.
Secret types that are managing credentials in integrated services that supports disabling credentials such as IAM Credentials will disable the secret API Keys in IAM.
Secrets configured with auto-rotation enabled and are disabled at rotation time will not auto rotate. Auto-rotation will resume if the secret will be enabled later and the secret will transition into an active state.
Manual rotation of disabled secrets will not be possible.
Disabled secrets will not send secret life-cycle event notifications (such as secret about to expire, or secret expired). Notifications will resume if the secret will be enabled later.