vania-janet/multiturn-rag-retrieval-data huggingface dataset:
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.

ibmcloud resource service-instance-create example-database <service-name> standard us-south -p '{
"backup_encryption_key_crn": "crn:v1:<...>:key:<id>"
}'





 Using the Key at Provision in the API 

In the API, use the backup_encryption_key_crn parameter in the body of the request.

curl -X POST https://resource-controller.cloud.ibm.com/v2/resource_instances -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{
"name": "my-instance",
"target": "blue-us-south",
"resource_group": "5g9f447903254bb58972a2f3f5a4c711",
"resource_plan_id": "databases-for-x-standard",
"backup_encryption_key_crn": "crn:v1:<...>:key:<id>"
}'

After you enable delegation and provisioned your deployment, two entries appear in your Authorizations in IAM. 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
Stand-alone data volumes that are encrypted by the suspended key can't be attached to an instance. 
 Snapshot unusable Snapshot cannot be used to restore a volume. 
 File shares stable Data on the file share is accessible but you can't create a file Share with that key. 
 Instance available Instance workloads continue to run with an available status in the CLI and API, and with a running status in the UI. If you stop instances, they can't restart. 



For more information about root key states from a KMS perspective, see the following topics.



* [Key Protect - Key states and transitions](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-stateskey-transitions)
* [Hyper Protect Crypto Services - Key states and transitions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-key-stateskey-transitions)







 Disable root keys 

When you disable a root key, you suspend its encryption and decryption operations. Disabling a root key in your KMS places the key in a suspended state, which makes it unusable for protecting a resource. The resources become unusable for normal operations. Temporarily disabling a root key is good practice if you suspect possible security exposure, compromise, or data breach. You can enable a disabled root key when the security threat is no longer active.

When you disable a root key, workloads continue to run in virtual server instances, and boot volumes remain encrypted. Data volumes remain attached. File share data is encrypted. However, if you stop the virtual server instance, it can't be restarted. You also can't provision a resource by using a disabled key. Before you disable a key, it's best to verify which resources are being protected by it.

To see which root keys are disabled, look in the UI list of resources. The status of volume and snapshot resources are unusable. File shares in a stable state remain so. The UI tooltip displays "key suspended" for the resource.
<br><br> * rate_period_seconds - Auto scaling rate period in seconds. -> [Scale up by rate_increase_percent every<br><br><br> 
 <br><br> * rate_units - Auto scaling rate in units.<br><br><br> 
 tags A list of tags that you want to add to your instance. 
 whitelist A list of allowed IP addresses for the database. Multiple blocks are allowed.Nested scheme for whitelist: 
 <br><br> * address - The IP address or range of database client addresses to be whitelisted in CIDR format.<br><br><br> 
 -description - A description for the allowed IP addresses range. 
 backup_id The CRN of a backup resource to restore from. The backup is created by a database deployment with the same service ID. The backup is loaded after provisioning and the new deployment starts up that uses that data. 
 backup_encryption_key_crn The CRN of a key protect key, that you want to use for encrypting disk that holds deployment backups. 
 key_protect_key The root key CRN of a Key Management Services like Key Protect or Hyper Protect Crypto Service (HPCS) that you want to use for disk encryption. 
 key_protect_instance The instance CRN of a Key Management Services like Key Protect or Hyper Protect Crypto Service (HPCS) that you want to use for disk encryption. 
 remote_leader_id A CRN of the leader database to make the replica(read-only) deployment. The leader database is created by a database deployment with the same service ID. A read-only replica is set up to replicate all of your data from the leader deployment to the replica deployment by using asynchronous replication. 











 Customizing a three-tier highly available infrastructure VPC in a multi-zone region with the catalog tile 



1. From the IBM Cloud catalog, select HA Infrastructure Deployment for 3-tier MZR.
2. Configure your workspace:



* Enter a name for the workspace.
* Select a Resource group.
* Select a Location for your workspace.
When you [create a Hyper Protect DBaaS for PostgreSQL service instance](https://cloud.ibm.com/docs/hyper-protect-dbaas-for-postgresql?topic=hyper-protect-dbaas-for-postgresql-gettingstartedcreating-a-database-cluster-introduction), select your Hyper Protect Crypto Services instance and root key.

The new Hyper Protect DBaaS for PostgreSQL service instance uses your Hyper Protect Crypto Services root key to protect your data encryption key. To check and manage your root key, click the Hyper Protect Crypto Services service instance on the Overview page of your Hyper Protect DBaaS for PostgreSQL service dashboard.

You can select the Hyper Protect Crypto Services key only when you create the DBaaS instance. Otherwise, a randomly generated key is used by default.





 Step 4 (Optional). Remove keys and delete your data 

If you delete the key that is used to encrypt your service, you lose access to the data. You can't recover the data from the instance (see [Deleting keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keys)). You might be able to recover your data by restoring a backup into a new service instance.

If you want to securely delete your data, you must delete both the service instance and the Hyper Protect Crypto Services key.
* UI
* API







 Connecting to external keystores 

You can use Unified Key Orchestrator to connect to external keystores with the IBM Cloud® console, or programmatically with the Unified Key Orchestrator API.

Before you connect to an external keystore, keep in mind the following considerations:



* You can connect to keystores that are external to your service instance on IBM Cloud®, or from other cloud providers such as Microsoft Azure Key Vault, Amazon Web Services (AWS) Key Management Service (KMS), and Google Cloud KMS.
* You can connect to one external keystore at no initial cost, regardless of the type. You are charged for additional external keystores. For more information about the pricing, see [FAQs: Pricing](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-pricing). Other currencies are applied based on the region the service instance is provisioned in.
* A managed key can be used for encryption and decryption only after you activate it in at least one target keystore.
* A target keystore can be assigned to only one vault.





 Setting up required user access in external keystores 

You need to set up user access before you use Unified Key Orchestrator to access keystores in third-party clouds.



 Setting up required user access in Azure Key Vault 

To set up user access to Azure Key Vault, complete the following steps:



1. [Create a service principal](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal) in Azure.
2. [Set up access policy](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy-portal) for the Key Vault, granting access to that service principal.



Unified Key Orchestrator requires the following access to be able to manage keys in Azure Key Vault:



* create
* import
* update
* list
* delete
* get
* recover
* purge
* backup
* restore
<br><br> * The number of backups per smart card: x<br> * The number of administrators (1 to 8): y<br> * The number of master key parts (2 or 3): z<br> * Store administrator signature keys separately from master key parts<br><br><br> 1 (CA card) + x (CA card backups) + y (administrator signature key EP11 cards)+ y * x (administrator signature key EP11 card backups) + z (master key part EP11 cards)+ z * x (master key part EP11 card backups) = (1+x) * (1+y+z) 
 <br><br> * The number of backups per smart card: x<br> * The number of administrators (1 to 8): y<br> * The number of master key parts (2 or 3): z<br> * Store an administrator signature key and a master key part on the same EP11 smart card<br> * The number of master key parts equals to the number of administrators (y = z)<br><br><br> 1 (CA card) + x (CA card backups) + z (administrator signature key and master key part EP11 cards)+ z * x (administrator signature key and master key part EP11 card backups) = (1+x) * (1+z) 



A backup certificate authority smart card can be created by using the Smart Card Utility Program. Select CA Smart Card > Backup CA smart card from the menu, and follow the prompts.

The contents of an EP11 smart card can be copied to another EP11 smart card that was created in the same smart card zone by using the Trusted Key Entry application. On the Smart card tab, click Copy smart card, and follow the prompts.

For greater security, you can generate administrator signature keys on more EP11 smart cards and set the signature thresholds in your crypto units to a value greater than one. You can install up to eight administrators in your crypto units and specify that up to eight signatures are required for some administrative commands.
"href": "https://uko.us-south.hs-crypto.cloud.ibm.com:9549/api/v4/keystores/b28bf13d-f49d-4b00-8b8d-457d38ad1e15"
},
"status": "not_present"
}
]
}







 hpcs uko key-templates 

List all key templates in the instance.

If the --all-pages option is not set, the command only retrieves a single page of the collection.

ibmcloud hpcs uko key-templates [--vault-id VAULT-ID] [--key-algorithm KEY-ALGORITHM] [--sort SORT] [--limit LIMIT] [--offset OFFSET]



* Command options

--vault-id (string)
: Optional. The UUID of the vault. The length must be 36 characters. The value must match the regular expression /^[-0-9a-z]+$/.

--key-algorithm (string)
: Optional. The algorithm of the returned key templates. Values that can be set are aes, rsa, hmac, and ec.

--sort ([]string)
: Optional. The sorting order. The default value is ["-updated_at"]. The list items must match the regular expression /^-?[a-z0-9_.\[\],-]+$/.

--limit (int64)
: Optional. The number of key templates to retrieve. The value must be between 1 and 1000.

--offset (int64)
: Optional. The number of keys to skip. The minimum value is 0.

--all-pages (bool)
: Invoke multiple requests to display all pages of the collection for key templates.
* Example

ibmcloud hpcs uko key-templates --output json
* Output

The command returns the output similar to the following example:

{
Recovering a master key from a recovery crypto unit 

If your service instance includes [recovery crypto units](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-instance-modeunderstand-recovery-crypto-unit), the current master key value in a recovery crypto unit can be used as a backup value for your operational crypto units. If you initialize service instances by using recovery crypto units (with the ibmcloud tke auto-init command) or rotate master keys using recovery crypto units (with the ibmcloud tke auto-mk-rotate command), this is the only backup value of the master key that exists for your service instance.

The value in the current master key register of a recovery crypto unit can be securely transferred to other current master key registers in service instances that are assigned to the current resource group by using the ibmcloud tke auto-mk-recover command.

You might need to use the command to recover the master key value in the following situations:



* You inadvertently zeroize a crypto unit and need to reinitialize it.
* You inadvertently clear the current master key register in a crypto unit.
* Your hardware fails and a crypto unit needs to be replaced.
* You need different service instances in the same resource group to use the same master key value.



Currently, only the us-south and us-east regions support recovery crypto units. Only service instances in these regions can use this command. For more information about supported regions, see [Regions and locations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regions).



 Before you begin 

To use the command, you need to make sure that the recovery crypto unit and all target crypto units meet the following requirements:



* They are not in imprint mode.
* They have the same signature threshold value.
* A common set of administrators is added to the recovery crypto unit and all target crypto units, which can meet the signature threshold value.
[Organize the keys in key rings](https://cloud.ibm.com/docs/key-protect?topic=key-protect-grouping-keys) for simpler management and enhanced security. 
 Hyper Protect Crypto Services Use [service-to-service authorizations](https://cloud.ibm.com/docs/account?topic=account-serviceauth&interface=ui) to share encryption keys. [Organize the keys in key rings](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-managing-key-rings) for simpler management and enhanced security. 
 Hyper Protect Crypto Services with Unified Key Orchestrator [Connect your Hyper Protect Crypto Services instance to keystores in IBM Cloud and third-party clouds](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-overview&interface=ui). 
 Secrets Manager [Integrations for Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-integrations) 
 Network 
 Transit Gateway [Connect across accounts with Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-aboutuse-case-5) 
 DNS Services [Sharing DNS zones across accounts in DNS Services](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-cross-account-about) 
 Account settings 
 Catalog Restricting available services in an account by utilizing [private catalogs and restricting the public catalog](https://cloud.ibm.com/docs/account?topic=account-filter-account) 
 Databases 
 IBM Cloudant [Data replication across accounts](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-replication-guidehow-to-run-replication-across-different-ibm-cloudant-accounts) 
 Cloud Databases [Restore backups across accounts](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-dashboard-backups)
* Error: When you check the status of the OADP backup utility after using it to backup a cluster where Discovery is installed, a Phase: PartiallyFailed message is displayed. One or more Discovery components are included in the Failed list.
* Cause: Discovery cannot be backed up and restored by using the OADP backup and restore utility. When the Discovery service is present, and an administrator backs up an entire IBM Cloud Pak for Data instance, a status message is displayed that indicates a partial failure. This status is displayed because the persistent volume claims (PVCs) for Discovery are not backed up. However, the message does not impact the back up of the rest of the services.
* Solution: No action is required to resolve the status message. You can remove the persistent volume claims that are associated with the Discovery service separately. After using the scripts to back up your Discovery service data, you can follow the step that is documented in the uninstall instructions for the Discovery service to delete the PVCs. For more information about how to remove the PVC associated with Discovery, see [Uninstalling the Discovery service](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=discovery-uninstalling-service).









 4.0.7, 30 March 2022 



* Discovery generates an error in the IBM Cloud Pak for Data OpenShift® APIs for Data Protection (OADP) backup and restore utility.



* Error: The utility does not complete successfully and the following message is written to the log: preBackupViaConfigHookRule on backupconfig/watson-discovery in namespace cpd (status=error)
* Cause: Discovery cannot be backed up and restored by using the OADP backup and restore utility. When the Discovery service is present, and an administrator attempts to backup an entire IBM Cloud Pak for Data instance, Discovery prevents the utility from completing successfully.
* Solution: Apply a patch that stops Discovery from preventing the utility from completing successfully.



1.
encryption_key = "crn:v1:bluemix:public:kms:us-south:a/dffc98a0f1f0f95f6613b3b752286b87:e4a29d1a-2ef0-42a6-8fd2-350deb1c647e:key:5437653b-c4b1-447f-9646-b2a2a4cd6179"
region = "us-south"
}
}

For more information about the arguments and attributes, see [ibm_is_backup_policy_plan](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_backup_policy_plan).







 Next steps 

After you create a backup policy, you can do the following actions.



* [Apply tags to your resources for backups](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-use-policies).
* [View a list of backup policies](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-view-policies) that you created.
* [Manage your backup policies and plans](https://cloud.ibm.com/vpc?topic=vpc-backup-service-manage).
More information on the Resource Controller API is found in its [API Reference](https://cloud.ibm.com/apidocs/resource-controllercreate-provision-a-new-resource-instance).





 Provisioning with Terraform 

If you use Terraform to manage your infrastructure, the [IBM Cloud provider for Terraform](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started) supports provisioning Cloud Databases deployments. A sample Terraform configuration file is on the [Cloud Databases resources](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/database) documentation page.





 List of Additional Parameters 



* backup_id- A CRN of a backup resource to restore from. The backup must be created by a database deployment with the same service ID. The backup is loaded after provisioning and the new deployment starts up that uses that data. A backup CRN is in the format crn:v1:<...>:backup:<uuid>. If omitted, the database is provisioned empty.
* version - The version of the database to be provisioned. If omitted, the database is created with the most recent major and minor version.
* disk_encryption_key_crn - The CRN of a KMS key (for example, [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) or [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about)), which is then used for disk encryption. A KMS key CRN is in the format crn:v1:<...>:key:<id>.
Instance available Instance workloads continue to run with an available status in the CLI and API, and with a running status in the UI. If you stop instances, they can't restart. 



For more information about root key states from a KMS perspective, see the following topics.



* [Key Protect - Key states and transitions](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-stateskey-transitions)
* [Hyper Protect Crypto Services - Key states and transitions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-key-stateskey-transitions)







 Disable root keys 

When you disable a root key, you suspend its encryption and decryption operations. Disabling a root key in your KMS places the key in a suspended state, which makes it unusable for protecting a resource. The resources become unusable for normal operations. Temporarily disabling a root key is good practice if you suspect possible security exposure, compromise, or data breach. You can enable a disabled root key when the security threat is no longer active.

When you disable a root key, workloads continue to run in virtual server instances, and boot volumes remain encrypted. Data volumes remain attached. File share data is encrypted. However, if you stop the virtual server instance, it can't be restarted. You also can't provision a resource by using a disabled key. Before you disable a key, it's best to verify which resources are being protected by it.

To see which root keys are disabled, look in the UI list of resources. The status of volume and snapshot resources are unusable. File shares in a stable state remain so. The UI tooltip displays "key suspended" for the resource. In the API response, you can see an encryption_key_disabled reason code.
If you use Terraform to manage your infrastructure, the [IBM Cloud provider for Terraform](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started) supports provisioning Cloud Databases deployments. Find a sample Terraform configuration file at [Cloud Databases Resources](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/database).





 List of Additional Parameters 



* backup_id- A CRN of a backup resource to restore from. The backup must be created by a database deployment with the same service ID. The backup is loaded after provisioning and the new deployment starts up that uses that data. A backup CRN is in the format crn:v1:<...>:backup:<uuid>. If omitted, the database is provisioned empty.
* version - The version of the database to be provisioned. If omitted, the database is created with the most recent major and minor version.
* disk_encryption_key_crn - The CRN of a KMS key (for example, [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) or [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about)), which is then used for disk encryption. A KMS key CRN is in the format crn:v1:<...>:key:<id>.
* backup_encryption_key_crn - The CRN of a KMS key (for example, [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) or [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about)), which is then used for backup encryption.