vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Consider assigning a label on your secret with encoded data, such as encode:base64, so that you can track secrets that require base64 decoding.
12. Optional: Enable expiration to control the lifespan of the secret.



1. To set an expiration date for the secret, switch the expiration toggle to Yes.



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







 Creating arbitrary secrets from the CLI 

To create an arbitrary secret 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. You can specify the type of secret by using the --secret-type arbitrary option. For example, the following command creates an arbitrary secret and stores secret-data as its value.

Secrets Manager supports text-based payloads only for arbitrary secrets. If you need to upload a binary file, you must base64 encode the data first so that you can pass it to the Secrets Manager CLI in a single-line string. To access this secret later in its original form, you need to base64 decode it. Consider assigning a label on your secret with encoded data, such as encode:base64, so that you can track secrets that require base64 decoding.

ibmcloud secrets-manager secret-create 
--secret-prototype='{"custom_metadata": {"anyKey": "anyValue"}, "description": "Description of my arbitrary secret."
The following example applies a secret that is stored in Key Protect to an IBM Cloud API key that is required by the [Pipeline tool integration](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-deliverypipeline). You can follow the same steps to apply secrets to any of the Continuous Delivery tool integrations that require secret values.

You must save third-party secrets, such as a Slack webhook or an Artifactory API token, in Key Protect before you create a new toolchain. You can mint and store only IBM-managed secrets such as IBM Cloud API keys in Key Protect while you work with your toolchain.



1. Click the key icon to retrieve secrets from secure stores such as Key Protect for the IBM Cloud API key.
2. In the Provider field, specify the provider and the name of the Key Protect tool integration that you use to manage your toolchain secrets. For example, to use the Key Protect tool integration, select Key Project: ibm-keyprotect-secrets-1. You can use other providers to manage your toolchain secrets, such as [HashiCorp Vault](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-hashicorpvault).
3. Select a secret name and click OK to apply the stored secret to the field that is associated with it.



Zoom

![Secret Reference to a Vault](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/secret-pill.png)

Figure 1. Secret reference to a vault

The name of the secret that you select appears in capsule form. You cannot edit the secret name inline, but you can click !
This API now supports public_cert secrets in addition to imported_cert.







 11 July 2021 

This release includes the following updates:



* Changed the maximum length for secret names to 240 characters.
* Changed the maximum length for secret descriptions to 1024 characters.







 20 June 2021 

This release includes the following updates:



* Added imported_cert secret type that can be used to store X.509 certificates in the service. For more information, see [Importing certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificates).
* Added the [Get a version of a secret](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2get-secret-version) method that can be used to retrieve the previous version of a secret. Currently, this API supports imported_cert secrets only.







 13 April 2021 

This release includes the following updates:



* Added group={secret_group_ID} query parameter that can be used to filter a list of secrets by secret group.







 7 March 2021 

This release includes the following updates:



* Added the reuse_api_key boolean parameter for IAM credential secrets.







 10 February 2021 

This release includes the following updates:



* Added the search={string} query parameter that can be used to filter a list of secrets that contain a specified string.
* Added the sort_by={field_name} query parameter that can be used to filter a list of secrets by a specified metadata field.







 25 January 2021 

This release includes the following updates:



* Changed the maximum length for secret names to 128 characters.
* Changed the maximum length for secret group names to 62 characters.
[Delivery Pipeline name](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/cd-only-satellite-pipeline-settings.png)

Figure 4. Delivery Pipeline name





 Step 3: Securely store secrets 

Several tools within this toolchain require secrets, such as an IBM Cloud API key. You must securely store all secrets in a secrets vault and reference them as required by the toolchain.

Using IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. In the Secrets step, you can specify which secret vault integrations to add or remove from your toolchain. For more information about adding and removing vault integrations, including prerequisites and by using hints, see [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud).

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.

This tutorial uses the [IBM Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started) as the secrets vault.

Zoom

![Secrets options](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/cd-only-satellite-secrets.png)

Figure 5. Secrets options

IBM Secrets Manager securely stores and applies secrets such as API keys, Image Signature, or HashiCorp credentials that are part of your toolchain.

Zoom

!
Configure the inventory repo 

The inventory repo records the details of the artifacts that are built by the continuous integration toolchains. You can either create a new inventory repo that is a clone of the [inventory repo template](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-inventory) or use an existing inventory repo that you share between toolchains.

Zoom

![VPC secure app inventory repo](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds-vpc-setup-inventory.png)

Figure 4. VPC secure app inventory repo

By default, the inventory repo template is cloned to your Git Repos and Issue Tracking org. To change the org, select Advanced options and specify the repo owner.





 Securely store secrets 

Several tools within this toolchain require secrets, such as an IBM Cloud API key. You must securely store all secrets in a secrets vault and reference them as required by the toolchain.

Using IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. In the Secrets step, you can specify which secret vault integrations to add or remove from your toolchain. For more information about adding and removing vault integrations, including prerequisites and by using hints, see [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud).

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.

This tutorial uses the [IBM Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started) as the secrets vault.

Zoom

!
Configure the inventory repo 

The inventory repo records the details of the artifacts that are built by the continuous integration toolchains. You can either create a new inventory repo that is a clone of the [inventory repo template](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-inventory) or use an existing inventory repo that you share between toolchains.

Zoom

![Kubernetes secure app inventory repo](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_inventory_repo.png)

Figure 4. Kubernetes secure app inventory repo

By default, the inventory repo template is cloned to your Git Repos and Issue Tracking org. To change the org, select Advanced options and specify the repo owner.





 Securely store secrets 

Several tools within this toolchain require secrets, such as an IBM Cloud API key. You must securely store all secrets in a secrets vault and reference them as required by the toolchain.

Using IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. In the Secrets step, you can specify which secret vault integrations to add or remove from your toolchain. For more information about adding and removing vault integrations, including prerequisites and by using hints, see [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud).

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.

This tutorial uses the [IBM Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started) as the secrets vault.

Zoom

!
: Version [1.12.6](https://cloud.ibm.com/docs/containers?topic=containers-istio-changelog1126) is available.





 13 April 2022 

IBM Cloud Object Storage plug-in
: Version 2.1.14 of the IBM Cloud Object Storage plug-in [is available](https://cloud.ibm.com/docs/containers?topic=containers-cos_plugin_changelog).





 12 April 2022 

Create and manage dedicated hosts in VPC Gen 2.
: You can now create clusters on dedicated hosts in VPC Gen 2. Note that support for dedicated hosts is available only for allowlisted accounts. For more information, see [Creating and managing dedicated hosts](https://cloud.ibm.com/docs/openshift?topic=openshift-dedicated-hosts).





 11 April 2022 

New! IBM Cloud® Secrets Manager
: With the deprecation of IBM Cloud® Certificate Manager, you can now manage certificates and secrets with IBM Cloud® Secrets Manager. You can integrate your own Secrets Manager instances with your Kubernetes clusters. Secrets Manager instances can be used across multiple clusters, and a single cluster can have more than one instance.

Block Storage for VPC add-on.
: [Version 4.2.3_983](https://cloud.ibm.com/docs/containers?topic=containers-vpc_bs_changelog) is available.

Worker node fix pack
: Kubernetes [1.23.5_1526](https://cloud.ibm.com/docs/containers?topic=containers-changelog_123), [1.22.8_1548](https://cloud.ibm.com/docs/containers?topic=containers-changelog_122), [1.21.11_1556](https://cloud.ibm.com/docs/containers?topic=containers-changelog_121), [1.20.15_1577](https://cloud.ibm.com/docs/containers?topic=containers-changelog_120).





 7 April 2022
"password": "cloudy-rainy-coffee-book",
"username": "user123"
}

Success! You're now able to fetch the secret data that is stored in your Secrets Manager instance. Continue to the next step.









 Step 4: Deploy an app to the cluster 

Finally, you can deploy an application in your cluster that uses the Secrets Manager secret that you defined in the external-secret-example.yml file. At application run time, the secret data that is fetched from Secrets Manager is converted to a Kubernetes secret that can be used by your cluster.

Looking for examples on how to deploy an app? Check out [Deploying Kubernetes-native apps in clusters](https://cloud.ibm.com/docs/containers?topic=containers-deploy_app) to find out more about deploying a single instance of an app.





 Step 5: (Optional) Clean up resources 

If you no longer need the resources that you created in this tutorial, you can complete the following steps to remove them from your account.



1. Delete your test Kubernetes cluster.

ibmcloud ks cluster rm --cluster my-test-cluster
2. Delete your test Secrets Manager instance.

ibmcloud resource service-instance-delete my-secrets-manager
3. Delete your authorization.

If you're using a service ID.

ibmcloud iam service-id-delete $SERVICE_ID

If you're working with a trusted profile.

ibmcloud iam trusted-profile-delete 'External Secrets'







 Best practices for using External Secrets Operator with Secrets Manager 

Secrets Manager sets a limit on the rate in which a client can send API requests to it. The limit is 20 calls per second for all API methods.

As you construct your [YAML document](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-tutorial-kubernetes-secretstutorial-kubernetes-secrets-update-deployment), keep in mind that each key in the data section is polled periodically by using REST from the Secrets Manager instance.
Alternatively, you can set the secret as the defaultCertificate in the [ibm-ingress-deploy-config ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationscomm-customize-deploy).

ibmcloud ks ingress secret create --cluster <cluster_name_or_ID> --cert-crn <CRN> --name <secret_name> --namespace <namespace>

To copy the secret with the ibmcloud ks ingress secret create command, you must have a default [Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr) instance registered to your cluster. If you do not have a Secrets Manager instance and your secrets are instead written directly to your cluster, your secrets do not have the required CRN value and you must manually copy them with kubectl commands.







 Setting up TLS secrets for custom subdomains 

If you define a custom subdomain in your Ingress resource, you can use your own TLS certificate to manage TLS termination. You must create a Kubernetes secret to store the TLS certificate, then import this secret into each namespace where your apps exist.

By storing custom TLS certificates in [Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr), you can import your certificates directly into a Kubernetes secret in your cluster.



1. Create or import a secret for the TLS certificate in the namespace where your Ingress resource exists. For example, you can import a secret from Secrets Manager into your cluster by running the following command. Specify the TLS certificate's CRN with the --cert-crn command option.

To import the secret with the ibmcloud ks ingress secret create command, you must have a default [Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr) instance registered to your 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::



You can specify a Secrets Manager instance and a secret group when you [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=cli) with the [ibmcloud oc cluster create classic](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clics_cluster_create) or [ibmcloud oc cluster create vpc-gen2](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clicli_cluster-create-vpc-gen2) commands. Use the --sm-instance option to register an instance to the cluster and the --sm-group option to specify a secret group that can access the secrets on the cluster. See [Registering a Secrets Manager instance when creating a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-secrets-mgrsecrets-mgr_cluster_create).





 Set a default Secrets Manager instance and regenerate your secrets 

When you set a default Secrets Manager instance, all new Ingress subdomain certificates are stored in that instance.



1. Run the command to set the new default instance. You can optionally specify a [secret group](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups) that is allowed access to the secrets in the instance.
ibmcloud ks 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::



You can specify a Secrets Manager instance and a secret group when you [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=cli) with the [ibmcloud ks cluster create classic](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clics_cluster_create) or [ibmcloud ks cluster create vpc-gen2](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clicli_cluster-create-vpc-gen2) commands. Use the --sm-instance option to register an instance to the cluster and the --sm-group option to specify a secret group that can access the secrets on the cluster. See [Registering a Secrets Manager instance when creating a cluster](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgrsecrets-mgr_cluster_create).





 Set a default Secrets Manager instance and regenerate your secrets 

When you set a default Secrets Manager instance, all new Ingress subdomain certificates are stored in that instance.



1. Run the command to set the new default instance. You can optionally specify a [secret group](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups) that is allowed access to the secrets in the instance.
Before a certificate can be issued to you, Secrets Manager checks to ensure that your certificate request matches the restrictions that are defined for the [certificate template](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificate-templates) that you select. After a certificate is issued, you can deploy it to your integrated apps, download it, revoke it, or rotate it manually.



 Creating private certificates in the UI 

You can create a private certificate by using the Secrets Manager UI.



1. In the console, click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/icon_hamburger.svg)> Resource List.
2. From the list of services, select your instance of Secrets Manager.
3. In the Secrets table, click Add.
4. Click the Create private certificate tile.
5. Click Next.
6. Add a name and description to easily identify your certificate.
7. Optional: Add labels to help you to search for similar secrets in your instance.
8. 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.



9. Click Next.
10. Select a certificate authority configuration.

The configuration that you select determines the certificate authority to use for signing and issuing the certificate. To view the configurations that are defined for your instance, you can go to Secrets engines > Private certificates.
11. Select a [certificate template](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificate-templates).

The template that you select determines the parameters to be applied to your generated certificate. To view the details of the certificate templates that are defined for your selected certificate authority, you can go to Secrets engines > Private certificates.
You can change key-value pairs for existing secrets.



 Updating secrets from the console 

You can update key-value pairs for your defined secrets from the console.



1. You can update key-value pairs for your defined secrets from the console in one of the following ways.



* Go to the Secrets and configmaps page for your project and locate the secret that you want to update. Click the name of the secret that you want to update to open it.
* If your secret is referenced by an app or job, then use the links in the environment variables table on the Environmental variables tab of your app or job. These links take you directly to your secret. Alternatively, you can also go to the Secrets and configmaps page for your project and locate the secret that you want to update. Click the name of the secret that you want to update to open it.



2. Click Edit and make the updates for your secret.
3. Click Save to save the changes to your secret.



If your updated secret is referenced by a job or app, then your job or app must be restarted for the new data to take effect.



* Apps - From the page for your app, click New revision and then Save and deploy. Alternatively, you can wait for your app to scale to zero and when the app scales up, the app uses the updated secret.
* Jobs - From the page for your job, click Submit job to run your job, or you can rerun a job. This new job run uses the updated secret.







 Updating secrets with the CLI 

You can update an existing secret and its key-value pairs with the CLI.



1. To change the value of a key-value pair in a defined secret, use the [secret update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-update) command. Let's update the mysecret-registry secret to use a different server.

ibmcloud ce secret update --name mysecret-registry --format registry --server <new_server> --username <new_username> --password <password>
2.
To access this secret later in its original form, you need to base64 decode it. Consider assigning a label on your secret with encoded data, such as encode:base64, so that you can track secrets that require base64 decoding.

ibmcloud secrets-manager secret-create 
--secret-prototype='{"custom_metadata": {"anyKey": "anyValue"}, "description": "Description of my arbitrary secret.", "expiration_date": "2023-10-05T11:49:42Z", "labels": ["dev","us-south"], "name": "example-arbitrary-secret", "secret_group_id": "default", "secret_type": "arbitrary", "payload": "secret-data", "version_custom_metadata": {"anyKey": "anyValue"}}'

The command outputs the ID value of the secret, along with other metadata. For more information about the command options, see [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).





 Creating arbitrary secrets with the API 

You can create arbitrary secrets programmatically by calling the Secrets Manager API.

The following example shows a query that you can use to create and store an arbitrary secret. When you call the API, replace the ID variables and IAM token with the values that are specific to your Secrets Manager instance.

You can store metadata that are relevant to the needs of your organization with the custom_metadata and version_custom_metadata request parameters. Values of the version_custom_metadata are returned only for the versions of a secret. The custom metadata of your secret is stored as all other metadata, for up to 50 versions, and you must not include confidential data.

Secrets Manager supports text-based payloads only for arbitrary secrets. If you need to upload a binary file, you must base64 encode the data first so that you can pass it to the Secrets Manager API in a single-line string.