vania-janet/multiturn-rag-retrieval-data huggingface dataset:
From the list of services, select your instance of Secrets Manager.
3. In the Secrets table, click Add.
4. From the list of secret types, select the User credentials tile.
5. Click Next.
6. Add a name and description to easily identify your secret.
7. Select the

secret groupthat you want to assign to the secret.

Don't have a secret group? In the Secret group field, you can click Create to provide a name and a description for a new group. Your secret is added to the new group automatically. For more information about secret groups, check out [Organizing your secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups).
8. Optional: Add labels to help you to search for similar secrets in your instance.
9. Optional: Add metadata to your secret or to a specific version of your secret.



1. Upload a file or enter the metadata and the version metadata in JSON format.



10. Click Next.
11. Enter the username and password that you want to associate with the secret.
12. Optional: Enable expiration and rotation options to control the lifespan of the secret.



1. To set an expiration date for the secret, switch the expiration toggle to Yes.
2. To rotate your secret at a 30, 60, or 90-day interval, switch the Automatic secret rotation toggle to Yes.



13. Click Next.
14. Review the details of your secret.
15. Click Add.







 Adding user credentials from the CLI 

To store a username and password by using the Secrets Manager CLI plug-in, run the [ibmcloud secrets-manager secret-create](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-secret-create-command) command.

ibmcloud secrets-manager secret-create
In this tutorial, you create a username and password as an example. To create a secret from the IBM Cloud CLI, you use the [ibmcloud secrets-manager secret-create](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-secret-create-command) command. Run the following command to create the secret and store its ID as an environment variable.

export SECRET_ID=ibmcloud secrets-manager username_password --resources '[{"name":"example_username_password","description":"Extended description for my secret.","secret_group_id":"'"$SECRET_GROUP_ID"'","username":"user123","password":"cloudy-rainy-coffee-book","labels":"my-test-cluster","tutorial"]}]' --output json | jq -r ".resources[].id"; echo $SECRET_ID

The output shows the ID of your newly created secret. For example:

e0246cea-d668-aba7-eef2-58ca11ad3707





 Step 3: Set up External Secrets Operator 

Now that you have a secret for your application, you can set up the [External Secrets Operator](https://external-secrets.io/latest/) tool for your cluster. This package configures the connection between Secrets Manager and your cluster by creating ExternalSecrets objects that are converted to Kubernetes secrets for your application.

External Secrets Operator is an open source tool that is not maintained by IBM. For more information about this tool or to troubleshoot any issues, refer to the [project documentation](https://external-secrets.io/latest/).



 Configure External Secrets Operator for your cluster 

First, add external-secrets resources to your cluster by installing the official Helm chart.
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Format: basic_auth
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 66s
Created: 2021-03-10T18:44:18-05:00

Data:
---
password: REDACTED
username: bXl1c2VybmFtZQ==







 ibmcloud ce secret list 

List all secrets in a project.

ibmcloud ce secret list [--all] [--format FORMAT] [--output OUTPUT] [--quiet] [--sort-by SORT_BY]



 Command Options 

--all, -a
: Display all secrets of all formats, including basic_auth, generic, registry, ssh, tls, and other secrets that are not managed by Code Engine. This value is optional. The default value is false.

--format, --fo
: Specify this option to filter the display of secrets. Valid values are basic_auth, generic, registry, ssh, and tls. This value is optional.

--output, -o
: Specifies the format of the command output. Valid values are json, yaml, jsonpath=JSONPATH_EXPRESSION, and jsonpath-as-json=JSONPATH_EXPRESSION. Use jsonpath to specify the path to an element of the JSON output. This value is optional.

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

--sort-by, -s
: Specifies the column by which to sort the list. Valid values are name and age. This value is optional. The default value is name.





 Example 

This command lists all secrets in a project.

ibmcloud ce secret list





 Example output 

Listing secrets...
OK

Name Format Data Age
[Actions icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/actions-icon-vertical.svg)> Manage access.
6. Select an access group to give its contained users and service IDs access to your secret group.
7. Choose a combination of [access roles](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam) to assign.

If you want to grant the users or service IDs in your access group the ability to access your Secrets Manager service instance from the Resource list in the IBM Cloud console, be sure to assign the [Viewer platform role](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iamiam-roles-actions).
8. Click Review.
9. Review your selections and click Assign.







 Assigning access to a secret group in the console 

You can also use the Access (IAM) section of the IBM Cloud console to manage access for your secret groups.

To assign access in the IBM Cloud console, be sure that you have the ID of the secret group that you want to manage. You can copy the ID of a secret group from the Secret groups table in your Secrets Manager service instance.



1. In the console, go to Manage > Access (IAM) > Access Groups.
2. In the row for the access group that you want to manage, click the Actions menu ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/actions-icon-vertical.svg)> Assign access.
3. Click Assign access.
4. From the list of services, select Secrets Manager and click Next.
5. In the Resources section, select Specific resources.



1.
ID: crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1-111a-1111-1a1a1a1111a1:
GUID: 111a1111-11a1-111a-1111-1a1a1a1111a1
Location: us-south
Service Name: secrets-manager
Service Plan Name: standard
Resource Group Name: default
State: active
Type: service_instance
Sub Type:
Created at: 2022-06-08T12:46:45Z
Created by: user@ibm.com
Updated at: 2022-06-08T12:54:45Z
2. Register the instance to your cluster. Specify the instance CRN found in the previous step.

If you want to register an instance to a cluster and also [set it as the default instance](https://cloud.ibm.com/docs/openshift?topic=openshift-secrets-mgrsecrets-mgr_setup_default), include the --is-default option. Otherwise, you can set a default instance with the ibmcloud oc ingress instance default set command.

ibmcloud oc ingress instance register --cluster <cluster_name_or_id> --crn <instance_crn> [--is-default]
3. Verify that the Secrets Manager instance was registered to the cluster.

ibmcloud oc ingress instance ls --cluster <cluster_name_or_id>

Example output.

Name Type Is Default Status Secret Group CRN
my-secrets-manager-instance secrets-manager false created default crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1-111a-1111-1a1a1a1111a1::
Option Format Description Supported secret types 

 Default --field <crn> The field name applied is the default field name for the secret type. All non-TLS secret types 
 Named --field <name>=<crn> The field name applied is the value specified for <name>. This option allows you to specify a custom name. <br><br> * Arbitrary /n - IAM credentials<br><br><br> 
 Prefixed --field <prefix>=<crn> The field name applied is the secret name in Secrets Manager, followed by an underscore and the default field name for the secret type. <br><br> * IAM credentials /n - username/password /n - key/value<br><br><br> 



The default field names are arbitrary for arbitrary secrets, api_key for IAM credentials, username or password for username and password secrets, and key for key values.

Review the example command to add a field and get the field details. This example adds a default, named, and prefixed field to a set of IAM credentials. You can [view the fields](https://cloud.ibm.com/docs/containers?topic=containers-secretsnon-tls-field-view) added to a secret by running kubectl get secret and viewing the data block of the output.

ibmcloud ks ingress secret field add --cluster example-cluster --name example-iam-secret --namespace default --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1 --field custom_iam_name=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1 --field prefix=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1
"description": "Extended description for my secret.",
"username": "user123",
"password": "cloudy-rainy-coffee-book",
"expiration_date": "2020-12-31T00:00:00Z",
"labels": [
"dev",
"us-south"
]
}'
Show more

Create user credentials in an existing secret group:

curl -X POST "https://{instance_id}.{region}.secrets-manager.appdomain.cloud/v1/ibmcloud/username_password/secrets/groups/{group_id}" -H 'Accept: application/json' -H 'X-Vault-Token: {Vault-Token}' -H 'Content-Type: application/json' -d '{
"name": "test-username-password-in-group",
"description": "Extended description for my secret.",
"username": "user123",
"password": "cloudy-rainy-coffee-book",
"expiration_date": "2020-12-31T00:00:00Z",
"labels": [
"dev",
"us-south"
]
}'
Show more

Import an SSL/TLS certificate and assign it to the default secret group.

curl -X POST "https://{instance_id}.{region}.secrets-manager.appdomain.cloud/v1/ibmcloud/imported_cert/secrets" -H 'Accept: application/json' -H 'X-Vault-Token: {Vault-Token}' -H 'Content-Type: application/json' -d '{
"name": "test-imported-certificate",
"description": "Extended description for my secret."
"certificate": "-----BEGIN CERTIFICATE-----nMIICWzCCAcQCC...(redacted)",
* If you plan to [expose apps with Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about), assign the user Administrator or Editor platform access role and the Manager service access role for Secrets Manager in All resource groups.
* Viewer platform access role for the resource group access.
* If your account [restricts service ID creation](https://cloud.ibm.com/docs/account?topic=account-restrict-service-id-create), the Service ID creator role to IAM Identity Service in the console (iam-identity in the API or CLI).
* If your account [restricts API key creation](https://cloud.ibm.com/docs/account?topic=account-allow-api-create), the User API key creator role to IAM Identity Service in the console (iam-identity in the API or CLI).
* If you plan to [encrypt your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkeyprotect):



* Assign the user the appropriate permission to the key management service (KMS) provider, such as the Administrator platform access role.
* For clusters that run Red Hat OpenShift 4.4.16_1513_openshift or later: When you enable KMS encryption, an additional Reader[service-to-service authorization policy](https://cloud.ibm.com/docs/account?topic=account-serviceauth) between Red Hat OpenShift on IBM Cloud and your KMS provider, such as Key Protect, is automatically created for your cluster, if the policy doesn't already exist. Without this policy, your cluster can't use all the [Key Protect features](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionkms-keyprotect-features).



* Viewer platform access role for the resource group access.



Infrastructure
:
Secrets Manager CLI change log 

In this change log, you can learn about the latest changes, improvements, and updates for the [IBM Cloud® Secrets Manager CLI plug-in](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-cli) (ibmcloud secrets-manager). The change log lists changes that have been made, ordered by the date they were released. Changes to existing CLI versions are designed to be compatible with existing client applications.

To learn about general updates and improvements to the Secrets Manager service, see [Release notes](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-release-notes).



 Version 2.0.1 

Version 2.0.1 was released on 19 April 2023. In this release, the CLI was updated to address an error that Windows users faced when they attempted to install the plug-in.





 Version 2.0.0 

Version 2.0.0 was released on 17 April 2023. All of the commands have been updated in this release. For more information, review the [CLI reference](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-change-log).

As of April 17, 2023, the IBM Cloud® Secrets Manager CLI v1 has been deprecated in favor of v2. If you're still actively working with the Secrets Manager CLI v1, please be sure to start your upgrade as soon as possible. On 31 October 2023, support for the Secrets Manager CLI v1 will be removed.





 Version 0.1.23 

Version 0.1.23 was released on 19 September 2022. This release includes the following update:
You can choose to register a Secrets Manager instance to your cluster during the cluster create process. You can also specify a secret group that you can use to control access to the secrets in your cluster. Both of these options can be configured or changed after you have created the cluster.

Encryption
: Data encryption with a key management service (KMS) encrypts secrets and other sensitive information in your cluster. You can add an existing KMS instance to your cluster during the cluster create process.

Cluster details
: You can customize the unique cluster name and any [tags](https://cloud.ibm.com/docs/account?topic=account-tag) that you want to use to organize and identify your IBM Cloud resources, such as the team or billing department.

Observability integrations
: You can enable additional observability integrations that you want to include on your cluster. Some integrations are automatically enabled if you have an existing platform instance of that integration. In this case, you cannot disable the integration. If you want to use an integration and you have only an existing application instance of that integration, the integration is disabled by default and you must manually enable it.
: 

* Activity tracking: Activity Tracker service captures a record of your IBM Cloud activities and monitors the activity of your account. You can use this service to investigate abnormal activity and critical actions, and comply with regulatory audit requirements. In addition, you can be alerted on actions as they happen. If you disable this integration and want to enable it later, see [Getting started with Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-startedgs_step2).



: 

* Logging: You can use Log Analysis to manage operating system logs, application logs, and platform logs. If you want to enable this integration later, see [Logging for clusters](https://cloud.ibm.com/docs/containers?topic=containers-health&interface=ui).



: 

* Monitoring: The monitoring service integration allows operational visibility into the performance and health of your applications, services, and platforms.
After you import key material into the service, keep in mind that you are responsible for managing the complete lifecycle of your key. By using the Key Protect API, you can set an expiration date for the key when you decide to upload it into the service.

However, if you want to [rotate an imported root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-rotate-keys), you must generate and provide new key material to retire and replace the existing key.







 Using import tokens 

If you want to encrypt your key material before you import it into Key Protect, you can create an import token for your Key Protect instance by using the Key Protect API.

Import tokens are a resource type in Key Protect that enable the secure import of key material to your Key Protect instance. By using the contents of an import token to encrypt your key material on-premises, you protect root keys while they're in flight to Key Protect based on the policies that you specify. For example, you can set a policy on the import token that limits its use based on time and usage count.



 How it works 

When you [create an import token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-import-tokens) for your Key Protect instance, Key Protect generates a 4096-bit RSA key-pair from its HSMs.

When you [retrieve the import token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-import-tokensretrieve-import-token-api), the service supplies the public key that you can use for encrypting and uploading a key to Key Protect.

The following list describes the import token workflow.



1. You send a request to create an import token.



1. Key Protect generates an RSA key-pair from its HSMs.
2. The public key becomes available for retrieval based on the policy that you specified at creation time.
3. The private key becomes non-extractable and never leaves the HSM.



2. You send a request to retrieve the import token.
From your IBM Cloud resource list, select your provisioned instance of Hyper Protect Crypto Services.
4. To import a key, select the KMS keys tab in the side menu.
5. In the Keys table, click Add key and select Import a key.

Specify the key's details:



Table 1. Describes the settings for importing a root key

 Setting Description 

 Key type The type of key that you would like to manage in Hyper Protect Crypto Services. From the list of key types, select [Root key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptsroot-key-concept). 
 Key name A unique, human-readable alias for easy identification of your key. To protect your privacy, ensure that the key name does not contain personally identifiable information (PII), such as your name or location. 
 Key alias (Optional) One or more unique, human-readable aliases that you want to assign to your key for easy recognition. Alias size can be 2 - 90 characters. You can set up to five key aliases for the key, with each separated by a comma.<br><br>Note: Each alias must be alphanumeric, case-sensitive, and cannot contain spaces or special characters other than dashes (-) or underscores (_). The alias cannot be a version 4 UUID and must not be a Hyper Protect Crypto Services reserved name: allowed_ip, key, keys, metadata, policy, policies, registration, registrations, ring, rings, rotate, wrap, unwrap, rewrap, version, versions. 
 Key ring ID Select a key ring from the list that contains the existing key rings. If you don't assign a key ring, the key will be added to the default key ring. For more information about key rings, see [Managing key rings](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-managing-key-rings). 
 Key material The base64 encoded key material, such as an existing key-wrapping key, that you want to store and manage in the service.
For more examples of PII, see section 2.2 of the [NIST Special Publication 800-122](https://www.nist.gov/publications/guide-protecting-confidentiality-personally-identifiable-information-pii).

A successful POST api/v2/keys response returns the ID value for your key, along with other metadata. The ID is a unique identifier that is assigned to your key and is used for subsequent calls to the Hyper Protect Crypto Services key management service API.
3. Optional: Verify that the key was added by running the following call to browse the keys in your Hyper Protect Crypto Services service instance.

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







 Importing root keys with the CLI 

Complete the following steps to import root keys by using the Key Protect CLI, which is integrated in Hyper Protect Crypto Services:



1. [Set up the Key Protect CLI](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-cli).
2. Import a root key with the following command:

ibmcloud kp key create

You can find more parameters for this command in the [Key Protect CLI reference](https://cloud.ibm.com/docs/key-protect?topic=key-protect-cli-plugin-key-protect-cli-referencekp-key-create).







 Base64 encoding your key material 

When importing an existing root key, it is required to include the encrypted key material that you want to store and manage in the service.



 Using OpenSSL to encode existing key material 



1. Download and install [OpenSSL](https://github.com/openssl/opensslfor-production-use).
2.
You can always [manage and update the network settings](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-managing-network-access-policies) after you provision and initialize the service instance. Use either the CLI or API to switch between a private-only network and a public-and-private network.





 Step 3: Target the Hyper Protect Crypto Services private endpoint for the TKE CLI plug-in 

To perform key management and cryptographic operations thought a private endpoint, you need to first target the private endpoint for the Trusted Key Entry (TKE) CLI plug-in.



1. From the command line, log in to IBM Cloud.

ibmcloud login

If the login fails, run the ibmcloud login --sso command to try again. The --sso parameter is required when you log in with a federated ID. If this option is used, go to the link listed in the CLI output to generate a one-time passcode.
2. Set the TKE_PRIVATE_ADDR environment variable to target the private endpoint for the Trusted Key Entry (TKE) plug-in. Replace with the [short name of the location](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regionsavailable-regions) that your service instance is created in.

export TKE_PRIVATE_ADDR=https://tke.private.<region>.hs-crypto.cloud.ibm.com

The TKE_PRIVATE_ADDR environment variable is used to set the API endpoint URL both for public endpoint and private endpoint. If you want to use the public endpoint, unset the TKE_PRIVATE_ADDR environment variable or set the TKE_PRIVATE_ADDR environment variable as the public endpoint URL: https://tke.<region>.hs-crypto.cloud.ibm.com.







 Step 4: Initialize the service instance