vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: Version 0.1.22 of the Secrets Manager CLI is now available for download. To learn about the latest updates, see the [CLI change log](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-change-log).

New custom metadata fields
: The documentation for creating secrets and managing versions of a secret is now updated to include custom_metadata and version_custom_metadata fields. To learn more about the latest updates, see [Creating secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-arbitrary-secrets&interface=ui) and [Managing secret versions](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-version-history&interface=ui).

New Secrets Manager event notifications
: The following notifications for events related to Secret Locks are now available.



* secret_deletion_blocked: Now available for arbitrary secrets, IAM credentials, user credentials, key value, imported certificates, private certificates, and public certificates.
* secret_revocation_blocked: Now available for private certificates.
* secret_rotation_blocked: Now available for arbitrary secrets, IAM credentials, user credentials, key value, imported certificates, private certificates, and public certificates.
* secret_expiration_blocked: Now available for arbitrary secrets, IAM credentials, and user credentials.
* secret_version_data_deleted: Now available for arbitrary secrets, IAM credentials, user credentials, key value, imported certificates, private certificates, and public certificates.



For more information about using Event Notifications to enable lifecycle notifications for your Secrets Manager instance, see [Enabling event notifications](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-event-notifications).





 1 August 2022 

Improved authorization flow
: The documentation for granting service access to domains is now updated to simplify the required flow. To try out the latest updates, see [Granting service access to CIS](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesauthorize-domains).
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 key-value secrets with the API 

You can create key-value secrets programmatically by using the Secrets Manager API.

The following example shows a query that you can use to create and store a key-value 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.

curl -X POST
-H "Authorization: Bearer {iam_token}" -H "Accept: application/json" -H "Content-Type: application/json" -d '{
"name": "example-kv-secret",
"description": "Description of my kv secret.",
"secret_type": "kv",
"secret_group_id": "67d025e1-0248-418f-83ba-deb0ebfb9b4a",
"labels": [
"dev",
"us-south"
],
"data": {
"key1": "val1",
"key2": "val2"
},
"custom_metadata": {
"metadata_custom_key": "metadata_custom_value"
},
"version_custom_metadata": {
"custom_version_key": "custom_version_value"
}
}' 
"https://{instance_ID}.
You can restore one version back on [supported secret types](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-automatic-rotation&interface=uibefore-auto-rotate-supported-secret-types). For auditing purposes, the service retains the metadata of up to 50 versions for each secret, which you can review as part of a secret's [version history](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-version-history).



 Supported secret types 

Restoring to a previous version is supported for [IAM credentials](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam-credentials) and [public certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-public-certificates).







 Restoring a previous version with the API 

You can use the Secrets Manager API to restore a secret to its previous version.

The following example request restores the previous version of a secret. When you call the API, replace the ID variables and IAM token with the values that are specific to your Secrets Manager instance. Allowable values for {secret_type} are: iam_credentials, public_cert

To list the versions of a secret and obtain the ID of each version, use the [List versions API](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-version-history&interface=apiversions-api).

curl -X POST
--H "Authorization: Bearer {iam_token}" --H "Accept: application/json" --H "Content-Type: application/json" --d '{
"restore_from_version": "previous",
"custom_metadata": {
"metadata_custom_key": "metadata_custom_value"
},
"version_custom_metadata": {
"custom_version_key": "custom_version_value"
}
}' 
"https://{instance_ID}.
: Fixes LibSass vulnerabilities for [CVE-2018-19218](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19218).

Disruptive
: None





 28 October 2019 

The following changes occurred for the ee01ba3471cadbb9925269183acd724f4bf0e5bd Fluentd component.

Non-disruptive changes
: Fixes Ruby vulnerabilities - [CVE-2019-15845](https://www.ruby-lang.org/en/news/2019/10/01/nul-injection-file-fnmatch-cve-2019-15845/) - [CVE-2019-16201](https://www.ruby-lang.org/en/news/2019/10/01/webrick-regexp-digestauth-dos-cve-2019-16201/) - [CVE-2019-16254](https://www.ruby-lang.org/en/news/2019/10/01/http-response-splitting-in-webrick-cve-2019-16254/) - [CVE-2019-16255](https://www.ruby-lang.org/en/news/2019/10/01/code-injection-shell-test-cve-2019-16255/)

Disruptive
: None





 24 September 2019 

The following changes occurred for the 58c604236080f142f35d14fe3b6c4b4484290121 Fluentd component.

Non-disruptive changes
* [CVE-2021-3800](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3800)
* [CVE-2019-18218](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18218)
* [CVE-2020-12762](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12762)
* [CVE-2020-16135](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16135)
* [CVE-2021-20266](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20266)
* [CVE-2021-33928](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33928)
* [CVE-2021-33929](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33929)
* [CVE-2021-33930](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33930)
* [CVE-2021-33938](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33938)
* [CVE-2021-3200](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3200)
* [CVE-2020-13434](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13434)
* [CVE-2020-13543](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13543)
* [CVE-2020-13584](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13584)
* [CVE-2020-13776](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13776)
* [CVE-2020-15358](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15358)
* [CVE-2020-24330](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24330)
* [CVE-2020-24331](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24331)
* [CVE-2020-24332](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24332)
* [CVE-2020-24977](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977)
* [CVE-2020-27618](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27618)
Note: To find the version ID of a secret, use the Get secret metadata method and check the response details. Required.

The value must match regular expression /^([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}|previous)$/.





 Examples 

ibmcloud secrets-manager secret-version-metadata --secret-type=arbitrary --id=exampleString --version-id=exampleString







 ibmcloud secrets-manager secret-version-metadata-update 

Update the metadata of a secret version, such as version_custom_metadata.

ibmcloud secrets-manager secret-version-metadata-update --secret-type SECRET-TYPE --id ID --version-id VERSION-ID --metadata METADATA --resources RESOURCES



 Command options 

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

Allowable values are: arbitrary, iam_credentials, imported_cert, public_cert, private_cert, username_password, kv.

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

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

--version-id (string)
: The v4 UUID that uniquely identifies the secret version. You can also use previous to retrieve the previous version.

Note: To find the version ID of a secret, use the Get secret metadata method and check the response details. Required.
In particular, this means vaulting the required secrets by using an approved in-boundary vault provider, such as IBM Cloud® Secrets Manager, IBM® Key Protect, or [HashiCorp Vault](https://www.vaultproject.io) and then linking your toolchain secrets to those resources.

The secrets management capabilities that are provided in the toolchain setup and pipeline user interfaces enable selection of vaulted secrets by using secrets integrations for IBM Cloud® Secrets Manager, IBM® Key Protect, or HashiCorp Vault. By using the Secrets Picker dialog, a toolchain or pipeline editor can select named secrets from a bound secrets integration, that is either configured by CRN (Cloud Resource Name) or by name, that is then resolved by reference at runtime within the toolchain and pipeline. After a secret is chosen, a CRN or canonical secret reference is injected into the corresponding toolchain or pipeline secure property where the format is either crn:v1:...secret:<secret-guid> if it's a Secrets Manager integration configured by CRN, or alternatively {vault::integration-name.secret-name} if it's a vault integration using any of the supported providers and configured by name.

The canonical by name reference format, currently does not resolve a secret that includes the period character in the secret name because this character is used to delimit each section of the canonical path.

Regardless of which type of secret reference is used, either by CRN or by name, the front-end user interface components and Secrets Picker dialog only use a secret reference. The resolved value of a by CRN or by name secret reference is never exposed to the front-end and is always dynamically resolved at runtime within a toolchain and pipeline based on a permitted [authorization](https://cloud.ibm.com/iam/authorizations) being available (configured using IAM Authorizations and Access Policies).

Within IBM Cloud®, the dynamic process of resolving by CRN and by name secrets references in toolchains and pipelines is performed using internal virtual private endpoints (VPE) to all IBM Cloud® Secrets Manager and IBM® Key Protect provider instances in all regions.
Use [Secrets Manager](https://cloud.ibm.com/catalog/services/secrets-manager) to securely store and apply secrets like API keys, Image Signature, or Hashicorp Vault credentials that are part of your toolchain. You must create a Secrets Manager Service Instance before you proceed further. If you already created a Secrets Manager Service Instance as prerequisite, you can link the same in this step.

Zoom

![DevSecOps secrets manager](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-secrets-manager.png)

Figure 9. DevSecOps secrets manager



* Name: Name of Secrets Manager instance created by the toolchain. This Secrets Manager instance can be accessed by this name during various stages of the toolchain setup.
* Region: Region in which the Secrets Manager service is located.
* Resource Group: Resource Group that the Secrets Manager service belongs.
* Service name: Secrets Manager service name.







 HashiCorp Vault 

Use HashiCorp Vault to securely store secrets that are needed by your toolchain. Examples of secrets are API keys, passwords, or any other tokens that enable access to sensitive information. Your toolchain stores references to the HashiCorp Vault secrets, not the literal secret values, which enable advanced capabilities like secret rotation.

Zoom

![HashiCorp Vault](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops_hashicorp1_orig.png)

Figure 10. HashiCorp Vault



* Name: A name for this tool integration. This name is displayed in the toolchain.
* Server URL: The server URL for your HashiCorp Vault Instance.
-6405](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6405), [CVE-2020-9327](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9327), [CVE-2020-8177](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8177), [CVE-2019-13050](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13050), [CVE-2018-20843](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20843), [CVE-2019-15903](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15903), [CVE-2019-14889](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14889), [CVE-2020-1730](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1730), [CVE-2019-1551](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1551), [CVE-2020
The options for {secret_type} are: arbitrary, iam_credentials, imported_cert, kv, private_cert, public_cert, and username_password.

curl -X GET
--H "Authorization: Bearer {iam_token}" --H "Accept: application/json" "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets/{id}/versions"

A successful response returns metadata details about each secret version.

{
"versions": [
{
"created_at": "2022-06-27T11:58:15Z",
"created_by": "iam-ServiceId-e4a2f0a4-3c76-4bef-b1f2-fbeae11c0f21",
"expiration_date": "2023-10-05T11:49:42Z",
"id": "bc656587-8fda-4d05-9ad8-b1de1ec7e712",
"payload_available": true,
"secret_group_id": "67d025e1-0248-418f-83ba-deb0ebfb9b4a",
"secret_id": "67d025e1-0248-418f-83ba-deb0ebfb9b4a",
"secret_name": "example-imported-certificate",
"secret_type": "imported_cert",
"serial_number": "38:eb:01:a3:22:e9:de:55:24:56:9b:14:cb:e2:f3:e3:e2:fb:f5:18",
"validity": {
"not_after": "2023-10-05T11:49:42Z",
"not_before": "2022-06-27T11:58:15Z"
},
Security strategy: Start by reviewing all [security options](https://cloud.ibm.com/docs/openshift?topic=openshift-security) that are available for your cluster.
2. Network security:



* Classic clusters:



1. To isolate networking workloads, you can restrict network traffic to [edge worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-edge).
2. Set up a firewall by using a [gateway appliance](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallvyatta_firewall) or [Calico network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies).



* VPC clusters: Control traffic to and from your cluster with [VPC security groups](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-network-policy).



3. Workload security:



1. [Encrypt sensitive information](https://cloud.ibm.com/docs/openshift?topic=openshift-encryption) in the cluster, such as the master's local disk and secrets.
2. Set up a [private image registry](https://cloud.ibm.com/docs/openshift?topic=openshift-securityimages_registry) for your developers, such as the one provided by Container Registry, to control access to the registry and the image content that can be pushed.
3. [Set pod priority](https://cloud.ibm.com/docs/openshift?topic=openshift-pod_priority) to indicate the relative priority of the pods that make up your cluster's workload.
4. Authorize who can create and update pods by configuring [security context constraints (SCCs)](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_scc).
Select the Key Protect service instance that you created earlier.
6. Authorize dependent services by selecting Enable authorization to be delegated. Delegation allows the Key Protect instance to propagate its authorizations to this service.
7. Make sure that the Reader role is enabled. Reader permissions allow the Watson service to see the root keys in the Key Protect instance.
8. Click Authorize and confirm delegated authorization.







 Step 4. Encrypt the Watson service data 

After you grant the Watson service the authorization to use your keys, you create another instance on your Premium plan and supply the key name or CRN. The service uses your encryption key to encrypt your data.

You must have the administrator or editor role on the Watson service.



1. Go to the [AI / Machine Learning](https://cloud.ibm.com/catalog/?category=ai) category page.
2. Select the Watson service that you authorized in [Step 3. Grant service access](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-keyserviceserviceauth-key)
3. Select a region. Make sure to create the instance in the same location as the Key Protect service that you created in Step 1.
4. Select the Premium plan. This feature is supported on the Premium plan only.
5. Encrypt the service data with Key Protect:



1. Select Yes to "Encrypt service with Key Protect."
2. Select the Key Protect instance that you authorized earlier.
3. Select the root key that you authorized earlier.



If you see a drop-down menu flash and disappear, check that you have correctly followed sub-step 5 of [Step 3. Grant service access](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-keyserviceserviceauth-key)
6. Click Create.



The data that is associated with this Watson service instance is now encrypted.
Select the Key Protect service instance that you created earlier.
6. Authorize dependent services by selecting Enable authorization to be delegated. Delegation allows the Key Protect instance to propagate its authorizations to this service.
7. Make sure that the Reader role is enabled. Reader permissions allow the Watson service to see the root keys in the Key Protect instance.
8. Click Authorize and confirm delegated authorization.







 Step 4. Encrypt the Watson service data 

After you grant the Watson service the authorization to use your keys, you create another instance on your Premium plan and supply the key name or CRN. The service uses your encryption key to encrypt your data.

You must have the administrator or editor role on the Watson service.



1. Go to the [AI / Machine Learning](https://cloud.ibm.com/catalog/?category=ai) category page.
2. Select the Watson service that you authorized in [Step 3. Grant service access](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-keyserviceserviceauth-key)
3. Select a region. Make sure to create the instance in the same location as the Key Protect service that you created in Step 1.
4. Select the Premium plan. This feature is supported on the Premium plan only.
5. Encrypt the service data with Key Protect:



1. Select Yes to "Encrypt service with Key Protect."
2. Select the Key Protect instance that you authorized earlier.
3. Select the root key that you authorized earlier.



If you see a drop-down menu flash and disappear, check that you have correctly followed sub-step 5 of [Step 3. Grant service access](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-keyserviceserviceauth-key)
6. Click Create.



The data that is associated with this Watson service instance is now encrypted.
Select the Key Protect service instance that you created earlier.
6. Authorize dependent services by selecting Enable authorization to be delegated. Delegation allows the Key Protect instance to propagate its authorizations to this service.
7. Make sure that the Reader role is enabled. Reader permissions allow the Watson service to see the root keys in the Key Protect instance.
8. Click Authorize and confirm delegated authorization.







 Step 4. Encrypt the Watson service data 

After you grant the Watson service the authorization to use your keys, you create another instance on your Premium plan and supply the key name or CRN. The service uses your encryption key to encrypt your data.

You must have the administrator or editor role on the Watson service.



1. Go to the [AI / Machine Learning](https://cloud.ibm.com/catalog/?category=ai) category page.
2. Select the Watson service that you authorized in [Step 3. Grant service access](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-keyserviceserviceauth-key)
3. Select a region. Make sure to create the instance in the same location as the Key Protect service that you created in Step 1.
4. Select the Premium plan. This feature is supported on the Premium plan only.
5. Encrypt the service data with Key Protect:



1. Select Yes to "Encrypt service with Key Protect."
2. Select the Key Protect instance that you authorized earlier.
3. Select the root key that you authorized earlier.



If you see a drop-down menu flash and disappear, check that you have correctly followed sub-step 5 of [Step 3. Grant service access](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-keyserviceserviceauth-key)
6. Click Create.



The data that is associated with this Watson service instance is now encrypted.







 Working with customer-managed keys
Create an HSM master key to encrypt the content of key storage, including root keys. Only you have access to your keys and data. 



You might see Key Protect being described as BYOK, "bring your own key" and Hyper Protect Crypto Services as KYOK, or "keep your own key". Key Protect and Hyper Protect Crypto Services are similar services.





 Envelope encryption 

Root keys serve as key-wrapping keys and are an important part of envelope encryption. With envelope encryption, root keys encrypt LUKS passphrases (also called key encryption keys) which, in turn, secure data encryption keys (DEKs) that encrypt your data on the virtual disk. Figure 1 illustrates this process.

Zoom

![Figure showing envelope encryption.](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/envelope-encryption.png)

Figure 1. Contextual view of envelope encryption

Both Key Protect and Hyper Protect Crypto Services provide envelope encryption. Root keys in Hyper Protect Crypto Services service instances are also protected by a hardware security module (HSM) master key. The KMS stores your key and makes it available during volume and custom image encryption. You also manage your keys in the KMS.

Block storage volumes and file shares are assigned a unique master encryption key that is generated by the instance's host hypervisor. This key is encrypted by a passphrase and wrapped (encrypted) by the root key, creating a wrapped DEK or WDEK. The WDEK is stored as metadata with the volume or image, and is not available on VPC interfaces.

Custom images are encrypted by your own LUKS passphrase that you create by using QEMU. After the image is encrypted, you wrap the passphrase with your root key that is stored in the KMS.

For more information about envelope encryption, see the following documentation: