vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Initializing service instances using recovery crypto units 

Before you can use your Hyper Protect Crypto Services instance, you need to first initialize your service instance by loading the master key. This topic guides you through the steps to initialize your service instance by using recovery crypto units through IBM Cloud TKE CLI plug-in.

For an introduction to the approaches of service instance initialization and the related fundamental concepts, see [Initializing service instances](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-introduce-service) and [Introducing service instance initialization approaches](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-instance-mode).

Currently, only the us-south and us-east regions are enabled with the recovery crypto units, which means, when a service instance is provisioned in either regions, you are by default enabled with the option to back up your master keys in the recovery crypto units located in both regions. For more information about supported regions, see [Regions and locations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regions).

If smart cards are used to initialize the service instance, the recovery crypto units are not applicable and can be ignored. The backup of the master key relies on the backup of the smart cards in that case.

You can automate the instance initialization with recovery crypto units by using Terraform. For more information, see [Setting up Terraform for Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-terraform-setup-for-hpcs).



 Initializing service instances 

To initialize your service instance using recovery crypto units, complete the following steps:



1. Complete [the prerequisite steps](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm-prerequisite).
2. Run the following command:

ibmcloud tke auto-init

Follow this procedure to initialize your service instance.
Generating an SSH key pair with the PuTTY Key Generator" caption-side="bottom"}

You can select one of the supported cryptographic algorithms from the PuTTY Key Generator by clicking an appropriate option for the Type of key to generate. For the ECDSA option, a pull-down choice appears where you must additionally select a Curve to use for generating this key (either nistp256, nistp384, or nistp521).

You must then save the private, and optionally the public key, into separate files by pressing the appropriate buttons (Save public key, Save private key). To reuse the public key saved this way for creating a virtual server, ensure that you use the OpenSSH public key format that is recognized by Hyper Protect Virtual Servers.

You must store the keys in a safe location and take a backup of the keys. Virtual Server upgrade scenarios require signing with the original keys that were used to create the virtual server.

To create a virtual server with a PuTTY public SSH key, you have the following choices:



* To create the virtual server directly after the key pair generation, copy the public key from the Key box. Include the string 'ssh-rsa' at the beginning, but delete the key comment at the end as shown in Figure 2.
* To create the virtual server after the PuTTY Key Generator dialog is already closed, you can use the public key from a saved file in the OpenSSH public key format.



![SSH key pair from the PuTTY Key Generator ready for use](https://cloud.ibm.com/docs-content/v1/content/29e0ddc9fd7149f916889ba6a4d131cc3528c9bc/hp-virtual-servers/image/hpvs_putty_pubkey.gif){: caption="Figure 2. SSH key pair from the PuTTY Key Generator ready for use" caption-side="bottom"}





 Converting an OpenSSH key pair for logging-in to a virtual server from PuTTY 

Imagine you have an existing virtual server, which you want to configure in the PuTTY Configuration utility for a convenient log-in to this server.
Introducing Unified Key Orchestrator 

With Hyper Protect Crypto Services with Unified Key Orchestrator, you can manage keys not only for your internal keystores, but across multiple cloud providers, including Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform. All your keys in all those places are protected by your own master key, which is stored in a FIPS 140-2 Level 4-certified hardware security module (HSM) for the highest security. You can manage the lifecycles of your keys from a single point of control, while the system keeps keys that are distributed in sync.

With Unified Key Orchestrator, you can organize everything in vaults. Vaults are secure repositories that bundle your managed keys and the target keystores to distribute managed keys to. You can use vaults to grant access to different Identity and Access Management (IAM) user groups.



 Use case example 

In the following example, your retail banking business unit, reflected as one user group, uses a vault called Retail Banking BU. Another business unit, reflected as another user group, uses their own vault to keep their managed keys and target keystores separate.

You connect vault Retail Banking BU to three external keystores in different locations, in this example, three Azure Key Vaults. You can also connect your vault to other external keystore types if needed, such as AWS Key Management Service, IBM® Key Protect, or other Hyper Protect Crypto Services instances. Then, you create managed keys in vault Retail Banking BU and distribute the keys to those three external keystores in Azure.

For development and test purposes, you create a few more keys in the same vault and an internal KMS keystore to distribute the keys to.

You activate a key in multiple internal or external keystores in the same vault. When you make changes to the key, for example, changing the key state from Active to Deactivated, the change is applied to all keystores that the key is activated in.

Zoom

!
"attach_user_tags": [
"daily-backups"
],
"copy_user_tags": true,
"cron_spec": "30 /2 * * 1-5",
"deletion_trigger": {
"delete_after": 20,
"delete_over_count": 20
},
"remote_region_policies": {
"delete_over_count": 5,
"encryption_key": [
{
"CRN": "crn:v1:bluemix:public:kms:us-south:a/dffc98a0f1f0f95f6613b3b752286b87:e4a29d1a-2ef0-42a6-8fd2-350deb1c647e:key:5437653b-c4b1-447f-9646-b2a2a4cd617"
}
],
"region": [
{
"name":"us-east"
}
]
},
"name": "my-daily-plan-2"
}'

A successful response shows that the remote region policy is created.

{
"active": true,
"attach_user_tags": [
"hourly-backups"
],
"copy_user_tags": false,
"created_at": "2023-05-09T15:16:37Z",
"cron_spec": "0 /2 * * ",
"deletion_trigger": {
"delete_after": 5
},
* UI
* API







 Disabling and enabling root keys 

You can use IBM® Key Protect for IBM Cloud® to disable or enable a root key and temporarily revoke access to the key's associated data on the cloud.

As an admin, you might need to temporarily disable a root key if you suspect a possible security exposure, compromise, or breach with your data. When you disable a root key, you suspend its encrypt and decrypt operations. After confirming that a security risk is no longer active, you can restore access to your data by enabling the disabled root key.

If you are using a Cloud Service that is integrated with Key Protect, your data might not be accessible after disabling a root key. To determine whether an [integrated service](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-services) supports revoking access to data by disabling a Key Protect root key, refer to its service documentation.



 Disabling or enabling a root key 



 Disabling a root key 

When you disable a root key that was previously enabled, the key transitions from the [Active](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-states) to the [Suspended](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-states) key state. This action mean the key can no longer be used to cryptographically protect data.

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
"deleted": {
"more_info": "https://cloud.ibm.com/apidocs/vpcdeleted-resources"
},
"href": "https://us-south.iaas.cloud.ibm.com/v1/snapshots/f6bfa329-0e36-433f-a3bb-0df632e79263",
"id": "f6bfa329-0e36-433f-a3bb-0df632e79263",
"name": "my-snapshot",
"resource_type": "snapshot"
}
}
<-- </section "id="section-backup-view-jobs-details-api" "> --><-- <section "id="section-backup-jobs-status" "> --> Backup job statuses and reason codes When you view details of a backup job by making a GET /backup_policies/{backup_policy_id}/jobs/{backup_job_id} request, the status property indicates whether the job failed, is running, or succeeded. The API also provides status reasons, with the following codes:<-- <ul> --> * internal_error: Indicates an internal error. Contact IBM support if your see this code. * snapshot_pending: Indicates that backup snapshot in the pendingsnapshot lifecycle state]Snapshot statuses] cannot be deleted. * snapshot_volume_limit: Indicates that the snapshot limit]] ! ! ! ! for the source volume is reached.
"attach_user_tags": [
"daily-backups"
],
"copy_user_tags": true,
"cron_spec": "30 /2 * * 1-5",
"deletion_trigger": {
"delete_after": 20,
"delete_over_count": 20
},
"remote_region_policies": {
"delete_over_count": 5,
"encryption_key": [
{
"CRN": "crn:v1:bluemix:public:kms:us-south:a/dffc98a0f1f0f95f6613b3b752286b87:e4a29d1a-2ef0-42a6-8fd2-350deb1c647e:key:5437653b-c4b1-447f-9646-b2a2a4cd617"
}
],
"region": [
{
"name":"us-east"
}
]
},
"name": "my-daily-plan-2"
}'
Show more

A successful response shows that the remote region policy is created.

{
"active": true,
"attach_user_tags": [
"hourly-backups"
],
"copy_user_tags": false,
"created_at": "2023-05-09T15:16:37Z",
"cron_spec": "0 /2 * * ",
"deletion_trigger": {
"delete_after": 5
},
From the Actions menu, click Delete license.
4. In the Notes field, optionally enter a reason for license deletion.
5. Enter the license name to confirm deletion and click Delete. The status of the license is changed to Removing.



When the license deletion is complete, the license is no longer listed in the Zerto licenses table and you receive an email that confirms the license deletion.

The license charge is reflected on your account until the end of the billing cycle, which is typically 30 days.





 Related links 



* [Zerto overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-addingzertodr)
* [Managing Zerto](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-managingzertodr)
* [Ordering Zerto licenses](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-zerto_ordering_licenses)
* [Zerto](https://www.zerto.com)
* [Zerto technical documentation](https://www.zerto.com/myzerto/technical-documentation/)
* A STRUCTURE using either shorthand or JSON syntax.



* Flag: --delete STRUCTURE
* Shorthand Syntax: --delete 'Objects=[{Key=string},{Key=string}],Quiet=boolean'
* JSON Syntax: --delete file://<filename.json> ======= The --delete command takes a JSON structure listing the objects to delete. In this example, the file:// prefix is used to load the JSON structure from the specified file.





{
"Objects": [
{
"Key": "string",
"VersionId": "string"
}
...
],
"Quiet": true|false
}



* Optional: The REGION where the bucket is present. If this flag is not provided, the program uses the default option that is specified in config.



* Flag: --region REGION



* Optional: Output FORMAT can be only json or text.



* Flag: --output FORMAT











 Download an object 



* Action: Download an object from a bucket in a user's IBM Cloud Object Storage account.
* Usage:ibmcloud cos object-get --bucket BUCKET_NAME --key KEY [--if-match ETAG] [--if-modified-since TIMESTAMP] [--if-none-match ETAG] [--if-unmodified-since TIMESTAMP] [--range RANGE] [--response-cache-control HEADER] [--response-content-disposition HEADER] [--response-content-encoding HEADER] [--response-content-language HEADER] [--response-content-type HEADER] [--response-expires HEADER] [--region REGION] [--output FORMAT] [OUTFILE]
* Parameters to provide:



* The name of the bucket.



* Flag: --bucket BUCKET_NAME



* The KEY of the object.



* Flag: --key KEY
Environment Variable: export KUBECONFIG=/user/myusername/.bluemix/plugins/code-engine/myproject-01234567-abcd-abcd-abcd-abcdabcd1111.yaml







 ibmcloud ce project delete 

Delete a project.

ibmcloud ce project delete (--name PROJECT_NAME | --id PROJECT_ID) [--force] [--hard] [--no-wait] [--quiet] [--wait] [--wait-timeout WAIT_TIMEOUT]



 Command Options 

--force, -f
: Force deletion without confirmation. This value is optional. The default value is false.

--hard
: Immediately delete the project. If you do not specify the --hard option, the project can be restored within 7 days by using either the project restore or the reclamation restore command. This value is optional. The default value is false.

--id, --guid
: The ID of the project. This value is required if --name is not specified.

--name, -n
: The name of the project. This value is required if --id is not specified.

--no-wait, --nw
: Delete the project and do not wait for the project to be deleted. If you specify the no-wait option, the project delete begins and does not wait. Use the project get command to check the project status. This value is optional. The default value is false.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.

--wait, -w
: Delete the project and wait for the project to be deleted. If you specify the --wait option, the project delete waits for a maximum time in seconds, as set by the --wait-timeout option, for the project to become deleted. If the project is not deleted within the specified --wait-timeout period, the project delete fails.
Click the Restore Key button to open the restore side panel.
7. Click Restore Key button.
8. Confirm the key was restored in the updated Keys table.







 Restoring a deleted key with the API 

Restore a previously imported key by making a POST call to the following endpoint:

https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/restore



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

To restore a key, you must have the Manager role for the instance or key. To learn how IAM roles map to Key Protect service actions, check out [Service access roles](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessmanage-access-roles).
2. Retrieve the ID of the key that you want to restore.

You can retrieve the ID for a specified key by making a [list keys request](https://cloud.ibm.com/apidocs/key-protectlist-keys) request, or by viewing your keys in the Key Protect dashboard. For more information, check out [Viewing a list of keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keys).
3. Run the following curl command to restore the key and regain access to its associated data. Note that you must wait 30 seconds after deleting a key before you are able to restore it.

You cannot restore a key that has an expiration date that is current or in the past.

$ curl -X POST "https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/restore" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>" -H "x-kms-key-ring: <key_ring_ID>"
Red Hat OpenShift on IBM Cloud version 4.13 compliance operator benchmark 

Review the compliance operator benchmark results for Red Hat OpenShift on IBM Cloud version 4.13.

Missing results are being investigated.



 1 Control plane components 



 1.1 Master node configuration files 

The master node configuration is not stored as a set of files; therefore, rules in section 1.1 are out of the scope of the automated check by the compliance operator.





 1.2 API server 



Section 1.2 API server benchmark results

 Section Recommendation Manual/Automated Level Result 

 1.2.1 Ensure that anonymous requests are authorized. Manual 1 Pass 
 1.2.2 Ensure that the --basic-auth-file option is not set. Automated 1 Pass 
 1.2.3 Ensure that the --token-auth-file parameter is not set. Automated 1 Pass 
 1.2.4 Use https for kubelet connections. Automated 1 [Fail](https://cloud.ibm.com/docs/openshift?topic=openshift-benchmarks_413_coco-benchmark-413-remdiations) 
 1.2.5 Ensure that the kubelet uses certificates to authenticate. Automated 1 Pass 
 1.2.6 Verify that the kubelet certificate authority is set as appropriate. Automated 1 Pass 
 1.2.7 Ensure that the --authorization-mode option is not set to AlwaysAllow. Automated 1 Pass 
 1.2.8 Verify that the Node authorizer is enabled. Automated 1 Pass 
 1.2.9 Verify that RBAC is enabled. Automated 1 Pass 
 1.2.10 Ensure that the APIPriorityAndFairness feature gate is enabled. Manual 1 Pass 
 1.2.11 Ensure that the admission control plug-in AlwaysAdmit is not set. Automated 1 Pass 
 1.2.12 Ensure that the admission control plug-in AlwaysPullImages is not set. Manual 1 Pass 
 1.2.13 Ensure that the admission control plug-in SecurityContextDeny is not set. Manual 1 Pass
[Istio](https://www.ibm.com/cloud/info/istio) is an open platform to connect, secure, control and observe microservices, also known as a service mesh, on cloud platforms such as Kubernetes in Red Hat OpenShift on IBM Cloud.



 Objectives 



* Install Red Hat OpenShift Service Mesh in your cluster
* Deploy the BookInfo sample app
* Use metrics, logging and tracing to observe services
* Set up the Istio Ingress Gateway
* Perform simple traffic management, such as A/B tests and canary deployments
* Secure your mesh using mTLS



Zoom

![Architecture Diagram](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution57-openshift-service-mesh/Architecture.png)

Figure 1. Architecture diagram of the tutorial



1. The admin provisions a Red Hat OpenShift on IBM Cloud cluster and installs the Service Mesh Operator along with other Telemetry Operators.
2. Admin creates an istio-system namespace(project) and creates ServiceMeshControlPlane.
3. Admin creates a bookinfo namespace with automatic sidecar injection enabled and deploys the BookInfo app (with four separate microservices) in to the Service Mesh.
4. Admin exposes the app for external traffic with the Istio Ingress Gateway.
5. The user securely(HTTPS) accesses the application via browser.
6. The admin monitors the health and performance of the microservices using the metrics, traces, logs.







 Before you begin 

This tutorial requires:



* IBM Cloud CLI,



* IBM Cloud Kubernetes Service plugin (kubernetes-service),



* oc to interact with OpenShift.
Monitoring cluster health 

For cluster metrics and app monitoring, Red Hat® OpenShift® on IBM Cloud® clusters include built-in tools to help you manage the health of your single cluster instance. You can also set up IBM Cloud tools for multi-cluster analysis or other use cases, such as IBM Cloud Kubernetes Service add-ons: IBM Log Analysis and IBM Cloud Monitoring.



 Understanding options for monitoring 

To help understand when to use the built-in Red Hat OpenShift tools or IBM Cloud integrations, review the following information.



 IBM Cloud Monitoring 

Review the following details about IBM Cloud Monitoring.



* Customizable user interface for a unified look at your cluster metrics, container security, resource usage, alerts, and custom events.
* Quick integration with the cluster via a script.
* Aggregated metrics and container monitoring across clusters and cloud providers.
* Historical access to metrics that is based on the timeline and plan, and ability to capture and download trace files.
* Highly available, scalable, and compliant with industry security standards.
* Integrated with IBM Cloud IAM for user access management.
* Free trial to try out the capabilities.
* To get started, see [Forwarding cluster and app metrics to IBM Cloud Monitoring](https://cloud.ibm.com/docs/openshift?topic=openshift-health-monitoropenshift_monitoring).



For more information, see [Monitoring](https://docs.openshift.com/container-platform/4.11/monitoring/monitoring-overview.html).





 Built-in Red Hat OpenShift monitoring tools 

Review the following details about built-in monitoring tools for your cluster.



* Built-in Prometheus and Grafana deployments in the openshift-monitoring project for cluster metrics.
* At-a-glance, real-time view of how your pods consume cluster resources that can be accessed from the Red Hat OpenShift Cluster Console.
* Monitoring is on a per-cluster basis.
* The openshift-monitoring project stack is set up in a single zone only. No persistent storage is available to back up or view metric history.
You must be assigned the Editor platform access role and the Manager service access role for Red Hat OpenShift on IBM Cloud. For more information, see [User access permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference).
3. Verify that you entered the etcd API endpoint for your Databases for etcd service instance in the correct format.



1. [Retrieve the Databases for etcd endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store).
2. Add the etcd endpoint in the format etcd:<etcd_endpoint1>;etcd:<etcd_endpoint2>. If you have more than one endpoint, include all endpoints and separate them with a semicolon (;).

Example endpoint:

etcd:https://1ab234c5-12a1-1234-a123.databases.appdomain.cloud:32059



4. Verify that you stored the credentials to access your Databases for etcd service instance in a Kubernetes secret in your cluster. For more information, see [Setting up a Databases for etcd service instance for Portworx metadata](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store).



1. Review steps 4-6 and verify that you retrieved the correct username, password, and certificate.
2. List the secrets in your cluster and look for the secret that holds the credentials of your Databases for etcd service instance.

oc get secrets
3. Make sure that the username, password, and certificate are stored as a base64 encoded value in your Kubernetes secret.
4. Verify that you entered the correct name of the secret in the IBM Cloud catalog.



5.