vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The value must match regular expression /^[A-Za-z0-9](?:_-\.[A-Za-z0-9]+)$/.

--configuration-patch (generic map)
: JSON Merge-Patch content for update_configuration.

Provide a JSON string option or specify a JSON file to read from by providing a filepath option that begins with a @, e.g. --configuration-patch=@path/to/file.json.

--x-sm-accept-configuration-type (string)
: The configuration type of this configuration - use this header to resolve 300 error responses.

Allowable values are: public_cert_configuration_ca_lets_encrypt, public_cert_configuration_dns_classic_infrastructure, public_cert_configuration_dns_cloud_internet_services, iam_credentials_configuration, private_cert_configuration_root_ca, private_cert_configuration_intermediate_ca, private_cert_configuration_template.

--api-key (string)
: The API key that is generated for this secret.

After the secret reaches the end of its lease (see the ttl field), the API key is deleted automatically. If you want to continue to use the same API key for future read operations, see the reuse_api_key field.

The maximum length is 60 characters. The minimum length is 5 characters. The value must match regular expression /^(?:[A-Za-z0-9_\-]{4})(?:[A-Za-z0-9_\-]{2}==|[A-Za-z0-9_\-]{3}=)?$/.

--lets-encrypt-environment (string)
: The configuration of the Let's Encrypt CA environment.

Allowable values are: production, staging.

--lets-encrypt-private-key (string)
: The PEM-encoded private key of your Let's Encrypt account.

The maximum length is 100000 characters.
You can enable the sessionauth parameter to encrypt the generated keys into the keystore or to decrypt the key before you use it. The password can be 6 - 8 characters.



Keystore passwords are not stored in the service instance. You, as the keystore administrator, are responsible for maintaining a local copy of the passwords. If a password is lost, you need to contact the Support team to reset the keystore, which means all data in the keystore is cleared.

Both the in-memory keystores and the database-backed keystores are composed of the following types of keystores:



* Public keystore: Stores keys that are less sensitive and that are to be accessed by any user types.
* Private keystore: Stores keys that encrypt sensitive data and that are to be accessed by normal users only.



Depending on the [user types](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-pkcs11-intropkcs11-user-intro) and key attributes settings, the generated keys are stored in different keystores. The following list summarizes the criteria of how keys are stored:



* The CKA_TOKEN attribute value decides whether the generated key is stored in an in-memory keystore or in a database-backed keystore.

If you want to store the key in the database-backed keystore, set CKA_TOKEN to TRUE in key or key pair generation templates. The PKCS #11 library initialization process establishes a gRPC connection with the IBM Cloud, which facilitates the storing and retrieval of key objects to or from the database-backed keystore. By default, CKA_TOKEN is set to FALSE, which means the key object is stored in an in-memory keystore within the process address space of the PKCS #11 application.
* The CKA_PRIVATE attribute value decides whether a key that is generated by normal users is to be stored in a public or private keystore.

By default, if a user is logged in as a normal user, generated keys are stored in the private keystores, except for the case where CKA_PRIVATE is set to FALSE.
Allowable values are: exclusive, exclusive_delete.







 Examples 

ibmcloud secrets-manager secret-lock --secret-type=arbitrary --id=exampleString --locks='[{"name": "lock-1", "description": "lock for consumer-1", "attributes": {"anyKey": "anyValue"}}]' --mode=exclusive







 ibmcloud secrets-manager secret-unlock 

Delete one or more locks that are associated with the current version of a secret.

A successful request deletes the locks that you specify. To remove all locks, you can pass {"locks": [""]} in in the request body. Otherwise, specify the names of the locks that you want to delete. For example, {"locks": ["lock1", "lock2"]}.

Note: A secret is considered unlocked and able to be revoked or deleted only after all of its locks are removed. To understand whether a secret contains locks, check the locks_total field that is returned as part of the metadata of your secret.

ibmcloud secrets-manager secret-unlock --secret-type SECRET-TYPE --id ID [--locks LOCKS]



 Command options 

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

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

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

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

--locks ([]string)
: A comma-separated list of locks to delete.

The list items must match regular expression /^(\w(([\w-.]+)?\w)?|[])$/.





 Examples
Security strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to direct attack, and resistance to tampering or bypass. Security assurance requirements include: (i) development processes, procedures, practices, and methodologies; and (ii) evidence from development and assessment activities providing grounds for confidence that the required security functionality has been implemented and the required security strength has been achieved. Security documentation requirements address all phases of the system development life cycle. Security functionality, assurance, and documentation requirements are expressed in terms of security controls and control enhancements that have been selected through the tailoring process. The security control tailoring process includes, for example, the specification of parameter values through the use of assignment and selection statements and the specification of platform dependencies and implementation information. Security documentation provides user and administrator guidance regarding the implementation and operation of security controls. The level of detail required in security documentation is based on the security category or classification level of the information system and the degree to which organizations depend on the stated security capability, functions, or mechanisms to meet overall risk response expectations (as defined in the organizational risk management strategy). Security requirements can also include organizationally mandated configuration settings specifying allowed functions, ports, protocols, and services. Acceptance criteria for information systems, information system components, and information system services are defined in the same manner as such criteria for any organizational acquisition or procurement. The Federal Acquisition Regulation (FAR) Section 7.103 contains information security requirements from FISMA.
One use case for supplying additional authentication data (AAD) is to "password protect" the ciphertext to make it more difficult to unwrap.

The ciphertext and the AAD is required to unwrap the ciphertext and reveal the plaintext data encryption key (DEK).

 create a root key
$ KEY_ID=$(ibmcloud kp key create my-root-key --output json | jq -r '.["id"]')

$ echo $KEY_ID

5f2cc155-fe16-492c-845c-4d1f0688c7ba

 create a random, base64-encoded, 32-byte data encryption key (DEK)
$ PLAINTEXT=$(openssl rand -base64 32)

$ echo $PLAINTEXT

H4ZfQe66aKcxirfCdNZ/3Na0JECP6HsAM3yclKmIfPQ=

 set the additional authentication data (AAD)
$ AAD1=My-Secret-Password
$ AAD2=My-Verification-Phrase

 wrap the plaintext with the root key and AAD
$ CIPHERTEXT=$(ibmcloud kp key wrap $KEY_ID -a "$AAD1,$AAD2" -p $PLAINTEXT --output json | jq -r '.["Ciphertext"]')

$ echo $CIPHERTEXT

eyJjaXBoZXJ0ZXh0IjoiL1pQUzRLbUxQ ...<redacted>... ZjA2ODhjN2JiIn0=

 unwrap the ciphertext and reveal the original plaintext DEK
$ ibmcloud kp key unwrap $KEY_ID $CIPHERTEXT -a $AAD1,$AAD2

Unwrapping key...
OK
Plaintext Rewrapped Plaintext
H4ZfQe66aKcxirfCdNZ/3Na0JECP6HsAM3yclKmIfPQ=

 this should fail (missing some of the AAD)
Why is my password incorrect? 

You must have a valid password that's associated with your IBMid or SoftLayer ID to log in to the IBM Cloud console.

  What’s happening 

When you try to log in to IBM Cloud, the following error message is displayed:

> The password that you entered is not correct.

  Why it’s happening 

The password that you used to log in to IBM Cloud isn't valid.

  How to fix it 

Use one of the following options:



*  Go to the [My IBM profile page](https://myibm.ibm.com/dashboard/) to confirm that you're using a valid password.
*  If you forgot your password, click Forgot your password to reset your password.
*  If you forgot your IBMid or continue to have problems with your password, contact the [Worldwide IBM Registration Help Desk](https://www.ibm.com/ibmid/myibm/help/us/helpdesk.html) for help.



If you sign in to IBM Cloud and the log in process is disrupted for any reason, like resetting your password, return to the console and start the log in process again.
{region}.secrets-manager.appdomain.cloud/api/v2/secrets/{id}/versions"

To have the service generate and assign a random password to your credential, you can pass an empty string on the password field. For example, { "password": ""}. Secrets Manager replaces the existing value with a randomly generated 32-character password that contains uppercase letters, lowercase letters, digits, and symbols.

A successful response returns the ID value for the secret, along with other metadata. For more information about the required and optional request parameters, check out the [API docs](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2update-secret).







 Manually rotating secrets with Terraform 

You can manually rotate your arbitrary secrets, key-value secrets, or imported certificates by using Terraform for Secrets Manager. To manually rotate other types of secrets, you must use the UI, the API or the CLI.



 Rotating arbitrary secrets 

You can rotate arbitrary secrets by using Terraform for Secrets Manager.

To rotate an arbitrary secret, modify the value of the payload attribute in your ibm_sm_arbitrary_secret resource configuration, and run terraform apply to apply the change. If you're using an input variable for the payload, modify its value in the variables.tf file.

You can also modify other attributes of the arbitrary secret at the same time, including metadata attributes such as description, custom_metadata, or version_custom_metadata.





 Rotating key-value secrets 

To rotate a key-value secret by using Terraform for Secrets Manager, modify the value of the data attribute in your ibm_sm_kv_secret resource configuration, and run terraform apply to apply the change. If you're using an input variable for the payload, modify its value in the variables.tf file.

You can also modify other attributes of the key-value secret at the same time, including metadata attributes such as description, custom_metadata or version_custom_metadata.





 Rotating imported certificates 

You can rotate imported certificates by using Terraform for Secrets Manager.
--password-from-json-file, --pfj
: The path to a JSON file containing the password to access the registry server. The apikey field is used for the password. This value is optional.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.

--server, -s
: The URL of the registry server. This value is optional.

--username, -u
: The username to access the registry server. This value is optional.





 Example 

The following example updates a password for the image registry access that is called myregistry.

ibmcloud ce registry update --name myregistry --password NEW_API_KEY





 Example output 

Getting image registry access secret 'myregistry'...
Updating image registry access secret 'myregistry'...

OK









 Repo commands 

A code repository, such as GitHub or GitLab, stores source code. With Code Engine, you can add access to a private code repository and then reference that repository from your build.

You must be within the context of a [project](https://cloud.ibm.com/docs/cli?topic=cli-clicli-project) before you use repo commands.

For more information about accessing repositories, see [Accessing private code repositories](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories).

To see CLI help for the repo commands, run ibmcloud ce repo -h.

Beginning with CLI version 1.42.0, defining and working with secrets in the CLI is unified under the secret command group. See [ibmcloud ce secret](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) commands.
Setting LDAP authentication 

Set your authentication method to LDAP with the [REGISTER EXTERNAL AUTHENTICATION SYSTEM SQL statement](https://www.ibm.com/docs/en/netezza?topic=reference-register-external-authentication).

Two factor authentication is not supported with an external authentication system.



 Syntax 

REGISTER EXTERNAL AUTHENTICATION SYSTEM 'LDAP' with BASE SERVER
[ VERSION ]
[ BINDDN { bind-string | NONE } ]
[ BINDPW { bind-password | NONE } ]
[ PORT ]
[ SCOPE { SUB | ONE | BASE } ]
[ SSL { ON | OFF } ]
[ ATTRNAME ]
[ NAMECASE { LOWERCASE | UPPERCASE }]

Where:



Table 1. REGISTER EXTERNAL AUTHENTICATION SYSTEM command config for LDAP.

 Input Description 

 VERSION The LDAP protocol version number to use. The default is 3. 
 BINDDN The Distinguished Name to use when binding to the LDAP server. A bind string is optional. This clause is typically not defined for conducting anonymous LDAP look-ups. 
 BINDPW The password that accompanies the BINDDN for binding to the LDAP server. 
 PORT The port number to use when it connects to the LDAP server. The default is 389. 
 SCOPE The scope to use when it searches the LDAP tree. 
 SSL Default is OFF. If ON, SSL is used when it contacts the LDAP server. When you specify LDAP as the authentication type, you must specify the SSL option. 
 ATTRNAME The field defined in the LDAP server that contains the user name. For Microsoft Active Directory, this is typically 'sAMAccountname', 'uid' for IBM® Tivoli Directory Server, and 'cn' for OpenLDAP servers. The default is 'cn'. 
 NAMECASE Indicates whether the LDAP server stores the user name in lowercase or uppercase. 







 Setting LDAP authentication with the web console 



1. [Log in to the web console](https://cloud.ibm.com/docs/netezza?topic=netezza-getstarted-console) as an admin user.
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}/.

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

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





 Example 

ibmcloud secrets-manager secret-version-data-delete --secret-id=0b5571f7-21e6-42b7-91c5-3f5ac9793a46 --id=eb4cf24d-9cae-424b-945e-159788a5f535







 ibmcloud secrets-manager secret-version-metadata 

Get the metadata of a secret version by specifying the ID of the version. You can use the current or previous aliases to refer to the current or previous secret version.

A successful request returns the metadata that is associated with the specified version of your secret.

ibmcloud secrets-manager secret-version-metadata --secret-id SECRET-ID --id ID



 Command options 

--secret-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}/.

--id (string)
: The ID of the secret version. Required.
The command to manually rotate a username_password secret with a service-generated password returns the following output:

{
"request_id": "67992946-3fd7-8cbe-9464-f5bc0cc8254e",
"lease_id": "",
"lease_duration": 0,
"renewable": false,
"data": {
"created_by": "iam-ServiceId-b7ebcf90-c7a9-495b-8ce8-bbf33cb95ca0",
"creation_date": "2020-10-22T15:09:19Z",
"crn": "crn:v1:bluemix:public:secrets-manager:us-south:a/791f5fb10986423e97aa8512f18b7e65:e415e570-f073-423a-abdc-55de9b58f54e:secret:cb32abc1-2a4b-e0fd-f403-233e5249e130",
"id": "cb32abc1-2a4b-e0fd-f403-233e5249e130",
"labels": [],
"last_update_date": "2020-10-22T16:25:55Z",
"name": "new-username-password",
"secret_data": {
"password": "TYRodi/HX7s095UpQ38)L1z(t4u003ccG6!2",
"username": "my-username"
},
"secret_type": "USERNAME_PASSWORD",
"state": 1,
"state_description": "Active"
},
"warnings": null
}







 Delete a secret 

Use this command to delete a secret.
You can find valid values in the [Go x509 package documentation](https://pkg.go.dev/crypto/x509KeyUsage). Omit the KeyUsage part of the value. Values are not case-sensitive. To specify no key usage constraints, set this field to an empty list.

The list items must match regular expression /^[a-zA-Z]+$/. The maximum length is 100 items. The minimum length is 0 items.

--ext-key-usage ([]string)
: The allowed extended key usage constraint on private certificates.

You can find valid values in the [Go x509 package documentation](https://golang.org/pkg/crypto/x509/ExtKeyUsage). Omit the ExtKeyUsage part of the value. Values are not case-sensitive. To specify no key usage constraints, set this field to an empty list.

The list items must match regular expression /^[a-zA-Z]+$/. The maximum length is 100 items. The minimum length is 0 items.

--ext-key-usage-oids ([]string)
: A list of extended key usage Object Identifiers (OIDs).

The list items must match regular expression /(.?)/. The maximum length is 100 items. The minimum length is 0 items.

--use-csr-common-name (bool)
: When used with the private_cert_configuration_action_sign_csr action, this field determines whether to use the common name (CN) from a certificate signing request (CSR) instead of the CN that is included in the data of the certificate.

Does not include any requested Subject Alternative Names (SANs) in the CSR. To use the alternative names, include the use_csr_sans property.

--use-csr-sans (bool)
The first line of the file is used for the password. If neither --password, nor --password-from-file, nor --password-from-json-file option is specified, then you are prompted for the password. This value is optional.

--password-from-json-file, --pfj
: The path to a JSON file containing the password to access the registry server. The apikey field is used for the password. If neither --password, nor --password-from-file, nor --password-from-json-file option is specified, then you are prompted for the password. This value is optional.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.

--server, -s
: The URL of the registry server. This value is optional. The default value is us.icr.io.

--username, -u
: The username to access the registry server. This value is optional. The default value is iamapikey.





 Example 

The following example creates image registry access that is called myregistry to a Container Registry instance that is located at us.icr.io and uses a username of iamapikey and the IAM API key as a password.

ibmcloud ce registry create --name myregistry --server us.icr.io --username iamapikey --password API_KEY





 Example output 

Creating image registry access secret myregistry...

OK







 ibmcloud ce registry delete 

Delete an image registry access secret.

ibmcloud ce registry delete --name NAME [--force] [--ignore-not-found] [--quiet]



 Command Options 

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

--force, -f
: Force deletion without confirmation. This value is optional. The default value is false.
For more information about how strongSwan works, see [Introduction to strongSwan](https://docs.strongswan.org/docs/5.9/howtos/introduction.html) and [IPsec Protocol](https://docs.strongswan.org/docs/5.9/howtos/ipsecProtocol.html), too.

Encrypting data in transit can have some performance impact due to the processing that is needed to encrypt and decrypt the data at the endpoints.

The IPsec connection requires that you have an X.509 certificate for authentication. X.509 is an international standard format for public key certificates, digital documents that securely associate cryptographic key pairs with identities such as websites, individuals, or organizations. The Instance Metadata service is used to create the certificates.

A Certificate Signing Request (CSR) is a block of encoded texts that are forwarded to a certificate authority (CA) when users apply for a certificate. CSR is created on the server where the certificate is to be installed. CSR includes information such as domain name, organization name, locality, and country. The request also contains the public key, which is associated with the certificate that is generated, and the private key. The CA uses only the public key when the certificate is created. The private key must be saved and kept secret. As the private key is part of the key pair with the public key, and the certificate does not work if the private key is lost.

Encryption in transit is not supported on Bare Metal Servers for VPC.





 Configuring encryption in transit 

To use the feature, the following requirements need to be met:



* The file share must be based on the [dp2 profile](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&interface=apidp2-profile) and be configured with [Security Group access mode](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-aboutfs-share-mount-targets).
CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-11-encrypt.crt>"
4. Use the following command to create a random password (the contract is encrypted via symmetric AES with a random PASSWORD):

PASSWORD="$(openssl rand 32 | base64 -w0)"
5. Use the following command to encrypt password with ibm-hyper-protect-container-runtime-1-0-s390x-11-encrypt.crt:

ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl rsautl -encrypt -inkey $CONTRACT_KEY -certin | base64 -w0 )"
6. Use the following command to encrypt the workload.yaml file with a random password:

ENCRYPTED_WORKLOAD="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$WORKLOAD" | base64 -w0)"
7. Use the following command to get the encrypted section of the contract:

echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_WORKLOAD}"
8. Get the output from step 7 and add it to the user-data.yaml file.

workload: hyper-protect-basic.js7TGt77EQ5bgTIKk5C0pViFTRHqWtn..............

The prefix hyper-protect-basic is mandatory.







 Creating encrypted env section of a contract 

Complete the following steps on an Ubuntu system, to encrypt the env section used in a contract:



1.