vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Specify one or more key-value pairs for this secret. For example, specify one key as secret1 with the value of mysecret1 and specify another key as secret2 with the value of target-secret. The name that you choose for your key does not need to be the same as the name of your environment variable. Notice that the value for the key is hidden, but it can be viewed if needed.



5. Click Create to create the secret.
6. Now that your secret is created from the console, go to the Secrets and configmaps page to view a listing of defined secrets and configmaps. For secrets, you can display a list of user-generated secrets or a list of all secrets, which includes secrets that are generated by Code Engine.







 Creating a TLS secret from the console 

Learn how to create a TLS secret from the console that can be consumed by apps when you work with custom domain mappings in Code Engine. A Transport Layer Security (TLS) secret contains a signed TLS certificate, including all its intermediate certificates, and its corresponding private key from a certificate authority (CA).

Before you begin, [create a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



1. After your project is in Active status, click the name of your project on the [Code Engine Projects page](https://cloud.ibm.com/codeengine/projects).
2. From the Components page, click Secrets and configmaps.
3. From the Secrets and configmaps page, click Create to create your secret.
4. From the Create config page, complete the following steps:



1. Select the TLS Secret option.
2. Provide a name; for example, myTLSsecret.
3. Add the certificate chain and its private key. Note that you can concatenate the certificates by starting each in a new line. You can provide this information in a file.



5. Click Create to create the TLS secret.
6.
To create or add secrets, you need the [Writer service role or higher](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam).

Before you import a certificate, be sure that you:



* Create an X.509 compliant certificate with a matching private key (optional).
* Convert your files into Privacy-enhanced electronic mail (PEM) format.
* Keep the private key unencrypted to ensure that it can be imported into Secrets Manager.







 Importing your existing certificates 

You can use Secrets Manager to store certificate files that are signed and issued by external certificate authorities. After you import your certificate files, you can deploy the certificate to your apps and services, download the certificate, or [rotate it manually](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manual-rotation) when it's time to renew.



 Importing certificates in the UI 

You can import an existing 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. From the list of secret types, click the Import certificate tile.
5. Click Next.
6. Add a name and description to easily identify your certificate.
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.
* [Prepare your instance to order certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificates).
* Review the certificate authority and DNS provider configurations that are available. To view the configurations that are defined for your instance, go to the Secrets engines > Public certificates page in the Secrets Manager UI.



To work with a DNS provider that is not currently integrated with the service, you do not need to add a configuration to order your public certificate.





 Ordering public certificates 

After you [configure the public certificates engine](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificates) for your instance, you can use Secrets Manager to request public SSL/TLS certificates from Let's Encrypt. Before a certificate can be issued to you, Secrets Manager uses domain validation to verify the ownership of your domains. When you order a certificate:



* Secrets Manager sends your request to the selected certificate authority. The status of the certificate changes to Pre-activation to indicate that your request is being processed.
* If the validation completes successfully, your certificate is issued and its status changes to Active.
* If the validation doesn't complete successfully, the status of your certificate changes to Deactivated. From your Secrets table, you can check the issuance details of your certificate by clicking the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/actions-icon-vertical.svg)> View details.
* If the validation doesn't complete successfully, the status of your certificate changes to Deactivated. From your Secrets table, you can check the issuance details of your certificate by clicking the Actions icon !
* UI
* CLI
* API
* Terraform







 Creating SSL/TLS private certificates 

You can use IBM Cloud® Secrets Manager to store, request, and generate private SSL/TLS certificates that you can use for your apps or services.

An SSL/TLS certificate is a type of digital certificate that is used to establish communication privacy between a server and a client. Certificates are issued by

certificate authorities (CA)and contain information that is used to create trusted and secure connections between endpoints. After you add a certificate to your Secrets Manager instance, you can use it to secure network communications for your cloud or on-premises deployments. Your certificate is stored securely in your dedicated Secrets Manager service instance, where you can centrally manage its lifecycle.

In Secrets Manager, certificates that you create by using a private certificate authority are private certificates (private_cert). Certificates that you import to the service are [imported certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificates) (imported_cert). Certificates that you order through Secrets Manager from a third-party certificate authority are [public certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-public-certificatesorder-public-certificates) (public_cert).



 Before you begin 

Before you get started, be sure that you have the required level of access. To create or add secrets, you need the [Writer service role or higher](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam).

Before you create a private certificate, be sure that you:



* [Prepare your instance to create certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-create-certificates).
* Review the intermediate certificate authorities that are available. To view the configurations that are defined for your instance, go to the Secrets engines > Private certificates page in the Secrets Manager UI.
To copy the secret with the ibmcloud oc ingress secret create command, you must have a default [Secrets Manager](https://cloud.ibm.com/docs/openshift?topic=openshift-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 oc 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/openshift?topic=openshift-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 oc ingress secret create command, you must have a default [Secrets Manager](https://cloud.ibm.com/docs/openshift?topic=openshift-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 oc commands.

ibmcloud oc ingress secret create --name <secret_name> --cluster <cluster_name_or_ID> --cert-crn <certificate_crn> --namespace <namespace>
2. Repeat the previous step for each namespace where your apps exist.









 Managing non-TLS secrets
The following table lists the required authorizations. An IAM administrator or a user with the required roles on those services can automatically grant authorizations by creating a project in your account, or they can [create the service to service authorizations manually](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-serviceauth&interface=ui). This authorization is only required once.



Table 2. Projects service to service authorizations

 Role Source Target Source account 

 Manager and Administrator IBM Cloud Projects service Schematics service This account 
 Viewer IBM Cloud Projects service Resource-controller service This account 
 Viewer IBM Cloud Projects service Catalog Management service This account 
 Viewer and SecretsReader IBM Cloud Projects service Secrets Manager service This account 



The resource-controller service can't be authorized manually by using the UI. A user with the required role on the resource-controller service can automatically grant this authorization by creating a project, or they can [create the authorization manually by using Terraform](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-serviceauth&interface=terraformauth-terra).

The following Terraform example creates the authorizations between the Projects service and the resource-controller, Schematics, Catalog Management, and Secrets Manager services:

resource "ibm_iam_authorization_policy" "rc" {
source_service_name = "project"
target_service_name = "resource-controller"
roles = ["Viewer"]
description = "created by terraform"
}
resource "ibm_iam_authorization_policy" "sc" {
source_service_name = "project"
target_service_name = "schematics"
roles = ["Manager", "Administrator"]
description = "created by terraform"
}
resource "ibm_iam_authorization_policy" "gc" {
source_service_name = "project"
target_service_name = "globalcatalog-collection"
roles = ["Viewer"]
description = "created by terraform"
}
resource "ibm_iam_authorization_policy" "sm" {
To create or add secrets, you need the [Writer service role or higher](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam).

Before you create a private certificate, be sure that you:



* [Prepare your instance to create certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-create-certificates).
* Review the intermediate certificate authorities that are available. To view the configurations that are defined for your instance, go to the Secrets engines > Private certificates page in the Secrets Manager UI.
* Review the [certificate templates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificate-templates) that are available for your selected intermediate CA.



A template selection is required when you create a private certificate. Depending on the template that you choose, some restrictions for your private certificate might apply. To view the templates that are defined for your intermediate CA, go to the Secrets engines > Private certificates page in the Secrets Manager UI. Expand the row of the intermediate CA that you want to use as the issuing authority for private certificate, and click Templates to review the templates that are available.





 Creating private certificates 

After you [configure the private certificates engine](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificates) for your instance, you can use Secrets Manager to generate private certificates by using an internal certificate authority that was previously configured for your Secrets Manager service 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 !
Projects directly support referencing API keys that are stored in Secrets Manager as an input to a deployable architecture.

Create a [Secrets Manager service instance](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-create-instance&interface=ui) in your primary project account that you can use for all projects within that account before you create your project.

There are a few different secret types that you can create. Use an arbitrary secret instance to store API Keys for your project. For more information, see [Creating arbitrary secrets in the UI](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-arbitrary-secrets&interface=uiarbitrary-ui).

Typically a single Secrets Manager instance is used for all projects in an account. Secrets in that instance can be organized into secrets groups that align with access restrictions. For example, you might want to use a secrets group per project or for a set of related projects.







 Organizing your configurations 

Consider organizing all of the related configurations into a single project. This way, you can manage the deployments from one location and help ensure they're secure and compliant. This might consist of one or more deployable architectures to create the necessary infrastructure, which then needs to be replicated to support multiple regions and environments such as development, test, and production.

Use a naming convention for your configurations so that users can understand the function of each configuration. For example, in a deployment that uses a VPC base deployable architecture and a Kubernetes Cluster deployable architecture that relies on the VPC base, you might name your configurations as follows:



Table 1. Configuration name examples

 Name Deployable architecture Notes 

 Dev-VPC-Global VPC Base Create the base VPC for the development environment 
 Dev-Kub-Dallas Kubernetes Cluster Create the cluster in Dallas for development 
 Dev-Kub-London Kubernetes Cluster Create the cluster in London for development 
 Prod-VPC-Global VPC Base Create the base VPC for the production environment 
 Prod-Kub-Dallas Kubernetes Cluster Create the cluster in Dallas for production
MA-3 - Maintenance Tools 



  Control requirements 

MA-3 - 0
:   The organization approves, controls, and monitors information system maintenance tools.





  NIST supplemental guidance 

This control addresses security-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into organizational information systems. Maintenance tools can include, for example, hardware/software diagnostic test equipment and hardware/software packet sniffers. This control does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing “ping,” “ls,” “ipconfig, or the hardware and software implementing the monitoring port of an Ethernet switch.
Single tenant, dedicated key management service. No Yes 
 Exclusive control of your master key. No Yes 
 Highest level security - FIPS 140-2 Level 4 HSM. No Yes 
 Managing your master key with smart cards. No Yes 
 Performing key ceremony. No Yes 







 What can I do with IBM Cloud Hyper Protect Crypto Services? 

IBM Cloud Hyper Protect Crypto Services can be used for key management service and cryptographic operations.

Hyper Protect Crypto Services can integrate with IBM Cloud data and storage services as well as VMware® vSphere® and VSAN, for providing data-at-rest encryption. The managed cloud HSM supports industry standards, such as Enterprise Public-Key Cryptography Standards (PKCS) #11. Your applications can integrate cryptographic operations such as digital signing and validation through Enterprise PKCS #11 (EP11 API). The EP11 library provides an interface similar to the industry-standard PKCS #11 application programming interface (API).

Hyper Protect Crypto Services leverages frameworks such as gRPC to enable remote application access. gRPC is a modern open source high-performance remote procedure call (RPC) framework that can connect services in and across data centers for load balancing, tracing, health checking, and authentication. Applications access Hyper Protect Crypto Services by calling EP11 API remotely over gRPC.

For more information, see [Hyper Protect Crypto Services use cases](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-use-cases).





 How do I know whether Hyper Protect Crypto Services is right for my company? 

If you are concerned on data security and compliance in the cloud, you are able to maintain complete control over data encryption and

signature keysin a cloud consumable HSM. The HSM is backed by industry-leading security for cloud data and digital assets. With the security and regulatory compliance support, your data is encrypted and privileged access is controlled. Even IBM Cloud administrators have no access to the keys.

With Hyper Protect Crypto Services, you can ensure regulatory compliance and strengthen data security.
Hyper Protect Crypto Services meets controls for global, industry, and regional compliance standards, such as GDPR, HIPAA, and ISO. As the HSM used by Hyper Protect Crypto Services, the IBM 4768 or IBM 4769 crypto card is also certified with Common Criteria EAL4 and FIPS 140-2 Level 4. For more information, see [Security and compliance](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-security-and-compliance).





 Can I monitor my service instance? 

Yes, you can monitor the status of your service instance through [IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-at-events).
Click the Overflow icon ![ellipsis icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/overflow-icon-2.svg) > Configure data set.
6. Click Add Quality Data Set.
7. Select Predefined Quality Data Sets.
8. Complete all required fields, and click Submit



The following are the seven pre-defined tags that are provided by DevOps Insights.



Table 1. Default DevOps Insights data sets

 Pre-defined Data Set Tag Display label Data Type Supported Data Formats 

 unittest Unit Tests Test Case JUnit (JSON), xUnit (xml), Mocha (JSON), KarmaMocha (JSON) 
 code Code Coverage Code Coverage Cobertura (xml), lcov (info), JaCoCo (xml) 
 fvt Functional Verification Tests Test Case JUnit (JSON), xUnit (xml), Mocha (JSON), KarmaMocha (JSON) 
 sonarqube SonarQube SonarQube SonarQube 
 dynamicsecurityscan Dynamic Security Scan Dynamic Security Scan IBM Cloud® Application Security (xml) 
 staticsecurityscan Static Security Scan Static Security Scan IBM Cloud® Application Security (xml) 
 vulnerabilityadvisor Vulnerability Advisor Vulnerability Advisor Vulnerability Advisor (JSON) 







 Adding custom data sets 

You can add your own custom data sets. Custom data sets support JUnit or XUnit, Mocha, Cobertura, lcov, and JaCoCo. To add custom data sets, use the following steps:



1. Click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg), and select DevOps.
2.
idra --publishtestresult --filelocation=./coverage/coverage-summary.json --type=code

The idra command supports the following type values:



Table 2. idra command types

 Type Description 

 unittest Unit test results 
 fvt Functional verification test results 
 code Code coverage results 
 sonarqube SonarQube scan results 
 staticsecurityscan Static security scan results from IBM Application Security on Cloud 
 dynamicsecurityscan Dynamic security scan results from IBM Application Security on Cloud 
 vulnerabilityadvisor Vulnerability Advisor results from IBM Vulnerability Advisor on Cloud 



To learn more about the idra command, see [the grunt-idra3 package's page on npm](https://www.npmjs.com/package/grunt-idra3).





 Viewing test results 

When your pipeline runs, it publishes the test result data to DevOps Insights. To view the test result data in DevOps Insights, go to the Quality Dashboard page. For more information, see [DevOps data aggregation](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-devops-data-aggregation).





 Next steps 

Learn how to [evaluate gates](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-evaluating-gates-idra) by using idra (deprecated).
Publishing test data to DevOps Insights 

Users can upload test results to IBM Cloud® DevOps Insights from any continuous integration and continuous delivery (CI/CD) tools and see all of those test results in the DevOps Insights Quality Dashboard page. A CI/CD tool refers to tools like Jenkins, Travis CI, and IBM® Continuous Delivery Pipeline for IBM Cloud® that are used to create builds, run tests, and perform deployments.

For more information about the Quality Dashboard page, see [DevOps data aggregation](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-devops-data-aggregation).



 Supported test data format in DevOps Insights 

The following table showed a list of supported tests and formats.



Table 1. Default DevOps Insights data sets

 Display Label Data Type Supported Data Formats and File Extension 

 Unit Tests Test Case JUnit (JSON), xUnit (xml), Mocha (JSON), KarmaMocha (JSON) 
 Code Coverage Code Coverage Cobertura (xml), lcov (info), JaCoCo (xml) 
 Functional Verification Tests Test Case JUnit (JSON), xUnit (xml), Mocha (JSON), KarmaMocha (JSON) 
 SonarQube SonarQube SonarQube 
 Dynamic Security Scan Dynamic Security Scan IBM Cloud® Application Security (xml) 
 Static Security Scan Static Security Scan IBM Cloud® Application Security (xml) 
 Vulnerability Advisor Vulnerability Advisor Vulnerability Advisor (JSON) 







 Uploading test case results 

To upload unit tests, functional verification tests or custom test data, use the following command:

ibmcloud doi testrecord-publish --logicalappname "$MY_APP_NAME" --buildnumber "$MY_BUILD_NUMBER" --filelocation "./test-sample-folder/unit_test_mocha.json" --type=unittest

For a sample test result files that you can upload to DevOps Insights, see [this GitHub repository with dummy data](https://github.com/devops-insights/example-upload-data-format).





 Uploading Code Coverage Results