vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Use the following steps to delete an API key for a service ID by using Terraform.



1. The following example shows how to delete the API key for a service ID.

resource "ibm_iam_service_id" "serviceID" {
name = "servicetest"
}

resource "ibm_iam_service_api_key" "testacc_apiKey" {
name = "testapikey"
iam_service_id = ibm_iam_service_id.serviceID.iam_id
}

For more information, see the argument reference details on the [Terraform Identity and Access Management (IAM)](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_service_api_key) page.
2. After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply
0: pbkdf2
Hash: sha256
Iterations: 106736
Salt: a4 57 7d 09 e8 cd 56 e7 ad 4c 14 d8 15 b4 38 88
84 63 a8 7d 2a e8 2d d8 46 b6 87 2f 87 fa a9 e0
Digest: 09 aa 56 8f 14 dd c7 76 9a 51 5e 74 b9 1b 95 8a
14 a2 93 59 18 b3 70 df 54 53 c0 85 2c 3b 79 fd
[root@classic-byok-poc02 ]





 Removing a key from a specific slot 

See the following example for removing a key from a specific slot.

[root@classic-byok-poc02 ] cryptsetup luksKillSlot /dev/sda 1
Enter any remaining passphrase:
[root@classic-byok-poc02 ] cryptsetup luksDump /dev/sda
LUKS header information
Version: 	2
Epoch: 	5
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID: 	6e515660-7db7-41df-9b48-47d1489c7711
Label: 	(no label)
Subsystem: 	(no subsystem)
Flags: 	(no flags)

Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]

Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2i
Time cost: 4
Memory: 737817
Threads: 2
Salt: c3 c9 89 88 35 3a fb 32 4e 64 a0 5c 58 33 c0 92
This command (kp key cancel-delete) cancels, or removes, a prior authorization.

The [kp key schedule-delete](https://cloud.ibm.com/docs/key-protect-cli-plugin?topic=key-protect-cli-plugin-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",
[Authorize deletion for a key with the API (dual authorization)](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-dual-auth-keysset-key-deletion-api) [Authorize deletion for a key with the API (dual authorization)](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-dual-auth-keysset-key-deletion-api) 
 Restore key [Restoring a deleted key with the API](https://cloud.ibm.com/docs/key-protect?topic=key-protect-restore-keysrestore-api) [Restoring a deleted key with the API](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-restore-keysrestore-api) 







 Removing service authorization to a root key 

You can make your data inaccessible but retain it on the cloud by removing IAM authorization to use that root key.

When you [authorize use](https://cloud.ibm.com/docs/account?topic=account-serviceauthserviceauth) of your root key, you grant permission for IBM to use the key to encrypt your resource. Authorization is done at the key management service level through IAM, when you authorize service between your service (for example, Cloud Block Storage) and the key management service.

You can remove any authorization between services in your account when you have the Administrator role on the target service (in this case, the key management service). 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.
For an integrated Cloud Service that supports revoking access to a disabled root key, the service can take up to 4 hours to revoke or restore access to the associated data of the root key. After access to the associated data is revoked or restored, a corresponding enable event is displayed in the Activity Tracker web UI.



 Disabling and enabling root keys with 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 

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



1. [Log in to the IBM Cloud console](https://cloud.ibm.com/).
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 Hyper Protect Crypto Services.
4. On the KMS keys page, use the Keys table to browse the keys in your service instance.
5. Click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/action-menu-icon.svg) to open a list of options for the key that you want to disable.
6. From the options menu, click Disable key, enter the key name to confirm the key to be disabled, and click Disable key.



After the key is disabled, the State of the key is moved to Suspended in the Keys table.





 Enabling a root key 

If you want to re-enable a root key that is [disabled](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-disable-keysdisable-ui), complete the following steps:

You must wait 30 seconds after you disable a root key before you are able to enable it again.
If you have many keys, you can narrow your search by using the search bars to only search for enabled keys (since other kinds of keys cannot be rotated), keys in a particular key ring, and keys with a particular alias.
5. Once the key has been found, click the ⋯ icon to open a list of options for the key that you want to rotate.
6. From the options menu, click Rotate to open the Rotation side panel.
7. If your rotation policy is Enabled, you can edit this policy by changing the number of months selected. This will set the 30-day interval for your root key. If a key is set to be rotated every 2 months, for example, it will be rotated every 60 days, regardless of the number of days in a particular month. If your rotation policy is Disabled, and the key was created at a time when your instance had a rotation policy, a rotation interval number can be seen. This is the rotation policy that was written to your key in a Disabled state at key creation time. You can also change the rotation interval at this time.
8. Click Set policy. The policy is now in effect.



If you want to rotate the key immediately, click Rotate key. Note: these actions are not mutually exclusive. If your key has an existing rotation policy, the interface displays the key's existing rotation period.

For imported root keys only, you must add base64 encoded key material that you want to store and manage in the service. Ensure that the key material is in 128, 192, or 256 bits and that the bytes of data (for example, 32 bytes for 256 bits) are encoded by using base64 encoding.

When it's time to rotate the key based on the rotation interval that you specify, Key Protect automatically replaces the root key with new key material.
Why can't I delete vaults? 

You are not able to delete vaults by using either UI or API.

  What’s happening 

You try to delete a vault, but it fails with the following message:

> The service was not able to delete vault <vault_name> because it still contains some keys or keystores.

  Why it’s happening 

If you want to delete a vault, you need to delete all managed keys, and delete or disconnect from all target keystores that are managed in the vault first. The Delete function is available for empty vaults only.

  How to fix it 

Verify with your administrator that you're assigned [the correct role](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessroles) in the applicable resource group or service instance. And then, delete all managed keys, and delete or disconnect from all target keystores that are managed in the vault, and try again.
Click the Actions menu (ellipsis) in the row of the snapshot that you want to delete.
3. Select Delete.
4. Confirm the deletion and click Delete.



You can also delete a snapshot from the details page of a Block Storage for VPC volume.



1. Go to the list of all Block Storage for VPC volumes. In the [IBM Cloud console](https://cloud.ibm.com/login), go to the menu ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Storage > Block storage volumes.
2. Select a volume from the list, and click the volume name to go to the volume details page.
3. Click Snapshots. A list of snapshots that are taken of this volume are displayed, and you can take the following actions:



* Click Delete all to delete all snapshots for this volume.
* Click the Actions menu (ellipsis) to delete a specific snapshot.



4. Select Delete. If the snapshot is actively restoring a volume, the delete operation does not work.
5. Confirm the deletion.







 Deleting all snapshots for a volume in the UI 

To delete all snapshots for a volume in the UI, follow these steps.



1. Go to the list of all snapshots. In the [IBM Cloud console](https://cloud.ibm.com/login), go to menu ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Storage > Snapshots.
2. Click the row to select the snapshot that you want to delete.
3. From the Actions menu (ellipsis), select Delete all for volume.
4. Confirm the deletion by typing delete and then click Delete.
Delete a secret group by specifying the ID of the secret group.

Note: To delete a secret group, it must be empty. If you need to remove a secret group that contains secrets, you must first delete the secrets that are associated with the group.

ibmcloud secrets-manager secret-group-delete --id ID



 Command options 

--id (string)
: The v4 UUID that uniquely identifies the secret group. Required.

The value must match regular expression /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/.





 Examples 

ibmcloud secrets-manager secret-group-delete --id=exampleString









 Secrets 

Create, import, and manage different types of secrets for your apps and services.



 ibmcloud secrets-manager secret-create 

Create a secret or import an existing value that you can use to access or authenticate to a protected resource.

Use this method to either generate or import an existing secret, such as an arbitrary value or a TLS certificate, that you can manage in your Secrets Manager service instance. A successful request stores the secret in your dedicated instance based on the secret type and data that you specify. The response returns the ID value of the secret, along with other metadata.

To learn more about the types of secrets that you can create with Secrets Manager, check out the [docs](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-what-is-secret).

ibmcloud secrets-manager secret-create --secret-type SECRET-TYPE --metadata METADATA --resources RESOURCES



 Command options 

--secret-type (string)
: The secret type. Required.

Allowable values are: arbitrary, iam_credentials, imported_cert, public_cert, private_cert, username_password, kv.
You can also revoke access at any time, for example, if you suspect your keys might be compromised. You can also disable or delete a root key, or temporarily revoke access to the key's associated data on the cloud. For more information, see [Managing root keys](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managingbyok-manage-root-keys).
* What are the advantages of using customer-managed encryption over provider-managed encryption?

 What are the advantages of using customer-managed encryption over provider-managed encryption? 

Customer-managed encryption encrypts your Block Storage for VPC volumes by using your own root keys. You have complete control over your data security and grant IBM access to use your root keys. For more information, see [Advantages of customer-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutbyok-advantages).
* What encryption technology is used for customer-managed encryption?

 What encryption technology is used for customer-managed encryption? 

Virtual disk images for VPC use QEMU Copy On Write Version 2 (QCOW2) file format. LUKS encryption format secures the QCOW2 format files. IBM currently uses the AES-256 cipher suite and XTS cipher mode options with LUKS. This combination provides you a much greater level of security than AES-CBC, along with better management of passphrases for key rotation, and provides key replacement options in case your keys are compromised.
* What are master encryption keys and how are they assigned to my Block Storage for VPC volumes?

 What are master encryption keys and how are they assigned to my Block Storage for VPC volumes? 

Each volume is assigned a unique master encryption key, called a data encryption key or DEK, which is generated by the instance's host hypervisor. The master key for each Block Storage for VPC volume is encrypted with a unique KMS-generated LUKS passphrase, which is then encrypted by your customer root key (CRK) and stored in the KMS.
"updatedBy": "user id ...<redacted>...",
"rotation": {
"interval_month": 2
}
}
]





 Required parameters 

KEY_ID
: The ID of the key that you want to query. To retrieve a list of your available keys, run the [kp keys](#kp-keys) command.





 Optional parameters 

-m, --monthly-interval
: Set the key rotation interval in months. The deault is 1 (one) month. The rotation interval must be 1 to 12 months.







 kp key restore 

Key Protect can restore a previously deleted root key, which restores access to its associated data in the cloud.

As an admin, you might need to restore a root key that was imported into Key Protect to access data the key previously protected.

When you restore a key, you move the key from the Destroyed (value is 5) to the Active (value is 1) key state, and you restore access to any data that was previously encrypted with the key.

You can restore a deleted key within 30 days of its deletion. This capability is available only for root keys that were created with a key material.

You can only restore root keys that were created with a key material, using kp key create with the -k, --key-material option. You cannot restore a root key if the --key-material option was not specified.

If you want to restore a deleted root key then you must save the key material that was used to create the root key. You cannot restore a deleted key without provided the original key material.

ibmcloud kp key restore KEY_ID
-i, --instance-id INSTANCE_ID
-k, --key-material KEY_MATERIAL
[-n, --encrypted-nonce ENCRYPTED_NONCE]
[-v, --iv IV]



 Examples 

These are examples of kp key restore.



 Example 1 

This example creates a root key using a key material, deletes the key, then restores the key.
For information about endpoints per region, see [API endpoints](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-endpointsendpoints_api).

KEY_ID
: ID value of the ingestion key to be deleted.

SERVICE_KEY
: Service key value. A service key is a unique code that is passed in an API request to identify the calling application or user. The service key is specific to a logging instance. For more information on how to generate a service key, see [Managing service keys](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-service_keys).







 Rotating the ingestion key by using the API 

If the ingestion key is compromised or you have a policy that requies renewal of a key after a number of days, you can generate a new key and delete the old one.

To rotate a key, complete the following steps:



1. Get the details of the key that you want to rotate.

You can list all ingestion keys to obtain the ID of the key that you want to rotate. For more information, see [Listing all ingestion keys](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-ingestion_keyingestion_key_api_list).

If you know the Key ID, skip to the next step.
2. Create a new key. For more information, see [Creating an ingestion key](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-ingestion_keyingestion_key_api_create).
3. Delete the old key. Make sure you use the ID of the key that you identified previously. For more information, see [Deleting a key](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-ingestion_keyingestion_key_api_delete).
4.
Key ID Key Name Description Creation Date Expiration Date
8635b804-9966-4918-a16b-d561fdbf181f my-root-key 2020-05-05 19:58:02 +0000 UTC Key does not expire

 delete the key
$ ibmcloud kp key delete 8635b804-9966-4918-a16b-d561fdbf181f

Deleting key: 8635b804-9966-4918-a16b-d561fdbf181f, from instance: 390086ac-76fa-4094-8cf3-c0829bd69526...
OK
Deleted Key
8635b804-9966-4918-a16b-d561fdbf181f





 Example 2 

Delete a root key and show the JSON output.

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

{
"id": "9cca88c9-019e-4f0a-9e76-8e657c6b9720",
"name": "my-root-key",
"type": "application/vnd.ibm.kms.key+json",
"extractable": false,
"state": 1,
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb145:390086ac-76fa-4094-8cf3-c0829bd69526:key:9cca88c9-019e-4f0a-9e76-8e657c6b9720"
}

 show key details
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",
"collectionTotal": 1
},
"resources": [
{
"type": "application/vnd.ibm.kms.key+json",
"id": "02fd6835-6001-4482-a892-13bd2085f75d",
"name": "test-root-key",
"aliases":
"alias-1",
"alias-2"
],
"state": 5,
"extractable": false,
"crn": "crn:v1:bluemix:public:kms:us-south:a/f047b55a3362ac06afad8a3f2f5586ea:12e8c9c2-a162-472d-b7d6-8b9a86b815a6:key:02fd6835-6001-4482-a892-13bd2085f75d",
"imported": false,
"creationDate": "2020-03-10T20:41:27Z",
"createdBy": "...",
"algorithmType": "Deprecated",
"algorithmMetadata": {
"bitLength": "256",
"mode": "Deprecated"
},
"algorithmBitSize": 256,
"algorithmMode": "Deprecated",
"lastUpdateDate": "2020-03-16T20:41:27Z",
8635b804-9966-4918-a16b-d561fdbf181f





 Example 2 

Delete a root key and show the JSON output.

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

{
"id": "9cca88c9-019e-4f0a-9e76-8e657c6b9720",
"name": "my-root-key",
"type": "application/vnd.ibm.kms.key+json",
"extractable": false,
"state": 1,
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb145:390086ac-76fa-4094-8cf3-c0829bd69526:key:9cca88c9-019e-4f0a-9e76-8e657c6b9720"
}

 show key details
$ ibmcloud kp key show 9cca88c9-019e-4f0a-9e76-8e657c6b9720 --output json

{
"id": "9cca88c9-019e-4f0a-9e76-8e657c6b9720",
"name": "my-root-key",
"type": "application/vnd.ibm.kms.key+json",
"algorithmType": "AES",
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-05-05T20:03:00Z",
"lastUpdateDate": "2020-05-05T20:03:00Z",
"extractable": false,
"lastUpdateDate": "2020-06-09T21:23:26Z",
"keyVersion": {
"id": "264fadc3-7667-4b25-916e-5825fe70de0b",
"creationDate": "2020-06-09T21:21:55Z"
},
"extractable": false,
"state": 2,
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:390086ac-76fa-4094-8cf3-c0829bd69526:key:264fadc3-7667-4b25-916e-5825fe70de0b"
}







 Required parameters 



* KEY_ID_OR_ALIAS

The v4 UUID or alias of the key that you want to delete. To retrieve a list of your available keys, run the [kp keys](https://cloud.ibm.com/docs/key-protect-cli-pluginkp-keys) command.
* -i, --instance-id

The IBM Cloud instance ID that identifies your Key Protect instance.

You can set an environment variable instead of specifying -i with the following command: $ export KP_INSTANCE_ID=<INSTANCE_ID>.







 Optional parameters 



* --key-ring

A unique, human readable name for the key-ring. Required if the user doesn't have permissions on the default key ring.









 kp key enable 

When you enable a root key that was previously disabled, the key transitions from the Suspended (value is 2) to the Active (value is 1) 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.
Be sure to identify two distinct users with the [appropriate levels of access](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessservice-access-roles) to the instance or key.



To learn how to delete a key that has a dual authorization policy, see [Deleting keys using dual authorization](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-dual-auth-keys).



 Viewing a dual authorization policy for a key 

For a high-level view, you can retrieve the dual authorization policy for a single key by making a GET call to the following endpoint.

https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys/<key_ID>/policies?policy=dualAuthDelete



1. [Retrieve your authentication credentials to work with keys in the service](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-kms-api).

To work with dual authorization policies, you must be assigned a Manager access policy for the instance or key. To learn how IAM roles map to Hyper Protect Crypto Services actions, check out [Service access roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessservice-access-roles).
2. Retrieve the dual authorization policy for a specified key by running the following cURL command.

curl -X GET 
'https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/keys/<key_ID>/policies?policy=dualAuthDelete' 
-H 'authorization: Bearer <IAM_token>' 
-H 'bluemix-instance: <instance_ID>' 
-H 'accept: application/vnd.ibm.kms.policy+json'

Replace the variables in the example request according to the following table.



Table 1.