vania-janet/multiturn-rag-retrieval-data huggingface dataset:
return The following certificate(s) expire on ${getDate(decodedNotification.secrets_expiration_date)}:
${decodedNotification.secrets.reduce((accumulator, currentValue) => {
return accumulator + 
> Domain(s): ${currentValue.domains}
Secret ID: ${currentValue.secret_id}
Secret name: ${currentValue.secret_name}
;
}, "")};
if (decodedNotification.event_type === "secret_expired")
return The following certificate(s) have expired:
${decodedNotification.secrets.reduce((accumulator, currentValue) => {
return accumulator + 
> Domain(s): ${currentValue.domains}
Secret ID: ${currentValue.secret_id}
Secret name: ${currentValue.secret_name}
;
}, "")};
}

async function main(params) {
try {
const publicKey = await getPublicKey();

// Verify the notification data using the retrieved public key
const decodedNotification = await jwtVerify(params.__ow_body, publicKey).data.data;
console.log(nReceived the following event notification from Secrets Manager:n${JSON.stringify(decodedNotification)});

const body = createIssueBody(decodedNotification);
if (!body) {
console.log(nNo action required for this notification. Event type: ${decodedNotification.event_type});
return;
}

// Create a GitHub issue with notification data
const options = {
method: 'POST',
url: 'https://api.github.com/repos/<org_name>/<repo_name>/issues',
headers: {
On 31 October 2023, support for the Secrets Manager API v1 will be removed.







 12 September 2022 

This release includes the following updates:



* Added the [Update the metadata of a secret version](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2update-secret-version-metadata) method that can be used to store version custom metadata that is relevant to the needs of your organization.
* Updated the [Create a secret](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2create-secret), [Invoke an action on a secret](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2update-secret), [Get secret metadata](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2get-secret-metadata), [Get secret version metadata](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2get-secret-version-metadata), and [Update secret metadata](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2update-secret-metadata) methods to include custom_metadata and version_custom_metadata fields.







 10 July 2022 

This release includes the following updates:



* Added the [Lock a secret](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2lock-secret) and [Lock a secret version](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2lock-secret-version) methods that can be used to create locks on a secret in your instance. For more information, see [Locking secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-locks).
With TLS secrets, you can specify one certificate CRN. With non-TLS secrets, you can specify multiple fields to pull non-certificate secrets. If you do not specify a secret type when you create a secret, TLS is applied by default. For more information on supported secrets, see [Working with secrets of different types](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-what-is-secretsecret-types).

Are secrets that are stored in a registered Secrets Manager instance automatically updated?
: Yes. If you have a Secrets Manager instance registered to your cluster, the secrets on the cluster are automatically updated with the values from Secrets Manager once a day. These updates are made using the value of the the secret from the corresponding CRN.

Are my secrets automatically updated if I do not create and register a Secrets Manager instance?
: If you do not have a Secrets Manager instance registered to your cluster, your default Ingress secrets continue to update automatically every 90 days and are applied to your cluster. However, any secrets you created that reference the default Ingress secret are not automatically updated.
: Example scenario: You have a default Ingress certificate in the default namespace. You run the ibmcloud oc ingress secret create command and reference the CRN of the default Ingress certificate to mirror the certificate in the istio-system namespace. Without a Secrets Manager instance, the default Ingress certificate in the default namespace automatically updates. However, you are responsible for regularly updating the certificate in the istio-system namespace with the kubectl commands or another rotation method.

I created secrets that reference the default Ingress certificate, but I have not created and registered a Secrets Manager instance. How do I manage my secrets?
: If you don't register a Secrets Manager instance, Red Hat OpenShift on IBM Cloud only automatically updates the default Ingress secret. You are responsible for managing any other secrets by using kubectl commands or another rotation method. If you have any secrets that reference the default Ingress certificate, you should remove them by using ibmcloud ks ingress secret rm.
* Option-2: An existing key can be copy and pasted (Not Recommended)
* Option-3: A new key can be created from here by clicking New +. Generate a new api-key if you don’t have one or copy an existing key to the field. The newly generated API key can be saved to an existing Key Protect instance.



The newly generated API key can be saved to an existing Key Protect instance.

Zoom

![DevSecOps API key](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-ci-api-key-full-access.png)

Figure 14. DevSecOps API key

Click the Key Icon to use an existing key from your Secret Provider.



* Provider: The Secret Provider that stores your API Key to access the cluster, as linked to your toolchain earlier. It can be a Key Protect Instance, Secret Manager Instance, or Hashicorp Vault Instance.
* Resource Group: Resource Group that the Secrets Manager Provider belongs.
* Secret name: Name or alias of the secret, such as the API Key.



Using the API key that is either created, retrieved from a vault, or manually entered the following fields load automatically if the API key has sufficient access. If the API key is valid, the Container registry region and namespace Cluster region, name, namespace, and Resource group is automatically populated. Change any of these fields to match your configuration if needed.

Zoom

![DevSecOps Deployment Target](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-ci-deployment-target.png)

Figure 15. DevSecOps Deployment Target





 Inventory target and source branches 



* Inventory Source Environment: The environment from where you want to promote the application Default: master
* secret_expired: Now available for arbitrary secrets, IAM credentials, and user credentials.



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).

CLI plug-in version 0.1.19
: Version 1.1.19 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).





 25 April 2022 

Create private SSL/TLS certificates for your applications
: You can now use Secrets Manager to set up a private certificate authority (CA) that you can use to issue SSL/TLS certificates to your internal applications. By configuring root and intermediate CAs for your instance, you can establish a valid chain of trust for your certificates. To find out more about this release, [check out the announcement blog](https://www.ibm.com/cloud/blog/announcements/create-private-tls-certificates-with-ibm-cloud-secrets-manager).



* [Preparing to create private certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-create-certificates)
* [Creating root certificate authorities](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-root-certificate-authorities)
* [Creating intermediate certificate authorities](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-intermediate-certificate-authorities)
* [Adding certificate templates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificate-templates)
* [Creating private certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificatescreate-certificates)



New Secrets Manager event notifications
CPU: 1
Memory: 4G

Runtime:
Array Indices: 0
Max Execution Time: 7200
Retry Limit: 3









 Removing fully referenced secrets or configmaps with the CLI 

You can remove a fully referenced secret or configmap from a job or app.

In this scenario, let's remove the fully referenced mydatabasesec secret from the demo job.



1. Update the demo job to remove the reference to the mydatabasesec secret.

ibmcloud ce job update -n demo --env-from-secret-rm mydatabasesec
2. View the details of the demo job. The output illustrates that the reference to the mydatabasesec secret is removed.

ibmcloud ce job get -n demo

Example output

Getting job 'demo'...
OK

Name: demo
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 19m
Created: 2021-02-12T07:05:23-06:00
[...]

Commands:
env
Image: busybox
Resource Allocation:
CPU: 1
Memory: 4G

Runtime:
Array Indices: 0
Max Execution Time: 7200
Retry Limit: 3







 Removing key references with the CLI 

You can remove a referenced key in a secret or configmap from a job or app.

In this scenario, let's remove the url key from the keyref job.

Even though the --env-from-configmap option was used on a job to reference the url key in the mydatabasecm configmap, you can use the --env-rm option to remove individual keys.
For more information, check out the [Secrets Manager CLI reference](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-cli).





 Secrets Manager API 

If you're trying out Secrets Manager for the first time, you might want to use the Secrets Manager API to evaluate the service and test out workflows for your applications. Start by copying the service endpoint URL from the Endpoints page in your Secrets Manager service dashboard. Then, generate an [IBM Cloud Identity and Access Management (IAM) token](https://cloud.ibm.com/docs/account?topic=account-iamtoken_from_apikey) to include in your request. For example, after you store secrets in your service instance, the following API request can be used to obtain your list of secrets:

curl -X GET -H "Authorization: Bearer {access_token}" -H "Accept: application/json"
"{base_url}/api/v2/secrets"

Replace {base_url} with your service endpoint URL, and {access_token} with your IAM token. To run the API request, you can paste it into your command line or preferred API testing tool.

For more information about using Secrets Manager APIs, check out the [Secrets Manager API reference](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2).





 Vault 

Already using HashiCorp Vault? You can interact with your Secrets Manager service instance by using the Vault HTTP API or CLI format.

Secrets Manager doesn't support all components that are available for Vault. Instead, the service builds on a custom version of open source Vault to support operations in Secrets Manager for various secret types.

For more information, check out the following resources:



* [Vault API reference](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-vault-api)
* [Vault CLI reference](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-vault-cli)
* Updated all secrets operations to return a locks_total field as part of the metadata of a secret.







 25 April 2022 

This release includes the following updates:



* Added the private_cert secret type that can be used to generate TLS certificates with the service. For more information, see [Creating private certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-private-certificatescreate-private-certificates).
* Added the [Invoke an action on a version of a secret](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2update-secret-version) method that can be used to revoke a version of a private certificate. Currently, this API supports private_cert secrets only.
* Updated the [Invoke an action on a secret](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2update-secret) method to include revoke as a supported action. Currently, the revoke action is supported for private_cert secrets only.
* Updated 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. This API now supports private_cert secrets in addition to imported_cert and public_cert.
* To specify the field name, use the named field option: --field name=<crn>. This option is available for arbitrary and IAM credential secret types.
* To use the IBM Cloud Secrets Manager secret as the prefix, use the prefixed field option: --field prefix=<crn>. This option is available for IAM credential, username and password, and key value secret types.



--namespace NAMESPACE
: Optional: Specify the project that your Ingress resource is deployed to. If your ALB runs the Kubernetes Ingress image, this value is required, because the ALB can identify secrets only in the same project as your Ingress resource. If your ALB runs the Red Hat OpenShift on IBM Cloud Ingress image, and you don't specify a project, the certificate secret is created in a project called ibm-cert-store. A reference to this secret is then created in the default project, which any Ingress resource in any project can access. While processing requests, the ALB follows the reference to pick up and use the certificate secret from the ibm-cert-store project.

--persist
: Optional: Persist the secret data in your cluster. If the secret is later deleted from the CLI or Red Hat OpenShift web console, the secret is automatically re-created in your cluster. To permanently delete the secret, you must use the [/ingress/v2/secret/deleteSecret API](https://containers.cloud.ibm.com/global/swagger-global-api//beta/DeleteIngressSecret).

--type
: Optional. The type of secret. Choose from tls for certificate CRNs or opaque for non-certificate CRNs. For tls, specify up to one CRN. Foropaque, you can specify multiple CRNs. If no secret type is specified, tls is applied by default.

-q
: Optional: Do not show the message of the day or update reminders.



 Example ingress secret create command
"anyKey" : "anyValue"
}
} ]





 SecretAction 

The following example shows the format of the SecretAction object.

{
"payload" : "exampleString",
"custom_metadata" : {
"anyKey" : "anyValue"
},
"version_custom_metadata" : {
"anyKey" : "anyValue"
}
}





 SecretGroupMetadataUpdatable[] 

The following example shows the format of the SecretGroupMetadataUpdatable[] object.

[ {
"name" : "updated-secret-group-name",
"description" : "Updated description for this group."
} ]





 SecretGroupResource[] 

The following example shows the format of the SecretGroupResource[] object.

[ {
"name" : "my-secret-group",
"description" : "Extended description for this group."
} ]





 SecretMetadata[] 

The following example shows the format of the SecretMetadata[] object.

[ {
"labels" : "dev", "us-south" ],
"name" : "updated-secret-name",
"description" : "Updated description for this secret.",
"custom_metadata" : {
"anyKey" : "anyValue"
},
"expiration_date" : "2030-04-01T09:30:00Z"
} ]





 SecretPolicyRotation[] 

The following example shows the format of the SecretPolicyRotation[] object.

[ {
"type" : "application/vnd.ibm.secrets-manager.secret.policy+json",
"rotation" : {
"interval" : 1,
"unit" : "day"
}
} ]





 SecretResource[] 

The following example shows the format of the SecretResource[] object.

[ {
"name" : "example-arbitrary-secret",
<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/openshift?topic=openshift-secretsnon-tls-field-view) added to a secret by running kubectl get secret and viewing the data block of the output.

ibmcloud oc 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

Example fields listed in the data block of the secret details.

data:
api_key: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk= Default field type using the default api_key field name
FAQs: Hyper Protect Crypto Services with Unified Key Orchestrator 

Read to get answers for questions about IBM Cloud® Hyper Protect Crypto Services with Unified Key Orchestrator.



 What is the difference between key management, key orchestration, and key governance? 

Key orchestration brings both key management and key governance capabilities into operations within an enterprise:



* Key management is the people, processes, and technology that define how encryption keys exist and operate within an enterprise, including key lifecycle stages, and roles and duties definitions.
* Key governance is the business control that is defined by the security and risk management practices of an enterprise. Key governance ensures encryption key risks are identified, assessed, and addressed by risk mitigation policies and controls, including applicable regulations and compliance requirements.
* Key orchestration is the activities and means that initiate and manage encryption keys through their lifecycle within an enterprise, including automation and integration into reporting and monitoring.



For more information about key management, see [NIST SP 800-57 Part 2 Rev 1 "Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf).





 Does Hyper Protect Crypto Services with Unified Key Orchestrator provide key management, governance, and orchestration at the same time? 

Yes. Unified Key Orchestrator provides a simplified means of key management, governance, and orchestration: one place to define, operate, and oversee encryption keys across hybrid multicloud environments.





 Is Unified Key Orchestrator a separate offering? 

No. From a technology point of view, Unified Key Orchestrator is a feature of Hyper Protect Crypto Services. You need to provision and deploy a Hyper Protect Crypto Services instance to implement and use Unified Key Orchestrator.





 How is Hyper Protect Crypto Services with Unified Key Orchestrator different from the Hyper Protect Crypto Services Standard Plan? 

Hyper Protect Crypto Services with Unified Key Orchestrator extends the Standard Plan. IBM Cloud is the only cloud service provider that offers native cloud encryption key orchestration and lifecycle management across hybrid multicloud environments, including IBM Cloud, IBM Satellite, other cloud service providers, and on-premises environments.
Hyper Protect Virtual Servers overview 

Hyper Protect Virtual Servers is an IBM Cloud® service that provides highly secure virtual servers that can run Linux applications and containerized workloads. It offers a flexible and scalable framework that you can use to quickly and easily provision and manage the created virtual servers.

For more information about how to get started, take a look at the [tutorial](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-getting-started).



  Why IBM Cloud Hyper Protect Virtual Servers? 

Hyper Protect Virtual Servers offers the following benefits:



*  Security -



Using Hyper Protect Virtual Servers, you can deploy a virtual server in a Secure Service Container, which ensures confidentiality of your data and code that you run within the virtual server. No external access to your data is allowed, including privileged users such as cloud administrators.



*  IBM Z capabilities on the cloud -



Hyper Protect Virtual Servers brings IBM Z capabilities into the cloud, from where you can use them to deploy workload into the most secure, highly performant Linux virtual server.



*  No IBM Z hardware and skills required -



By deploying Hyper Protect Virtual Servers, you can access IBM Z technology without having to purchase, install, and maintain the required hardware.



*  Easy to use, open, and flexible -



Embracing the openness and flexibility of a public cloud, Hyper Protect Virtual Servers offers user experience at parity with market leaders who apply IBM Z capabilities in an enterprise environment.





  Key features 

Hyper Protect Virtual Servers makes it possible to bring IBM Z into IBM’s global public cloud data centers. Through the IBM Cloud catalog, you can gain access to industry-leading security capabilities to modernize your applications in the IBM Cloud.



*  You can run both core and non-core workloads in a public cloud, observing all security and compliance policies of your enterprise.
*  You can protect the assets of business while you simultaneously maintain enhanced business service levels.
*  You can instantiate Linux virtual servers with your own public SSH key. Thus, only you can access your code and data. Not even an IBM Cloud administrator has access to your data.
*  You can deploy any supported workload into the most secure, highly performant Linux system, taking advantage of strengths of the LinuxONE system.