vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The region abbreviation, such as us-south or eu-gb, that represents the geographic area where your Key Protect instance resides. <br> <br>For more information, see [Regional service endpoints](https://cloud.ibm.com/docs/key-protect?topic=key-protect-regionsservice-endpoints). 
 key_ID_or_alias Required. The unique identifier or alias for the key that you would like to delete. 
 IAM_token Required. Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the curl request. <br> <br>For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Key Protect service instance. <br> <br>For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-instance-ID). 
 return_preference Optional. A header that alters server behavior for POST and DELETE operations. <br> <br>When you set the return_preference variable to return=minimal, the service returns a successful deletion response. When you set the variable to return=representation, the service returns both the key material and the key metadata. 



If the return_preference variable is set to return=representation, the details of the DELETE request are returned in the response entity-body.

After you delete a key, it transitions to the Deactivated key state. After 24 hours, if a key is not reinstated, the key transitions to the Destroyed state. Destroyed keys can be recovered after up to 30 days or their expiration date, whichever is sooner. After this the key contents are permanently erased and no longer accessible.

The following JSON object shows an example returned value.

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.key+json",
The [kp key schedule-delete](https://cloud.ibm.com/docs/key-protect-cli-pluginkp-key-schedule-delete) command is the "authorization" to delete the key.

Follow this process to delete a key with a dual-auth-delete policy.



1. Create a key and enable the dual-auth-delete policy
2. 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



ibmcloud kp key cancel-delete KEY_ID_OR_ALIAS
-i, --instance-id INSTANCE_ID



 Example 

This is an example of canceling a previously scheduled key delete.

 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",
As a consequence, App Configuration can no longer access the data because it can no longer access the key.

To remove access permanently, you can delete the key. However, you must take extreme caution because this operation is non-recoverable. You will lose access to any data stored in your App Configuration instance. There is no way to recover this data.

In both cases, the App Configuration instance shuts down and no longer accepts or processes connections. An activity tracker event is generated to report the action. For more information, see [App Configuration events](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-at_events).

The authorization should be left in place between your App Configuration and the key management service instance at all times. While removing this authorization prevents App Configuration from future access to your data, already in-use data will continue to be available for a period of time.

You are charged for your instance of App Configuration until you deprovision it using the IBM Cloud console or CLI. These charges are still applied even if you chose to prevent access to your data.





 Restoring access to data 

Access can be restored only if the key was not deleted. To restore access, re-enable your root key. After a short period of initialization, your App Configuration instance is restarted and starts accepting connections again. All data is retained, subject to the normal retention limits configured in your instance.

An activity tracker event is generated to report the action. For more information, see [Activity Tracker events](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-at_events).





 Rotating the key 

Key Protect and Hyper Protect Crypto Services support the rotation of root keys, either on demand or on a schedule. When this occurs, App Configuration adopts the new key by rewrapping the DEK as described previously in [how customer-managed encryption works](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-managing-encryptionac-encryption-how).

An activity tracker event is generated to report the action.
Conflicts are most likely to occur in response to a PUT request. For example, you may get a 409 response when uploading a file which is older than the one already on the server resulting in a version control conflict.





 Context 

A key with a dual authorization policy cannot be deleted without an authorization from two users.



 Example 

These steps illustrate how to create the error message.



1. Create a root key
2. Enable the dual authorization policy
3. List the policies (verify dual authorization is enabled)
4. Delete the key, which fails because not enough authorizations are met to delete the key



 step 1 - create a root key
$ KEY_ID=$(ibmcloud kp key create example-key -i $KP_INSTANCE_ID --output json | jq -r '.["id"]')

$ echo $KEY_ID

8f97b016-bc31-4e3d-9cd6-a0a1c7caffdb

 step 2 - enable the dual authorization policy
$ ibmcloud kp key policy-update dual-auth-delete $KEY_ID -i $KP_INSTANCE_ID --enable

Setting a rotation interval for key ID: 8f97b016-bc31-4e3d-9cd6-a0a1c7caffdb...
OK

Key ID 8f97b016-bc31-4e3d-9cd6-a0a1c7caffdb
Created By IBMid-...<redacted>...
Creation Date 2020-08-13T22:33:50Z
Last Updated 2020-08-13T22:33:50Z
Updated By IBMid-...<redacted>...
Enabled true

 step 3 - list the policies (verify dual authorization is enabled)
$ ibmcloud kp key policies $KEY_ID -i $KP_INSTANCE_ID --output json

[
{
"createdBy": "IBMid-...<redacted>...",
"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

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 -
Disabling the dual authorization policy for an instance does not change the policy for existing keys. The instance policy applies to new keys created after the policy is updated.

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

Updating instance policy...
OK

 create a new key
$ ibmcloud kp key create my-protected-key

Creating key: 'my-protected-key', in instance: 'a192d603-0b8d-452f-aac3-f9e1f95e7411'...
OK
Key ID Key Name
6a8a129b-0cd4-4667-ba57-b355a125a7ca my-protected-key

 list the policies for the key - dual-auth-delete is
 enabled because the key inherits the instance policy
$ ibmcloud kp key policies 6a8a129b-0cd4-4667-ba57-b355a125a7ca --output json

[
{
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-22T19:13:00Z",
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:policy:2427dbde-6cff-41eb-8b5a-ff26b038cafc",
"lastUpdateDate": "2020-06-22T19:13:00Z",
"updatedBy": "user id ...<redacted>...",
"dualAuthDelete": { "enabled": true
}
}
]
If you remove an access policy that was created by the source service for its dependent services, the source service is unable to complete the workflow or access the target service.

Because the root keys are under your control, you don't need to contact IBM to remove authorization.

Do not remove IAM authorization between Cloud Block Storage and the KMS instance, and then delete a block storage volume, snapshot, or image resource. Such action causes the root key in the KMS instance to remain registered with the deleted resource. You must delete all BYOK volumes, snapshots, or images before you remove the IAM authorization.

To make your data inaccessible, but retain it on the IBM Cloud:



1. [Remove IAM authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauthremove-auth) from the source Cloud Block Storage service to your target key management service instance.
2. [Stop all virtual server instances](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-virtual-server-instancesstop-and-start) with attached encrypted volumes that are secured by that root key.



You can also [disable a root key](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managing&interface=uibyok-disable-root-keys), which suspends the key and temporarily revokes access to it.







 Viewing events in the IBM Cloud Activity Tracker 

Use the Activity Tracker to verify user-initiated activities that change the state of your keys in the key management service.

Due to the sensitivity of the information, when an event is generated as a result of an API call to the KMS, the event doesn't include detailed information about the key. Instead, it includes a correlation ID that you can use to identify the key internally in your cloud environment. The correlation ID is a field that is returned as part of the correlationId field.



 Activity Tracker events for key rotation 

When you initiate activity in the KMS to rotate and manage your root keys, Activity Tracker events are generated.
Click Create.





App ID supports state changes to your key.



 Rotating your keys 

When you [rotate your KEK](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-rotate-keys), App ID rewraps the DEKs associated with the rotated key, ensuring your user data is always protected with your up-to-date encryption key.





 Deleting your keys 

When you [delete your KEK](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keys), user data becomes inaccessible within 4 hours of deletion. Although user data is not destroyed when a key is deleted, App ID is no longer able to decrypt the user data, making it inaccessible.









 Deleting your data in App ID 

When you delete an instance of App ID, all the user-associated data is also deleted. When the service instance is deleted, a 7-day reclamation period begins. During that time, you are able to restore the instance and all the user-associated data. However, if the instance and data are permanently deleted, it cannot be restored. App ID does not store any data from permanently deleted instances.

The App ID data retention policy describes how long your data is stored after you delete the service. The data retention policy is included in the App ID service description, which you can find in the [IBM Cloud Terms and Notices](https://cloud.ibm.com/docs/overview?topic=overview-terms).



 Deleting an instance 

If you no longer need an instance of App ID, you can delete the service instance and any data that is stored. You can also choose to delete your service instance by using the console.



1. Delete the service and place it in a reclamation period of 7 days.

ibmcloud resource service-instance-delete <serviceName>
2. Optional: To permanently delete your instance, get the reclamation ID.

ibmcloud resource reclamations --resource-instance-id <tenantID>
[checkmark icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/checkmark-icon.svg) 



If you're an account owner, you are automatically assigned Administrator platform access to your Hyper Protect Crypto Services service instances so you can further assign roles and customize access policies for others.





 IAM service access roles 

As a service administrator, you can use the service access roles to grant permissions of service users at the service level, such as the ability to view, create, or delete Hyper Protect Crypto Services keys.



* As a Reader, you can browse a high-level view of keys. Readers cannot create, modify, or delete keys.
* As a ReaderPlus, you have the same permissions as a Reader, with the additional ability to retrieve a standard key's material.
* As a Writer, you can create, modify, rotate, and use keys. Writers cannot delete or disable keys.
* As a Manager, you can perform all actions that a Reader, ReaderPlus and Writer can perform, including the ability to delete keys and set policies for keys.
* As a VMware KMIP Manager, you can configure KMIP for VMware with Hyper Protect Crypto Services to enable encryption with your own root keys.
* As a Vault Administrator, you can manage vaults, keystores, and templates, and perform destructive lifecycle actions on managed keys in Unified Key Orchestrator. Different vaults can be used to separate teams, lines of business, or customers. You can also add paid keystores if you already exceed the limit of free keystores.
* As a Key Custodian - Creator, you can create and manage keys in Unified Key Orchestrator. For a complete key lifecycle, both the Key Custodian - Creator and Key Custodian - Deployer roles are needed.
* As a Key Custodian - Deployer, you can deploy and manage keys in Unified Key Orchestrator. For a complete key lifecycle, both the Key Custodian - Creator and Key Custodian - Deployer roles are needed.
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.

ibmcloud kp key disable KEY_ID_OR_ALIAS
-i, --instance-id INSTANCE_ID
[--key-ring KEY_RING_ID]



 Examples 

These are examples of kp key disable.



 Example 1 

Create a root key, disable it, verify the key state (suspended), enable the root key, and verify the key state (active).

 create a root key
$ ibmcloud kp key create my-root-key --output json

{
"id": "264fadc3-7667-4b25-916e-5825fe70de0b",
"name": "my-root-key",
"type": "application/vnd.ibm.kms.key+json",
"extractable": false,
"state": 1,
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:390086ac-76fa-4094-8cf3-c0829bd69526:key:264fadc3-7667-4b25-916e-5825fe70de0b"
}

 show key details - a state of "1" is "active"
$ ibmcloud kp key show 264fadc3-7667-4b25-916e-5825fe70de0b --output json

{
The [kp key schedule-delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-key-schedule-delete) command is the "authorization" to delete the key.

Follow this process to delete a key with a dual-auth-delete policy.



1. Create a key and enable the dual-auth-delete policy
2. 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



ibmcloud kp key cancel-delete KEY_ID_OR_ALIAS
-i, --instance-id INSTANCE_ID



 Example 

This is an example of canceling a previously scheduled key delete.

 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",
After you grant your Db2 on Cloud deployments permission to use your keys, you supply the key name or CRN in [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keys) or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-view-keys) when you provision a deployment. The deployment uses your encryption key to encrypt your data.

If you provision a deployment through the CLI or API, the key needs to be identified by its full CRN, not just its ID. A CRN is in the format crn:v1:<...>:key:<id>.





 Deleting the deployment 

If you delete a deployment that is protected with a key, the deployment remains registered against the key for the duration of the soft-deletion period (up to 9 days). If you need to delete the key in the soft-deletion period, you have to force delete the key using [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-keys) or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keys). After the soft-deletion period the key can be deleted without the force. You can check the [association between the key and your deployment](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-protected-resources) to determine when you can delete the key.





 Cryptoshredding 

Cryptoshredding is a destructive action. Once the key is deleted your data is unrecoverable.
For more information, search for [Removing an authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauthremove-auth) in "Using authorizations to grant access between services".





 Restore temporary access 

To restore access after you temporarily remove it, follow these steps:



1. Re-create the authorization between your Watson service and Key Protect instance as shown in [Step 3. Grant service access](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-keyserviceserviceauth-key).
2. Tell your IBM Client Success Manager (CSM) that you want to restore access through Key Protect.



After you re-create the authorization and your CSM confirms Watson that any delegated authorizations are reconnected, the Watson instance starts accepting connections again.





 Permanently prevent access to your data 

To delete your data securely, delete both the encrypted Watson service instance and the Key Protect key.

When you delete a data encryption key, it is not recoverable and you cannot decrypt the key. You prevent further access to the data, but you also cannot recover the data.

For more information about deleting keys, see [Deleting keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-keys) in the Key Protect docs.





 Rotating keys 

Key rotation is an important part of mitigating the risk of a data breach. Periodically changing keys reduces the potential data loss if the key is lost or compromised. For more information, see [Setting a rotation policy](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-rotation-policy) in the Key Protect docs.





 Identify which key is encrypting your service instance 

To see which Key Protect instance is used to encrypt the data, use the link in the service details.



1. Go to your [resource list](https://cloud.ibm.com/resources).
2. Click the name of the Watson service instance.
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
-d, --disable OR
-e, --enable





 Examples 

These are examples of kp instance policy-update dual-auth-delete.



 Example 1 

This example enables the dual authorization delete policy.

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

Updating instance policy...
OK

 list the instance policies
$ ibmcloud kp instance policies --output json

[
{
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-06-22T18:45:14Z",
"lastUpdated": "2020-06-22T18:45:14Z",
"updatedBy": "user id ...<redacted>...",
"policy_type": "dualAuthDelete",
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 is no longer authorized for deletion. If you need to restart the dual authorization process, you can issue another authorization to [set the key for deletion](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-dual-auth-keysset-key-deletion-api).









 What's next 



* To restore a previously deleted key, check out [Restoring keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-restore-keys).
* To create another root key, check out [Creating root keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-create-root-keys).
* To delete the service instance, check out [Deleting service instances](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-instance)
* To find out more about programmatically managing your keys, [check out the Hyper Protect Crypto Services key management service API reference doc](https://cloud.ibm.com/apidocs/hs-crypto).