vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In the side panel, review the source details for the connection. Optionally, provide a description.
4. Select the resource group and Event Notifications service instance that you want to connect to.



If an IAM authorization between Secrets Manager and Event Notifications doesn't exist in your account, a dialog is displayed. Follow the prompts to grant access between the services:



1. To grant access, click Authorize.
2. In the side panel, select Event Notifications as the target service.
3. From the list of instances, select the service instance that you want to authorize.
4. Select the Event Source Manager role.
5. Click Review.
6. Click Assign.
7. To confirm the connection, click Connect.



A success message is displayed to indicate that Secrets Manager is now connected to Event Notifications.





 Step 4: Verify the Secrets Manager source in Event Notifications 



1. Click the menu icon > Resource list.
2. Open Services and software.
3. Open the Secrets Manager instance that you created. For more information, see [Sending email notifications to Event Notifications](https://cloud.ibm.com/docs/monitoring?topic=monitoring-tutorial-enen-create-instance).
4. Click Sources.



When you connect to Event Notifications in Secrets Manager, a source, with the same name as your Secrets Manager instance name, is automatically added to your Event Notifications list.





 Step 5: Create an Event Notifications destination 

This step ensures that an email destination exists where notifications are forwarded.



1. Click Destinations.
2. Notice in the Destinations list that, by default, an IBM Cloud email service is defined. You do not need to do anything else to configure an email destination.



If you want to add a webhook as a destination, click Add and enter the appropriate information in the Add a destination panel.





 Step 6: Create an Event Notifications topic 

Define a topic that receives an event from Secrets Manager.



1. Click Topics.
2. Click Create.
Why does the Ingress status show an ESSEC error? 

Virtual Private Cloud

Classic infrastructure

Satellite

  What’s happening 

When you check the status of your cluster's Ingress components by running the ibmcloud ks ingress status-report get command, you see an error similar to the following example.

The certificate for TLS secret expired or will expire soon (ESSEC).

  Why it’s happening 

You have secrets in your cluster that have either expired or are about to expire in the next 5 days.

  How to fix it 

Review and update your secrets and domains.



1.  Run the ibmcloud ks ingress secret ls command and review the output.

For secrets that are about to expire and are user managed
:   Ensure the value of the corresponding secret in IBM Cloud Secrets Manager has been updated and run the ibmcloud ks ingress secret update command for that secret.

For secrets that are managed by IBM
:   Ensure the corresponding domain is still active.

To determine whether a secret is IBM managed or user managed, run the ibmcloud ks ingress secret get command and look for the User Managed section.
2.  View the domains for your cluster.

ibmcloud ks nlb-dns ls

Example output

OK
Subdomain                                                                           Target(s)                              SSL Cert Status   SSL Cert Secret Name                            Secret Namespace    Status
example-124567891235678912345789asfghijk-0000.us-south.containers.appdomain.cloud   example0-us-south.lb.appdomain.cloud   created           example-124567891235678912345789asfghijk-0000   openshift-ingress   OK
3.  Inactive domains are any in the list that do not have an associated IP address or hostname. For those domains, remove the associated secrets from your cluster by running the following command.

ibmcloud ks nlb-dns secret rm
4.  If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.
Why does the Ingress status show an ESSEC error? 

Virtual Private Cloud

Classic infrastructure

Satellite

  What’s happening 

When you check the status of your cluster's Ingress components by running the ibmcloud oc ingress status-report get command, you see an error similar to the following example.

The certificate for TLS secret expired or will expire soon (ESSEC).

  Why it’s happening 

You have secrets in your cluster that have either expired or are about to expire in the next 5 days.

  How to fix it 

Review and update your secrets and domains.



1.  Run the ibmcloud oc ingress secret ls command and review the output.

For secrets that are about to expire and are user managed
:   Ensure the value of the corresponding secret in IBM Cloud Secrets Manager has been updated and run the ibmcloud oc ingress secret update command for that secret.

For secrets that are managed by IBM
:   Ensure the corresponding domain is still active.

To determine whether a secret is IBM managed or user managed, run the ibmcloud oc ingress secret get command and look for the User Managed section.
2.  View the domains for your cluster.

ibmcloud oc nlb-dns ls

Example output

OK
Subdomain                                                                           Target(s)                              SSL Cert Status   SSL Cert Secret Name                            Secret Namespace    Status
example-124567891235678912345789asfghijk-0000.us-south.containers.appdomain.cloud   example0-us-south.lb.appdomain.cloud   created           example-124567891235678912345789asfghijk-0000   openshift-ingress   OK
3.  Inactive domains are any in the list that do not have an associated IP address or hostname. For those domains, remove the associated secrets from your cluster by running the following command.

ibmcloud oc nlb-dns secret rm
4.  If the issue persists, contact support. Open a [support case](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the case details, be sure to include any relevant log files, error messages, or command outputs.
* Evidence: All raw compliance evidence that belongs to the application is collected here. For example, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-evidence.



The toolchain currently supports linking only to existing IBM-hosted Git Repos and Issue Tracking repositories.





 Inventory 

Repository URL: URL of the Inventory Repository configured in your CI Toolchain as captured in the previous step.





 Issues 

Repository URL: URL of the Issues Repository configured in your CI Toolchain as captured in the previous step.





 Pipeline Configuration 

The Pipeline configuration repository contains YAML files and scripts that are needed for deployment, testing, and other custom tasks.

If you do not have a configuration repository, enable the Advanced configuration toggle, and select the Clone repository type. The toolchain clones the [sample configuration](https://us-south.git.cloud.ibm.com/open-toolchain/hello-compliance-deployment) in your Git organization.

For more information about Git repos, see [Configuring your Git Repos and Issue Tracking](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-config-github). For more information about customizable scripts, see [Custom scripts](https://cloud.ibm.com/docs/devsecops?topic=devsecops-custom-scripts).





 Secrets 

Several tools in this toolchain, and possibly in your customizable scripts, require secrets to access privileged resources. An IBM Cloud API key is an example of such a secret. These secrets must be securely stored within an IBM-recommended secrets management tool, such as [IBM Key Protect for IBM Cloud](https://www.ibm.com/cloud/key-protect), [IBM Cloud® Secrets Manager](https://www.ibm.com/cloud/secrets-manager), or [Hashicorp Vault](https://www.vaultproject.io/).
dynamic-scan runs after deploy, but before the acceptance test run
dynamic-scan:
image: ibmcom/pipeline-base-image:2.12
script: 
!/bin/sh
...

 acceptance-test runs after deploy
acceptance-test:
image: ibmcom/pipeline-base-image:2.7
script: 
!/bin/sh
...
Show more

To view the .pipeline-config.yaml configuration file that is used by default for the example app in the reference pipeline template, see [configuration for pull requests and continuous integration](https://us-south.git.cloud.ibm.com/open-toolchain/hello-compliance-app/-/blob/master/.pipeline-config.yaml) and [configuration for continuous deployment](https://us-south.git.cloud.ibm.com/open-toolchain/hello-compliance-deployment/-/blob/master/.pipeline-config.yaml).









 Secrets, parameters, and properties 

Use [pipelinectl commands](https://cloud.ibm.com/docs/devsecops?topic=devsecops-pipelinectl) to read or write data from the pipeline at run time. You can read and write secrets, variables, repo data, artifact data, and evidence result artifacts (such as test result files) by way of the pipelinectl interface.

You do not need to install the pipelinectl tool for your scripts or base images, the reference pipeline provides the binary files for the context of your script.



 Accessing pipeline environment secrets and properties 

Environment properties and secrets (defined on the pipeline UI) are accessible through pipelinectl:

 if you set my_config_value on the UI, it's accessible via get_env
my_config_value=$(get_env my_config_value)

You can set other variables by using set_env:

set_env my_config_value "some value"

 later on, even in another stage
For example, if you click New to mint a new API key, you can select the Save this key in a secrets store for reuse checkbox to save the API key in a Key Protect instance to use it again later. If you do not already have a Key Protect instance, a new instance is created for you.





 Authorizing your toolchain to access secrets 

References to secrets that are stored in Key Protect are dynamically resolved when the toolchain runs. To access the required secrets, you must authorize your toolchain to access the Key Protect instance. If you create a toolchain that has a valid Key Protect tool integration, or add this tool integration to an existing toolchain, a request is automatically made to create the necessary authorization.

To view your authorizations in IBM Cloud, complete the following steps:



1. From the IBM Cloud console, click Manage > Access (IAM).
2. Click Authorizations.



You can also access your authorizations on the [Manage authorizations](https://cloud.ibm.com/iam/authorizations) page.

Zoom

![Toolchain Authorizations for Key Protect](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/s2s-auths.png)

Figure 3. Toolchain authorizations for Key Protect

You can create the authorization manually, if required. To successfully resolve the secret references, your toolchain instance must have both Viewer and ReaderPlus access to the correct Key Protect service instance.





 Configuring Key Protect by using the API
Usage: If you have 20 secrets in your instance, and you want to retrieve only the first 5 secrets, use ../secrets/{secret_type}?limit=5.

The maximum value is 5000. The minimum value is 1.

--offset (int64)
: The number of secrets to skip. By specifying offset, you retrieve a subset of items that starts with the offset value. Use offset with limit to page through your available resources.

Usage: If you have 100 secrets in your instance, and you want to retrieve secrets 26 through 50, use ..?offset=25&limit=25.

The minimum value is 0.





 Examples 

ibmcloud secrets-manager secrets --secret-type=arbitrary --limit=1 --offset=0







 ibmcloud secrets-manager all-secrets 

List all of the secrets in your Secrets Manager instance.

ibmcloud secrets-manager all-secrets [--limit LIMIT] [--offset OFFSET] [--search SEARCH] [--sort-by SORT-BY] [--groups GROUPS]



 Command options 

--limit (int64)
: The number of secrets to retrieve. By default, list operations return the first 200 items. To retrieve a different set of items, use limit with offset to page through your available resources.

Usage: If you have 20 secrets in your instance, and you want to retrieve only the first 5 secrets, use ../secrets/{secret_type}?limit=5.

The maximum value is 5000. The minimum value is 1.

--offset (int64)
: The number of secrets to skip. By specifying offset, you retrieve a subset of items that starts with the offset value. Use offset with limit to page through your available resources.

Usage: If you have 100 secrets in your instance, and you want to retrieve secrets 26 through 50, use ..?offset=25&limit=25.

The minimum value is 0.

--search (string)
: Filter secrets that contain the specified string. The fields that are searched include: id, name, description, labels, secret_type.
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, click the Other secret type 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. Select a file or enter the secret value that you want to associate with the secret.

Secrets Manager supports text-based payloads only for arbitrary secrets. If you select a file to assign to an arbitrary secret, the service uses base64 encoding to store the data in your instance. To access this secret later, 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.
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
The Wildcard certificate is the simplest way to deliver web content to your users securely. The Custom CNAME is added to the wildcard certificate maintained on the CDN Edge server and becomes the only way for users to use HTTPS for your CDN (for example, https://cdnakaivlnqidbg4.cdn.appdomain.cloud){: external}.



2. Accept the Master Service Agreement and click Create.



After you have successfully created the CDN mapping:



* CNAME configuration required may display in the Status column, you can ignore it and check the status again by selecting Get status from the overflow menu. It should change to Running after a few minutes.
* To view your CDN instance, select the CDN instance [in the list](https://cloud.ibm.com/cdn). The Details panel shows both the Hostname and the CNAME for your CDN.
* You application is now accessible through the CNAME only: https://<CNAME>. You may need to wait a few minutes for all configuration to complete and for the CNAME to work.







 Step 3: Enable Dynamic Content Acceleration (DCA) 

At that stage, the static content of the application is cached by the CDN but not the dynamic content.

The Dynamic Content Acceleration (DCA) feature will query a test object in about 10KB size on your origin server to determine the optimal routes for real requests. For this purpose, the application has been customized to include [a test object](https://github.com/IBM-Cloud/cdn-with-cda-todolist/blob/master/views/detection-test-object.html) made available at [/test-dca](https://github.com/IBM-Cloud/cdn-with-cda-todolist/blob/master/main.goL11).

To activate DCA:



1. Select the Settings tab in the CDN configuration.
2. Under the Optimization settings section, click Edit and select Dynamic Content Acceleration from the Optimized for drop-down list.
3.
* [Regenerating the certificate for an Ingress domain](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-domainsingress-domain-manage-secrets-regen)
* [Delete an Ingress domain secret](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-domainsingress-domain-manage-secrets-rm)





[Managing TLS and non-TLS certificates and secrets](https://cloud.ibm.com/docs/openshift?topic=openshift-secretssecrets)



* [Managing TLS certificates and secrets with Ingress](https://cloud.ibm.com/docs/openshift?topic=openshift-secretstls)



* [Setting up TLS secrets for the IBM-provided Ingress subdomain](https://cloud.ibm.com/docs/openshift?topic=openshift-secretstls-default)
* [Setting up TLS secrets for custom subdomains](https://cloud.ibm.com/docs/openshift?topic=openshift-secretstls-custom)



* [Managing non-TLS secrets](https://cloud.ibm.com/docs/openshift?topic=openshift-secretsnon-tls)



* [Creating a non-TLS secret in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-secretsnon-tls-create)
* [Managing non-TLS secret fields](https://cloud.ibm.com/docs/openshift?topic=openshift-secretsnon-tls-field)



* [Secrets FAQ](https://cloud.ibm.com/docs/openshift?topic=openshift-secretssecrets-faq)



[Setting up Secrets Manager in your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-secrets-mgrsecrets-mgr)
If you want to link an existing Application repo for the toolchain, select Bring your own app and specify the URL for the repo. The toolchain supports linking only to existing Git Repos and Issue Tracking repos.

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





 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/sat_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).
Content Delivery Network docs 

IBM Content Delivery Network (CDN) provides content caching on the Akamai network, so content is delivered at record speed. Leverage the docs and API reference to plan for and manage your content delivery network.

 Developer tools 

[API & SDK reference](https://cloud.ibm.com/docs/CDN?topic=CDN-cdn-api-reference)

 Recommended content 

[About Content Delivery Networks How does a CDN work? View the three-tier architecture of IBM Cloud CDN and read all about its key features.](https://cloud.ibm.com/docs/CDN?topic=CDN-about-content-delivery-networks-cdn-)[CDN Support Center Need assistance? Go here for common tasks, troubleshooting tips, FAQs, and more.](https://cloud.ibm.com/unifiedsupport/supportcenter/b6c4a555-5ff6-4e1d-9ce7-0a9976629eab)[Ordering a CDN You'll first need an IBMid. You can then order your CDN service through the IBM Cloud console.](https://cloud.ibm.com/docs/CDN?topic=CDN-order-a-cdn)[Accelerate delivery of static files Step through this tutorial to learn how to use a CDN and host website assets and user-generated content in IBM Cloud Object Storage.](https://cloud.ibm.com/docs/CDN?topic=solution-tutorials-static-files-cdn)[Accelerate a dynamic website Learn how to use Dynamic Content Acceleration (DCA) to optimize the performance of non-static content.](https://cloud.ibm.com/docs/CDN?topic=solution-tutorials-dynamic-content-cdn)

 Video library 

[![carousel thumbnail](https://cloud.ibm.com/docs-content/v1/content/CDN//images/thumbnail1.png)<br><br>What is a Content Delivery Network?]
vault write [-format=FORMAT] ibmcloud/SECRET_TYPE/roles/groups/SECRET_GROUP_ID/ROLE_NAME access_groups=ACCESS_GROUP_ID,ACCESS_GROUP_ID ttl=LEASE_DURATION [description="DESCRIPTION"] [labels=LABEL,LABEL]



 Prerequisites 

You need the [Writer service role](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam) to create secrets.





 Command options 

SECRET_TYPE
: The type of secret that you want to create. Currently, iam_credentials is supported.

SECRET_GROUP_ID
: The ID of the secret group that you want to assign to the role and its credentials.

ROLE_NAME
: The human-readable alias that you want to assign to the role and its credentials.

access_groups
: The ID of the access group that determines the scope of access to assign to the role and its credentials.

ttl
: The time-to-live (TTL) that determines how long a role's generated-credentials can exist. Use a duration string such as 300s or 1h30m. Valid time units are s, m, and h.

description
: An extended description to assign to the role and its credentials.

labels
: Labels that you can use to group and search for similar secrets in your instance.

-format
: Prints the output in the format that you specify. Valid formats are table, json, and yaml. The default is table. You can also set the output format by using the VAULT_FORMAT environment variable.





 Examples 

Configure an IAM credential with a lease duration of 1 hour and assign it to the default secret group.

vault write -format=json ibmcloud/iam_credentials/roles/test-iam-credentials access_groups=AccessGroupId-985dc0a3-857b-48bd-b6d6-33819da7ba42 ttl=1h description="My test IAM credential." labels=test,us-south