vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Key states affect whether an action that you perform on a key succeeds or fails. For example, if a managed key is in the Active state, you cannot destroy the key before you deactivate it first.

The following table shows how Unified Key Orchestrator handles service actions based on the state of a key. The column headers represent the key states, and the row headers represent the actions that you can perform on a key. The Checkmark icon ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) indicates that the action on a key is expected to succeed based on the key state.



Table 2. How key states affect service actions

 Action Pre-active Active Deactivated Destroyed 

 Get a key. ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) ![checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) 
 List keys. !
User 1 schedules (authorizes) a key deletion with the kp key schedule-delete command
3. User 2 schedules (authorizes) a key deletion
4. The key is deleted after the second schedule-delete is performed, which is supported in the user interface, API, and CLI
5. If a second authorization does not occur within 7 days, the key returns to its default status



There are two ways to enable the dual-auth-delete policy:



* Set the policy for a single key using kp key policy-update dual-auth-delete
* Set the policy for the instance using kp instance policy-update dual-auth-delete; all keys created after the instance policy is enabled inherit the instance policy setting



The [kp key cancel-delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-cli-reference-five-twokp-key-cancel-delete) command cancels, or removes, a prior authorization.

ibmcloud kp key schedule-delete KEY_ID
-i, --instance-id INSTANCE_ID



 Example 

This is an example of scheduleing a key to be deleted.

 schedule this key to be deleted
$ ibmcloud kp key schedule-delete $KEY_ID

Scheduling key for deletion...
OK

 this key has a dual-auth-delete policy
$ ibmcloud kp key policies $KEY_ID --output json

[
{
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-22T19:13:00Z",
Retrieving policy details for instance: a192d603-0b8d-452f-aac3-f9e1f95e7411...
OK
Created By user id ...<redacted>...
Creation Date 2020-06-22T16:17:52Z
Last Updated 2020-06-22T18:17:32Z
Updated By user id ...<redacted>...
Policy Type allowedNetwork
Enabled true
Network Allowed public-and-private





 Required parameters 

-d, --disable
or
-e, --enable
: Disable or enable the network access policy. One option is required.







 kp instance policy-update dual-auth-delete 

Use the dual-auth-delete policy to safely delete encryption keys. When you delete a key, you shred its contents and associated data. Any data that is encrypted by the key becomes inaccessible.

Deleting a key that has a dual authorization policy requires an authorization from two users.

For more information, see [deleting keys using dual authorization](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-dual-auth-keys) and [setting dual authorization policies for keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-dual-auth-key-policy).



 Notes 

Dual authorization delete for an instance is different than dual authorization delete for keys.

Once you enable dual-auth-delete for a key you cannot disable it or remove it. You must wait 7 days for the policy to expire.

Dual authorization delete for an instance can be enabled or disabled anytime.

If a key has a dual-auth-delete policy, changing the instance policy does not change any existing key policies.

When you change the instance policy, new keys are enforced with the instance policy.

ibmcloud kp instance policy-update dual-auth-delete
-i, --instance-id INSTANCE_ID
For more information, see [Restoring your data from another region](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-restore-data).

For the plan with Unified Key Orchestrator, currently you can only open an IBM support ticket so that IBM can restore the service instance.





 What happens if I delete my service instances? 

If you delete your service instance, your keys that are managed are not accessible.





 Can I back up the keys before I delete a service instance? 

Backing up the keys manually is not supported.





 What happens when I delete a key? 

Within 30 days after you delete a key, you can still view the key and restore the key to reverse the deletion. After 90 days, the key is purged and permanently removed from your instance. The data that is associated with the key becomes inaccessible. Before you delete a key, make sure that the key is not actively protecting any resources. For more information, see [Restoring keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-restore-keys).





 What happens if I lose the signature key or the master key parts? 

If your signature key or master key part is lost, you are not able to initialize your service instance, and your service instance is not accessible. Depending on how to store your keys, back up you key files on your workstation or back up your smart cards.
When you rotate a key, the process initiates a syncing KMS state task, and your deployment is reencrypted with the new key. The task is displayed on the Tasks page on your deployment's Overview and the associated Key Protect and Cloud Databases events are sent to Activity Tracker.

For more information, see [Rotating manually or automatically](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-rotationcompare-key-rotation-options).





 Deleting the Deployment 

If you delete a deployment that is protected with a Key Protect key, the deployment remains registered against the key during the soft-deletion period (up to 9 days). To delete the key in the soft-deletion period, [force delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-keys) the key. After the soft-deletion period, the key can be deleted without the force. To determine when you can delete the key, check the [association between the key and your deployment](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-protected-resources).





 Cryptoshredding 

Cryptoshredding is a destructive action. When the key is deleted, your data is unrecoverable.

Key Protect allows you to [initiate a force delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-keys) of a key that is in use by IBM Cloud® services, including your Cloud Databases deployments. This action is called cryptoshredding. Deleting a key that is in use on your deployment locks the disks that contain your data and disables your deployment. You are still able to access the UI and some metadata such as security settings in the UI, CLI, and API but you are not able to access any of the databases or data that is contained within them.
"lastUpdateDate": "2020-06-22T19:13:00Z",
"updatedBy": "user id ...<redacted>...",
"dualAuthDelete": { "enabled": true
}
}
]

 attempt to delete the key - this fails
$ ibmcloud kp key delete 6a8a129b-0cd4-4667-ba57-b355a125a7ca

Deleting key: 6a8a129b-0cd4-4667-ba57-b355a125a7ca, from instance: a192d603-0b8d-452f-aac3-f9e1f95e7411...
FAILED
kp.Error:
correlation_id='8ad33eb2-7bbf-4b7a-a02e-221959920342',
msg='Conflict: 1 prior authorization(s) are required for deletion: Key could not be deleted. Please see "reasons" for more details.',
reasons='[AUTHORIZATIONS_NOT_MET: Number of authorizations required to delete is not met -
FOR_MORE_INFO_REFER: https://cloud.ibm.com/apidocs/key-protect]'

 disable the instance dual authorization policy
$ ibmcloud kp instance policy-update dual-auth-delete --disable

Updating instance policy...
OK

 attempt to delete the key - this fails because the key policy
 does not change when the instance policy is updated
$ ibmcloud kp key delete 6a8a129b-0cd4-4667-ba57-b355a125a7ca
Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the cURL request. For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Hyper Protect Crypto Services instance. For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-retrieve-instance-ID). 



A successful request returns an HTTP 204 No Content response, which indicates that your key was authorized for deletion. Another user with a Manager access policy can now [delete the key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keys) by using the IBM Cloud console or key management service API.

If you need to prevent the deletion of a key that is already authorized for deletion, you can remove the existing authorization by calling POST /api/v2/keys/<key_ID>/actions/unsetKeyForDeletion.







 Step 2. Delete the key 

After you set a key for deletion, a second user with a Manager access policy can safely delete the key.

Hyper Protect Crypto Services sets a 7-day waiting period that starts after you provide the first authorization to delete the key. During this 7-day period, the key remains in the [Active state](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-key-states) and all key operations are allowed on the key. If no action is taken by the second user and the 7-day period expires, you must [restart the dual authorization process](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-dual-auth-keysset-key-deletion-api) to delete the key.
One is the entry for the deployment that lists its status as delegator. It is "User Created".



Table 1. Example delegator Key Protect Authorization

 Role Source Target Type 

 AuthorizationDelegator, Reader <cloud-databases> Service Key Protect Service User defined 



And one for the Cloud Object Storage bucket for its backups, where the deployment is the initiator.



Table 2. Example Key Protect Authorization for Cloud Object Storage from Cloud Databases

 Role Source Target Type 

 Reader Cloud Object Storage service Key Protect Service Created by <cloud-databases-crn> 







 Removing Keys 

IAM/Key Protect does not stop you from removing the policy between the key and Cloud Object Storage (the second example), but doing so can make your backups unrestorable. To prevent this, if you delete the Cloud Object Storage policy that governs the ability of Cloud Databases to use the key for Cloud Object Storage, the policy is re-created to continue backing up your deployment.

Be careful when removing keys and authorizations. If you have multiple deployments that use the same keys, it is possible to inadvertently destroy backups to all of those deployments by revoking the delegation authorization. If possible, do not use the same key for multiple deployment's backups.

If you want to shred the backups, you can delete the key. Cloud Object Storage ensures that the storage is unreadable and unwriteable. However, any other deployments that use that same key for backups encounter subsequent backup failures.

If you do require that the same key to be used for multiple deployment's backups, removing keys and authorizations can have the following side effects.



* If you delete just the Cloud Object Storage authorization (as seen in Table 2), then not only is the deployment that is shown as the creator affected, but any deployments that also use the same key are also affected. Those deployments can encounter temporary backup failures until the policy is automatically re-created. There should be no lasting effects, except for missing backups.
* If you delete just Cloud Databases delegator authorization, which is created by you (as seen in Table 1), nothing immediately breaks because the second authorization is still in place.
If you're using an integrated Cloud Service that supports revoking access to a disabled root key, the service may take up to a maximum of 4 hours before access to the root key's associated data is revoked.

After access to the associated data is revoked, a corresponding disable event is displayed in the IBM Cloud® Activity Tracker web UI. The disable event indicates the key has been revoked (and is now disabled) and the key can not be used for encrypt and decrypt operations.





 Enabling a root key 

When you enable a root key that was previously disabled, the key transitions from the [Suspended](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-states) to the [Active](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-states) key state. This action restores the key's encrypt and decrypt operations.

If you're using an integrated Cloud Service that supports restoring access to a disabled root key, the service may take up to a maximum of 4 hours before access to the root key's associated data is restored.

After access to the associated data is restored, a corresponding enable event is displayed in the IBM Cloud Activity Tracker web UI. The enable event indicates the key has been restored (and is now enabled) and the key can be used for encrypt and decrypt operations.







 Disabling and enabling root keys in the console 

If you prefer to enable or disable your root keys by using a graphical interface, you can use the IBM Cloud console.



 Disabling a root key in the console 

[After you create or import your existing keys into the service](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys), complete the following steps to disable a key:



1. [Log in to the IBM Cloud console](https://cloud.ibm.com/login/).
2. Go to Menu > Resource List to view a list of your resources.
3. From your IBM Cloud resource list, select your provisioned instance of Key Protect.
4.
To learn if a key is registered to cloud resource, you can [review the resources](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-protected-resources) that are associated with the key.
* You can now [force deletion on a key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-keysdelete-keys-force-delete) that's protecting a cloud resource.







 17 February 2020 

Key Protect announces additional roles
: Need to grant read-only access to keys? You can now choose between the Reader and ReaderPlus IAM roles for better control over access to key material. To learn more about service access roles, see [Managing user access](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessmanage-access-roles).







 January 2020 



 15 January 2020 

Key Protect announces new dual authorization policies
: You can now enable dual authorization policies to safely delete keys from your Key Protect instance. When you enable dual authorization, you require an action from two users to delete a key.



* To learn how to enable dual authorization at the instance level, see [Enabling a dual authorization policy for an instance](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-dual-auth).
* To learn how to enable dual authorization at the key level, see [Enabling a dual authorization policy for a key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-dual-auth-key-policy).









 November 2019 



 04 November 2019 

Added:
: Key Protect is updating its user access roles and how they correspond to Key Protect service actions. Effective 13 November 2019, Key Protect will update access roles accordingly:



* Create keys service action has current role assignments: Administrator, Editor, Writer, Manager; will have new Writer, Manager role or roles.
* Retrieve a key by ID service action has current role assignments: Administrator, Editor, Writer, Manager; will have new Writer, Manager role or roles.
Table 1. Describes the table of keys

 Column Description 

 Name The unique, human-readable name that was assigned to your key. 
 ID A unique key ID that was assigned to your key by the Hyper Protect Crypto Services service. You can use the ID value to make calls to the service with the [Hyper Protect Crypto Services key management service API](https://cloud.ibm.com/apidocs/hs-crypto). 
 Alias The human-readable aliases that you specify for easy recognition when you create the key. 
 Key ring ID The key ring that the key belongs to. 
 Type The type of key that describes your key's designated purpose within the service. 
 State The [key state](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-key-states) based on [NIST Special Publication 800-57, Recommendation for Key Management](https://www.nist.gov/publications/recommendation-key-management-part-1-general-0). These states include Pre-active, Active, Suspended, Deactivated, and Destroyed. 
 Origin Indicates whether the key is imported. Created indicates that the key is created by the service instance; Imported indicates that the key is imported by the user. 
 Last updated The date and time that the key was last updated. This field gets updated when the key is created, rotated, or any part of the key metadata is modified. 
 Last rotated The date and time that the key was last rotated. 
 Created The date and time that the key was created. 
 Dual authorization enabled The status of a dual authorization policy on the key.<br><br><br><br> * True: Dual authorization is required to delete the key.<br> * False: No prior authorization is required to delete the key.<br><br><br> 
 Set for deletion Indicates whether a delete authorization is issued for a key.<br><br><br><br> * True: An authorization to delete this key is issued by the first user. A second user with a Manager access policy can safely delete the key.<br> * False: The key is not set for deletion.
"dualAuthDelete": {
"enabled": true
}
}

 list the policies
$ ibmcloud kp key policies $KEY_ID --output json

[
{
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-19T16:08:59Z",
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:policy:0aab763d-b650-43a2-86ad-bdfe2c35c94c",
"lastUpdateDate": "2020-06-19T16:08:59Z",
"updatedBy": "user id ...<redacted>...",
"dualAuthDelete": { "enabled": true
}
}
]

 this should fail (the key has a dual authorization policy)
$ ibmcloud kp key delete $KEY_ID_OR_ALIAS

Deleting key: d887bfe8-5166-4dad-af32-7e3055ca1873, from instance: a192d603-0b8d-452f-aac3-f9e1f95e7411...
FAILED
kp.Error:
correlation_id='fe0db627-1726-4827-a9d2-c21d728e1c92',
msg='Conflict: 1 prior authorization(s) are required for deletion: Key could not be deleted.
Please see "reasons" for more details.',
reasons='[AUTHORIZATIONS_NOT_MET: Number of authorizations required to delete is not met -
The service attempts to delete a key, which is not allowed. That is, another service cannot delete a Key Protect key.

One example of using service-to-service access is a user configuring a Cloud Object Storage (COS) bucket to encrypt their data using a Key Protect key.

Using the COS example, COS cannot delete the key used to encrypt data.







 30 - This action can only be done by a service... 



 Message 

This action can only be done by a service (service to service)

Reason code: SERVICE_ONLY_ERR





 HTTP status code 

403 - Forbidden

The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it.

This status is similar to 401, but in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.





 Context 

Some actions, such as creating a "registration", can only be performed by another service, in what is known as a service-to-service request.

For example, if you configuring a Cloud Object Storage (COS) bucket to encrypt data using a Key Protect key, then the COS service need to create the registration.

A service-to-service request is required to create, delete, replace, or update a registration.

See this resources for more information about registrations.



* [API documentation](https://cloud.ibm.com/apidocs/key-protectcreateregistration)









 31 - This action is not permitted on this... 



 Message 

This action is not permitted on this resource: Please contact IBM Key Protect or open a service ticket to enable this feature

Reason code: FEATURE_RESTRICTED_ERR





 HTTP status code 

403 - Forbidden

The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it.

This status is similar to 401, but in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.





 Context
Key Protect allows you to [initiate a force delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-keys) of a key that is in use by IBM Cloud® services, including your Cloud Databases deployments. This action is called cryptoshredding. Deleting a key that is in use on your deployment locks the disks that contain your data and disables your deployment. You are still able to access the UI and some metadata such as security settings in the UI, CLI, and API but you are not able to access any of the databases or data that is contained within them. Key deletion is [sent to the Activity Tracker](https://cloud.ibm.com/docs/key-protect?topic=key-protect-at-events) as kms.secrets.delete.





 Bring your own key for backups 

If you use Key Protect, when you provision a database you can also designate a key to encrypt the Cloud Object Storage disk that holds your deployment's backups.

BYOK for backups is available only in US regions us-south and us-east, and eu-de.

Only keys in the us-south and eu-de are durable to region failures. To ensure that your backups are available even if a region failure occurs, you must use a key from us-south or eu-de, regardless of your deployment's location.



 Granting the delegation authorization 

To enable your deployment to use the Key Protect key, you need to [Enable authorization to be delegated](https://cloud.ibm.com/docs/account?topic=account-serviceauth) when granting the service authorizations. If the delegation authorization is not present before provisioning your deployment with a key, the provision fails.





 Using the Key at Provision in the CLI 

After the appropriate authorization and delegation is granted, you supply the [key name or CRN](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keys) when you provision a deployment.

In the CLI, use the backup_encryption_key_crn parameter in the parameters JSON object.