vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You need the [Writer service role](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam) to create secrets.





 Command options 

name
: The human-readable alias that you want to assign to the secret. Required.

description
: An extended description to assign to the secret.

expiration_date
: The expiration date that you want to assign to the secret. Supported for the arbitrary and username_password secret types. The date format follows [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339).

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

payload
: The data that you want to store for arbitrary or kv secrets. Only text-based payloads are supported for arbitrary secrets. The key-value secrets engine can store secrets in complex JSON format. With your key-value secret, you can integrate with tools that are compatible with the HashiCorp Vault KV (Version 2) CLI commands. Learn more about [managing key-value secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-vault-manage-kv-cli) with the Vault CLI.

username
: The username that you want to assign to a username_password secret.

password
: The password that you want assign to a username_password secret.

certificate
: The certificate data that you want to store for an imported_cert secret. Supported file type is .pem.

private_key
: The private key data to store for an imported_cert secret. Supported file type is .pem.

intermediate
: Intermediate certificate data to store for an imported_cert secret. Supported file type is .pem.

ca
: The [certificate authority configuration](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-certificate-authority) to be used for ordering a public_cert secret.

dns
Your apps or jobs can consume and use the information that is stored in a secret by using environment variables.



 Referencing secrets from the console 

You can use the console to create environment variables for your apps and jobs that fully reference a secret or reference individual keys in a secret.

Before you can reference a secret, it must exist. See [create a secret](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret-create-ui). For this example, create a secret that is named target-secret with the key-value pair of TARGET=Sunshine.



1. To reference a defined secret from your app or job, [create an environment variable](https://cloud.ibm.com/docs/codeengine?topic=codeengine-envvarenvvar-create-ui). The environment variable can fully reference an existing secret or reference an individual key in an existing secret. When you fully reference a secret (or configmap), you can optionally specify a prefix. For example, if you fully reference the mysecret secret from the myapp application and use the mysecret_ prefix, each key in the secret is prefixed with mysecret_.
2. After you create environment variables, you must restart your app or job for the changes to take effect. For apps, save and deploy your app to update the app with the environment variables that you defined. For jobs, submit your job to update the job with the environment variables that you defined.
3. After the app or job status changes to Ready, you can test the application or run the job. For an app, click Test application and then click Send request in the Test application pane. To open the application in a web page, click Application URL. In the myapp example, because a prefix was specified for the fully referenced mysecret secret, all the keys of this secret are referenced as environment variables and are prefixed with mysecret_. For example, these environment variables display as mysecret_secret1=mysecret1 and mysecret_secret2=mysecret2.
Command options 

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





 Example 

Create or update the payload of a key-value secret.

vault kv put ibmcloud/kv/example-kv-secret key1=value1 key2=value2

Create or update the payload of a key-value secret in a custom group.

vault kv put ibmcloud/kv/9426e546-83de-4da5-9631-d70c993186c8/example-kv-secret key1=value1 key2=value2





 Output 

The command to create a new version of a kv secret returns the following output:

Key Value
--- -----
created_time 2022-03-08T18:32:43.610242127Z
deletion_time n/a
destroyed false
version 2







 Read a version of a key-value secret 

Get a version of a key-value secret. A successful request returns the secret data that is associated with the specified version of your secret, along with other metadata.

vault kv get [-version=VERSION] [-format=FORMAT] ibmcloud/kv/SECRET_NAME

Get a version of a key-value secret in a custom group.

vault kv get [-version=VERSION] [-format=FORMAT] ibmcloud/kv/GROUP_ID/SECRET_NAME



 Prerequisites 

You need the [Reader or Writer service role](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam) to read versions of key-value secrets.





 Command options 

-version
: The version that you want to read. If omitted, the latest version is returned.

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





 Example
IP aliasing is a commonly used technique, though it is recommended to review server and application configurations to determine if they work well under multi-home and IP alias configurations.

Additional routing configuration on the VRA will be required to create dynamic routes (for example BGP) or static routes for the BYOIP subnets.







 Related content 



* [IBM Cloud® Direct Link](https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-linkconfigure-ibm-cloud-direct-link)
* [Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started)
To see a list of fields, run [ibmcloud oc ingress secret field ls](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_ingress_secret_field_ls).



 Example ingress secret field rm command 

ibmcloud oc ingress secret field rm --cluster a11a11a11a111a1a111a --name my-secret --namespace default --field-name test-field-name







 ibmcloud oc ingress secret get 

Virtual Private Cloud

Classic infrastructure

View information about Ingress secrets in your cluster, including secrets stored in IBM Cloud® Secrets Manager.

The previous alias for this command, ibmcloud oc ingress alb cert get, is deprecated. In CLI version 1.0.157 and later, the ibmcloud oc ingress alb cert category is deprecated, and these commands are now listed in the ibmcloud oc ingress secret subcategory. For more information, see the [CLI change log](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_cli_changelog10).

ibmcloud oc ingress secret get --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [--output json] [-q]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--name SECRET_NAME
: Required: The name of the secret.

--namespace NAMESPACE
: Required: The project that the secret is deployed to.

--output json
: Optional: Prints the command output in JSON format.

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



 Example ingress secret get command 

ibmcloud oc ingress secret get --cluster my_cluster --name my_alb_secret --namespace demo_ns
See [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



For simplicity in this scenario, create one secret, kafka-subscription-secret, to contain the credentials that are required for both the Kafka sender sample app and the Kafka event subscription, which uses the Kafka receiver sample. These credentials are required for the sample Kafka sender app and the Code Engine Kafka event subscription to communicate with the service instance for Event Streams. While it not required that you create this secret before you create the Kafka sender app and the event subscription, this action simplifies the required steps.



 Creating a secret with credentials required by the Kafka samples from the console 

To create the kafka-subscription-secret secret from the console, go to Secrets and configmaps and click Create and select secret as your option. For more information, see [create a secret from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secretsecret-create-ui).



* Specify the username key with the value of user that is listed in the details of the service credentials in the Event Streams service instance. For the Event Streams service instance, this value is token. This key is required for authentication between the Code Engine Kafka event subscription and the Kafka message broker.
* Specify the password key with the value of apikey that is listed in the details of the service credentials in the Event Streams service instance. This key is required for the sender sample, and to enable communications between the Code Engine Kafka event subscription and the Kafka message broker.







 Creating a secret with credentials required by the Kafka samples with the CLI 

To create the kafka-subscription-secret secret with the CLI, add a literal environment variable for password, and username. For more information, see [create a secret with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secretsecret-create-cli).
The API key must be stored with an ibmcloud-api-key entry and the signing key that is stored under signing_key.

To create an API key for the DevSecOps toolchains, see [IBM Cloud® API key](https://cloud.ibm.com/iam/apikeys) and review the [IAM Access permissions](https://cloud.ibm.com/docs/devsecops?topic=devsecops-iam-permissions). The IAM access permissions are relevant only if you are running toolchains in some one else's account. Do not confuse the API key for running the toolchains with the API key called ibmcloud_api_key, which is one of the required inputs for setting up the toolchains.

ibmcloud-api-key and signing_key are the default names of the expected secrets in the secrets vault. These default names can be changed. See the following table for more details:



Table 7. Secret names

 Name Description Value 

 ci_ibmcloud_api_key_secret_name Name of the IBM Cloud® API key secret in the secret provider. "ibmcloud-api-key" 
 cd_ibmcloud_api_key_secret_name Name of the IBM Cloud® API key secret in the secret provider. "ibmcloud-api-key" 
 cc_ibmcloud_api_key_secret_name Name of the IBM Cloud® API key secret in the secret provider. "ibmcloud-api-key" 
 ci_signing_key_secret_name Name of the signing key secret in the secret provider. "signing_key" 



For more secret names, search for "secret_name" in the variable list.





 IBM® Key Protect 

Secrets Manager is the default secrets provider for the DevSecOps toolchains. However, you can use Key Protect instead. Set the following variables for Key Protect. These variables apply to the Key Protect integration in all the DevSecOps toolchains that are created.



Table 8. Key Protect

 Name Description Type Default
When you mount the secret as a volume to your pod, a file that is named binding is stored in the volume mount directory. The binding file in JSON format includes all the information and credentials that you need to access the IBM Cloud service.



1. List available secrets in your cluster and note the name of your secret. Look for a secret of type Opaque. If multiple secrets exist, contact your cluster administrator to identify the correct service secret.

oc get secrets

Example output

NAME TYPE DATA AGE
binding-<service_instance_name> Opaque 1 3m
2. Create a YAML file for your Kubernetes deployment and mount the secret as a volume to your pod.

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: secret-test
name: secret-test
namespace: <my_project>
spec:
selector:
matchLabels:
app: secret-test
replicas: 1
template:
metadata:
labels:
app: secret-test
spec:
containers:
- image: icr.io/ibm/liberty:latest
name: secret-test
volumeMounts:
- mountPath: <mount_path>
name: <volume_name>
volumes:
- name: <volume_name>
secret:
defaultMode: 420
secretName: binding-<service_instance_name>
Show more

volumeMounts.mountPath
: The absolute path of the directory to where the volume is mounted inside the container.

volumeMounts.name and volumes.name
: The name of the volume to mount to your pod.

secret.defaultMode
: The read and write permissions on the secret. Use 420 to set read-only permissions.

secret.secretName
: The name of the secret that you noted in the previous step.
3. Create the pod and mount the secret as a volume.

oc apply -f secret-test.yaml
4. Verify that the pod is created.

oc get pods
This value is optional. The default value is false.

--sort-by, -s
: Specifies the column by which to sort the list. Valid values are name and age. This value is optional. The default value is name.





 Example 

This command lists all secrets in a project.

ibmcloud ce secret list





 Example output 

Listing secrets...
OK

Name Format Data Age
ce-auto-icr-private-us-south registry 4 333d
ce-auto-private-icr-us-south registry 4 335d
myregistry-seccmd registry 4 3h31m
mysecret-basicauth basic_auth 2 7m37s
mysecret-generic generic 1 7m7s
mysecret-genericfromfile generic 2 2m29s
mysecret-registry registry 4 111s
mysecret-ssh ssh_auth 2 42m
mysecret-tls tls 2 3h47m







 ibmcloud ce secret update 

Update a secret.

ibmcloud ce secret update --name SECRET_NAME (--from-env-file FILE | --from-file FILE | --from-file KEY=FILE | --from-literal KEY=VALUE | --rm KEY) [--cert-chain-file CERT_CHAIN_FILE] [--email EMAIL] [--key-path KEY_PATH] [--known-hosts-path KNOWN_HOSTS_PATH] [--output OUTPUT] [--password PASSWORD] [--password-from-file PASSWORD_FROM_FILE] [--password-from-json-file PASSWORD_FROM_JSON_FILE] [--private-key-file PRIVATE_KEY_FILE] [--quiet] [--server SERVER] [--username USERNAME]



 Command Options 

--name, -n
: The name of the secret. This value is required.

--cert-chain-file, --ccf
: Specify a file containing the certificate chain provided by your certificate authority for a TLS secret.
: The ID of the secret. Required.

The maximum length is 36 characters. The minimum length is 36 characters. 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}/.





 Example 

ibmcloud secrets-manager secret-delete --id=0b5571f7-21e6-42b7-91c5-3f5ac9793a46







 ibmcloud secrets-manager secret-metadata 

Get the metadata of a secret by specifying the ID of the secret.

ibmcloud secrets-manager secret-metadata --id ID



 Command options 

--id (string)
: The ID of the secret. Required.

The maximum length is 36 characters. The minimum length is 36 characters. 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}/.





 Example 

ibmcloud secrets-manager secret-metadata --id=0b5571f7-21e6-42b7-91c5-3f5ac9793a46







 ibmcloud secrets-manager secret-metadata-update 

Update the metadata of a secret, such as its name or description.

ibmcloud secrets-manager secret-metadata-update --id ID [--name NAME] [--description DESCRIPTION] [--labels LABELS] [--custom-metadata CUSTOM-METADATA] [--expiration-date EXPIRATION-DATE] [--ttl TTL] [--rotation ROTATION]



 Command options 

--id (string)
: The ID of the secret. Required.

The maximum length is 36 characters. The minimum length is 36 characters.
Preparing and Installing SAP Data Hub 



 Deploying Red Hat's SAP Data Hub (SDH) Observer 

Deploying the SAP Data Hub (SDH) Observer lets the SAP Data Hub installer and runtime components access images in the IBM Cloud® Container Registry to provide the image pull secret for the project. In the Red Hat article, the project name is 'sdh'.

The project's namespace and Container Registry names used in the following steps are the same as those used in previous steps.



1. Copy the local pull image secret from the default area to the sdh project. For more information, see [Copying an existing image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registrycopy_imagePullSecret).

The source secret should match your region, for example, 'de' for Central Europe. In this example, the source secret default-de-icr-io is copied to sdh-de-icr-io.

Find your region.

ibmcloud cr api
 The region code precedes the domain - in this example the domain is icr.io and the region code is de.
 {: screen}
Registry API endpoint https://de.icr.io/api

The command line is: oc patch secret --dry-run -o yaml -n default <local_secret> -p '{"metadata":{"namespace": "<project_name>"}}' | oc -n sdh create -f -

oc patch secret --dry-run -o yaml -n default default-de-icr-io -p '{"metadata": {"namespace": "sdh", "name": "sdh-de-icr-io"}}' | oc -n sdh create -f -
2. Link the secret sdh-de-icr-io to the default service account’s pods.

oc secrets link -n sdh --for=pull default sdh-de-icr-io
3. Deploy the SAP Data Hub Observer in the sdh namespace.
Vault-Token The authentication token that is retrieved from Vault. 
 versions The versions of the key-value secret you want to permanently destroy. 







 Example response 

A request to permanently destroy versions of a key-value secret in the default secret group returns a blank response with a 204 status code to confirm that the secret's versions were destroyed.







 Create or update key-value secret metadata 

Create or update the metadata of a key-value secret, such as the maximum number of versions or other custom values. To update the actual contents of the secret, use the [Create or update a secret](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-vault-manage-kv&interface=apiupdate-kv-secret) method.



 Example request 

curl -X POST 'https://{instance_id}.{region}.secrets-manager.appdomain.cloud/v1/ibmcloud/kv/metadata/{secret_name}' -H 'Accept: application/json'  -H 'X-Vault-Token: {Vault-Token}' -H 'Content-Type: application/json' -d '{
"custom_metadata": {
"meta1": "data1",
"meta2": "data2"
}
}'



Table 7. Update the metadata of a key-value secret request parameters

 Request parameter Description 

 instance_id The ID of the Secrets Manager instance. 
 region The region in which the Secrets Manager instance was created. 
 secret_name The name of the key-value secret. 
 Vault-Token The authentication token that is retrieved from Vault. 







 Example response 

A request to update the metadata of a key-value secret in the default secret group returns a blank response with a 204 status code to confirm that the secret's metadata was updated.







 Read metadata of key-value secret 

Get a key-value secret's metadata by specifying the ID of the version.



 Example request 

curl -X GET 'https://{instance_id}.
<alb2-id>: '{"deepInspect":"<true|false>", "defaultBackendService":"<service_name>", "defaultCertificate":"<namespace>/<secret_name>", "enableSslPassthrough":"<true|false>", "httpPort":"<port>", "httpsPort":"<port>", "ingressClass":"<class>","logLevel":<log_level>, "replicas":<number_of_replicas>, "tcpServicesConfig":"<kube-system/tcp-services>"}'

deepInspect
: Enable or disable Ingress object security deep inspector. When enabled, ALBs inspect configuration values in Ingress resources before processing. For more information, see [the ingress-nginx source code](https://github.com/kubernetes/ingress-nginx/tree/main/internal/ingress/inspector).
: This feature is available for ALB versions 1.2.0 and later and enabled by default.

defaultBackendService
: Specify the name of an optional default service to receive requests when no host is configured or no matching host is found. This service replaces the IBM-provided default service that generates a 404 message. You might use this service to configure custom error pages or for testing connections.

defaultCertificate
: A secret for a default TLS certificate to apply to any subdomain that is configured with Ingress ALBs in the format secret_namespace/secret_name. To create a secret, you can run the [ibmcloud ks ingress secret create](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_ingress_secret_create) command. If a secret for a different TLS certificate is specified in the spec.tls section of an Ingress resource, and that secret exists in the same namespace as the Ingress resource, then that secret is applied instead of this default secret.
kubectl create secret docker-registry hsm-docker-secret --docker-server=<DOCKER_REGISTRY_SERVER> --docker-username=<DOCKER_USER> --docker-password=<DOCKER_PASSWORD> --docker-email=<DOCKER_EMAIL> -n <NAMESPACE>

Replace:



* DOCKER_REGISTRY_SERVER - Registry server url where the HSM client image is hosted.
* DOCKER_USER - Valid username with access to HSM client image in the container registry.
* DOCKER_PASSWORD - Valid password or access token for the HSM client image in the container registry.
* DOCKER_EMAIL - Email address for container registry user.
* NAMESPACE - Name of the project or namespace that is visible on the console Support page.



These instructions are obviously for the Docker registry. If you are using the IBM Container Registry, then you need to set up your own image pull secret in your cluster:

- [Using an image pull secret to access images in other IBM Cloud accounts or external private registries from non-default Kubernetes namespaces](/docs/containers?topic=containers-registryother)
- [Copying an existing image pull secret](/docs/containers?topic=containers-registrycopy_imagePullSecret)
- [Referring to the image pull secret in your pod deployment](/docs/containers?topic=containers-imagespod_imagePullSecret)







 Step four: Create a Kubernetes secret hsmcrypto 

In order for a CA, peer, or ordering node to be able to communicate with the HSM client image you need to create a Kubernetes secret named hsmcrypto that contains the keys and configuration files for the HSM that you are using. When the console deploys a node that is configured with HSM, it uses this secret to access the HSM client image keys and configuration files.

The Kubernetes secret needs to be created in the IBM Blockchain Platform service instance namespace that is visible on the console Support page. If you are using the IBM Cloud HSM, the command would be: