vania-janet/multiturn-rag-retrieval-data huggingface dataset:
It is a symmetric 256-bit AES key. With the master key, you take the ownership of the cloud HSM and own the root of trust that encrypts the entire hierarchy of encryption keys, including root keys and standard keys in the key management keystore and Enterprise PKCS #11 (EP11) keys in the EP11 keystore. You need to configure the master key first before you can manage encryption keys. One service instance can have only one master key. If you delete the master key of the service instance, you can effectively crypto-shred all data that was encrypted with the keys that are managed in the service.





 Master key part 

If you initialize your service instance using key part files, or using smart cards together with the Management Utilities, a master key is composed two or three master key parts. Master key parts that are created in Hyper Protect Crypto Services are symmetric 256-bit AES keys. For security considerations, each key part can be owned by a different person. Key parts are stored in workstation key part files when the [IBM Cloud TKE CLI plug-in](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptstke-concept) is used to load the master key. Key parts are stored on [smart cards](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptssmart-card-concept) when the [Hyper Protect Crypto Services Management Utilities](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptsmanagement-utilities-concept) are used to load the master key. The key part owner needs to be the only person who knows the file password or the smart card personal identification number (PIN) for the key part.





 IBM Cloud Trusted Key Entry CLI plug-in 

Trusted Key Entry (TKE) command-line interface (CLI) plug-in is a CLI plug-in working with IBM Cloud CLI. The TKE plug-in provides a set of functions for managing crypto units that are assigned to an IBM Cloud user account.
This value is optional. The default value is false.

--registry-secret, --rs
: The name of the registry secret. The registry secret is used to authenticate with a private registry when you download the container image. This value is optional.

--registry-secret-clear, --rsc
: Clear the registry secret. This value is optional. The default value is false.

--request-timeout, --rt, --timeout, -t
: The amount of time in seconds that can pass before requests made to the application must succeed or fail. This value is optional. The default value is 0.

--rn, --revision-name
: The name of the revision. Use a name that is unique within the application.



* The name can contain lowercase letters, numbers, and hyphens (-).
* The name must end with a lowercase alphanumeric character.
* The fully qualified revision name must be in the format, Name_of_application-Name of revision.
* The fully qualified revision name must be 63 characters or fewer.



This value is optional.

--scale-down-delay, --sdd
: The amount of time in seconds that must pass at reduced concurrency before the application is scaled down. An increase of the number of concurrent requests causes an application to scale up. If the number of requests drops (reduced concurrency), the specified amount of time for this option determines how long the reduced concurrency needs to persist, before the application is scaled down. By default, the application will be scaled down immediately, if reduced concurrency is detected. This value is optional. The default value is 0.

--service-account, --sa
: The name of the service account. A service account provides an identity for processes that run in an instance. For built-in service accounts, you can use the shortened names manager, none, reader, and writer. You can also use the full names that are prefixed with the Kubernetes Config Context, which can be determined with the project current command. This value is optional.
Show more
4. Use the following command to export complete path of env.yaml and ibm-hyper-protect-container-runtime-1-0-s390x-11-encrypt.crt:

ENV="<PATH to env.yaml>"
CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-11-encrypt.crt>"
5. Use the following command to create a random password:

PASSWORD="$(openssl rand 32 | base64 -w0)"
6. 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)"
7. Use the following command to encrypt env.yaml with a random password:

ENCRYPTED_ENV="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$ENV" | base64 -w0)"
8. Use the following command to extract the encrypted env section:

echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_ENV}"



Steps 4 - 8 are used to encrypt the env section. If you choose to not encrypt this section, skip these steps.





 Preparing the signature 

Complete the following steps on an Ubuntu system, to prepare the signature:
Generating and using an SSH key 

Secure Shell (SSH) keys authenticate your access to a server that uses public-key cryptography and challenge-response authentication. By using SSH key pairs, you can authenticate your access to the server without sending your password over the network. You can also use it with automation since it allows for unattended server communication. When generating an SSH key-pair, a private key file and a public key file are created. The private key file must be secured in your workstation and the public key file is copied on to the remote server for authentication and communication.

You can set up one or more SSH keys for root login when you create virtual server instances. The keys are loaded into the root's authorized_keys file. SSH keys allow you to securely log in to a virtual server instance.

You can use the ssh-keygen tool to generate SSH keys. To generate an SSH key, complete the following steps:



1. Ensure that you have the proper account permissions and device access. Only the account owner, or a user with the Manager service access role, can generate SSH keys. For more information, see [Service access roles](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-managing-resources-and-usersservice-access-roles).
2. Run the ssh-keygen command in your on-premises workstation. The following example generates a standard 2048-bit RSA key. The command prompts you for the location to store the key (default is $HOME/.ssh/) as well as a passphrase to secure the SSH key.



root@bck2:/etc ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
rule-e76a3a81-b0d0-41fc-947d-13dc9cfff379 - Check whether IBMid password policy prevents password reuse below the minimum of 
rule-759d504b-9eed-4602-8b5b-7244bf3f5690 - Check whether IBMid password may contain only printable ASCII characters (in the range 33 - 126)
rule-bcbd57e1-3cdc-4b6d-820b-2c63bc777e19 - Check whether IBMid password policy contains spaces or any of the following characters: ;:("?)<>
rule-fa06f6f2-b98e-49ac-aa55-d57de9e320d3 - Check whether IBMid uses a password meter that coaches users to create strong passwords that exceed the minimum requirements
rule-548a3321-6a39-400c-9c2d-0df9a13afd02 - Check whether IAM roles are used to create IAM policies for IBM resources
rule-726ec899-505e-4de9-ac1b-9578ef62f89f - Check whether a support role has been assigned in IAM to manage cases in the IBM Cloud Support Center
rule-962e2bde-2a4f-4e07-a352-ce17708b1e85 - Check whether API keys are not created in IAM during the initial setup of IAM users
rule-61fa114a-2bb9-43fd-8068-b873b48bdf79 - Check whether IAM users are attached to at least one access group
rule-4d86c074-097e-4ff3-a763-ccff128388e2 - Check whether multifactor authentication (MFA) is enabled at the account level
rule-0704e840-e443-4781-b9be-ec57469d09c1 - Check whether permissions for API key creation are limited and configured in IAM settings for the account owner
* Preshared key - Specify the authentication key of the VPN gateway for the network outside your VPC. The preshared key is a string of hexadecimal digits, or a passphrase of printable ASCII characters. To be compatible with most peer gateway types, this string must follow these rules:



* Can be a combination of digits, lower or upper case characters, or the following special characters: - + & ! @ $ % ^ * ( ) . , :
* The length of the string must be 6 - 128 characters.
* Cannot start with 0x or 0s.



* Local IBM CIDRs (Policy-based VPN only) - Specify one or more CIDRs in the VPC you want to connect through the VPN tunnel.
* Peer CIDRs (Policy-based VPN only) - Specify one or more CIDRs in the other network you want to connect through the VPN tunnel. Subnet range overlap between local and peer subnets is NOT allowed.



3. To configure how the VPN gateway sends messages to check that the peer gateway is active, specify the following information in the Dead peer detection section.



* Action - The action to take if a peer gateway stops responding. For example, select Restart if you want the gateway to immediately renegotiate the connection.
* Interval (secs) - How often to check that the peer gateway is active. By default, messages are sent every 2 seconds.
* Timeout (secs) - How long to wait for a response from the peer gateway. By default, a peer gateway is considered inactive if a response isn't received within 10 seconds.



4. In the Policies section, specify the Internet Key Exchange (IKE) and Internet Protocol Security (IPsec) options to use for Phase 1 and Phase 2 negotiation of the connection.



* Select Auto if you want the gateway to try to automatically establish the connection.
* Select or create custom policies if you need to enforce particular security requirements, or if the VPN gateway for the other network doesn't support the security proposals that are tried by auto-negotiation.









 Adding a connection from the CLI
decode the payload to get the original string (credentials)
$ echo $PAYLOAD | base64 -d

{
"host": "localhost",
"database": "dev-backup",
"username": "my-username",
"password": "my-password"
}







 Required parameters 

KEY_NAME
: A unique, human-readable alias to assign to your key.





 Optional parameters 

-k, --key-material
: If you generated a key then this is the base64-encoded key material that you store and manage in the service.

Root keys must be 16, 24, or 32 bytes long; corresponding to 128, 192, or 256 bits. The key must be base64-encoded.

Standard keys can be up to 7,500 bytes in size. The key must be base64-encoded.

If you are creating a key using an import token then this is the encrypted key from the kp import-token key-encrypt process.

To generate a new key, omit the -k, --key-material parameter.







 kp key delete 

[Delete a key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-keys) that is stored in your Key Protect service.

ibmcloud kp key delete KEY_ID
-i, --instance-id INSTANCE_ID
[-f, --force]
[-o, --output OUTPUT]



 Examples 

These are examples of kp key delete.



 Example 1 

Delete a root key.

 create a root key
$ ibmcloud kp key create my-root-key

Creating key: 'my-root-key', in instance: '390086ac-76fa-4094-8cf3-c0829bd69526'...
OK
Key ID Key Name
8635b804-9966-4918-a16b-d561fdbf181f my-root-key

 show key details
--type ([]string)
: Optional. The type of keystores that you want to retrieve. Values that can be set are: aws_kms, azure_key_vault, ibm_cloud_kms, and google_kms.

--name (string)
: Optional. Return only keystores whose name contains the string. The length must be between 1 and 100 characters. The value must match regular expression /.+/.

--description (string)
: Optional. Return only keystores whose description contains the string. The length must be between 1 and 200 characters. The value must match regular expression /.+/.

--group (string)
: Optional. The keystore group. This query parameter cannot be used in conjunction with the groups[] query parameter.

--groups ([]string)
: Optional. Keystore groups.

--vault-id ([]string)
: Optional. The UUID of the vault. The list items must match the regular expression /^[-0-9a-z]+$/.

--location (string)
: Optional. Keystore location.

--limit (int64)
: Optional. The number of keystores to retrieve. The value must between 1 and 1000.

--offset (int64)
: Optional. The number of keys to skip. The minimum value is 0.

--sort ([]string)
: Optional. The sorting order. The default value is ["-updated_at"]. The list items must match regular expression /^-?[a-z0-9_.\[\],-]+$/.

--all-pages (bool)
: Optional. Invoke multiple requests to display all pages of the collection for keystores.
* Example

ibmcloud hpcs uko keystores --output json
* Output

The command returns the output similar to the following example:

{
Managing software passwords 

You can manage the passwords for the software on each device.



  Before you begin 

First, navigate to the device menu and ensure you have the correct account permissions to complete the tasks.



*  Go to your console's device menu. For more information, see [Navigating to devices](https://cloud.ibm.com/docs/bare-metal?topic=virtual-servers-navigating-devices).
*  Mak\e sure that you have any necessary account permissions and device access. Only the account owner, or a user with the Manage Users classic infrastructure permission, can adjust the permissions.



For more information about permissions, see [Classic infrastructure permissions](https://cloud.ibm.com/docs/iam?topic=iam-infrapermissioninfrapermission) and [Managing device access](https://cloud.ibm.com/docs/vsi?topic=virtual-servers-managing-device-access).





  Managing software passwords on devices 

Each piece of software that is created on a device is assigned a password that is automatically generated by IBM Cloud infrastructure systems. Software passwords for each device are stored on the Passwords tab on the Device Details screen in the IBM Cloud console.

After you access the software for the first time, change your passwords.

Optionally, you can store software credentials on the Passwords tab for each device. However, when you store passwords in the IBM Cloud console, any person with access to the account and appropriate permissions can view those passwords.
You can use the /forgot_password endpoint to allow users to recover their password if they forget it.

Supply the following data in the request body:



* Your tenant ID.
* The email of the Cloud Directory user.



When the endpoint is called, a reset password email is sent to the user. The email contains a Reset button. After they press the button, a screen is displayed by App ID where they can reset their password.

You can present your own post reset password page:



1. Configure your Cloud Directory [settings](https://cloud.ibm.com/docs/appid?topic=appid-cloud-directorycd-settings) in the GUI. Allow users to manage their account from your app must be set to On.
2. In the Reset Password tab of the service dashboard, be sure that Forgot password email is set to On.
3. Enter the URL for your landing page in the URL for your custom reset password page



When this value is provided, App ID calls the URL along with a context query. The context parameter is used to receive the result when /forgot_password/confirmation_result is called. If the result is successful, then you can display your custom page.

Add a random string to your custom reset password page and pass it to your back-end when the request is submitted. Have your handler validate the string and call the /change_password endpoint only if it is valid. By doing so, you can reduce vulnerability of your back-end reset password endpoint.





 Change password 

You can use the /change_password endpoint in two ways: when a user submits a reset request, or when a user is signed in to your app and wants to update their password.

Before you call the /change_password API to allow a user to reset their password, it is highly recommended to check whether the context has a successful result by using the /forgot_password/confirmation_result endpoint. This operation adds a higher level of security to your back-end reset password process and ensures that a user can modify their password only if the context is still valid.

To update a user's password after a reset request, supply the following data in the request body:
To do so, store the password or key into IBM Cloud® Secrets Manager and specify an [access secret clause](https://cloud.ibm.com/docs/sql-query?topic=sql-query-sql-referenceaccessSecrets) in your query. For more information, see the [security documentation](https://cloud.ibm.com/docs/sql-query?topic=sql-query-authenticationaccessauthentication). With this option, you can connect to any Db2 database that is accessible from the public IBM Cloud® network.

For backward compatibility, it is possible to store the password or API key in IBM® Key Protect for IBM Cloud®. However, with this option the key cannot be rotated and it is more difficult to use. This option will be deprecated in the future.

The Db2 table URI has the following form:

db2://<db2 host name>[:<db2 port number>]/<table name>

The <db2 host name> is the hostname of the Db2 instance that is used to access the Db2 web console and is also used for Java database connectivity (JDBC).

The <db2 port number> is optional. It is the port number of the DRDA endpoint of the Db2 instance that is used by client JDBC drivers. The default value is 50001. For IBM® Db2® Warehouse on Cloud instances, this port number is fixed and you can omit it. For IBM® Db2® on Cloud instances, the port number can vary. Check the instance configuration to get the correct port number.

The <table name> part specifies the table that is created in your database. It has the format <schemaname>.<tablename>. If you omit the <schemaname> part, the table is created in the schema of database user that was created for the IBMid of the SQL user. The table name is case-preserving, so use uppercase to match database defaults.

The following URI is an example of a Db2 table URI:
The following attributes are part of the Token Authentication container input, which can be provided when creating a new Token Authentication. Attributes are optional unless otherwise noted.



* uniqueId - (Required) The unique ID of the mapping to which the existing behavior belongs.
* path - (Required) The path, relative to the domain that is accessed through token authentication.
* name - The token name. If this value is empty, then it is set to the default value __token__.
* tokenKey - (Required) The token encryption key, which specifies an even number of hex digits for the token key. An entry can be up to 64 characters in length.
* escapeTokenInputs - Possible values 0 and 1. If set to 1, input values are escaped before adding them to the token. Default value is 1.
* ignoreQueryString - Possible values 0 and 1. If set to 1, query strings are removed from a URL when computing the token’s HMAC algorithm. Default value is 0.
* tokenDelimiter - Specifies a single character to separate the individual token fields. The default value is .
* aclDelimiter - Specifies a single character to separate access control list (ACL) fields. The default value is !.
* hmacAlgorithm - Specifies the algorithm to use for the token’s hash-based message authentication code (HMAC) field. Valid entries are SHA256, SHA1, or MD5. The default value is SHA256.
* transitionKey - The token transition key, which specifies an even number of hex digits for the token transition key. An entry can be up to 64 characters in length.



* Returns - An object of type SoftLayer_Container_Network_CdnMarketplace_Configuration_Behavior_TokenAuth.



See this example to [create a token auth](https://cloud.ibm.com/docs/CDN?topic=CDN-code-examples-using-the-cdn-apicreate-token-auth-example).

--------------------





 updateTokenAuth
IA-5 (g) <br><br> * Check whether Secrets Manager user credentials are rotated at least every # days<br> * Check whether Secrets Manager arbitrary secrets are rotated at least every # days<br> * Check whether Hyper Protect Crypto Services encryption keys that are generated by the service are rotated automatically at least every # months<br><br><br> 







 NIST supplemental guidance 

Individual authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial authenticator content is the actual content (e.g., the initial password) as opposed to requirements about authenticator content (e.g., minimum password length). In many cases, developers ship information system components with factory default authentication credentials to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant security risk. The requirement to protect individual authenticators may be implemented via control PL-4 or PS-6 for authenticators in the possession of individuals and by controls AC-3, AC-6, and SC-28 for authenticators stored within organizational information systems (e.g., passwords stored in hashed or encrypted formats, files containing encrypted or hashed passwords accessible with administrator privileges). Information systems support individual authenticator management by organization-defined settings and restrictions for various authenticator characteristics including, for example, minimum password length, password composition, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication. Specific actions that can be taken to safeguard authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing individual authenticators with others, and reporting lost, stolen, or compromised authenticators immediately. Authenticator management includes issuing and revoking, when no longer needed, authenticators for temporary access such as that required for remote maintenance. Device authenticators include, for example, certificates and passwords.
Retrieving information about a virtual server 

After you create a virtual server instance by using the Hyper Protect Virtual Servers service, you can view detailed information about your new instance.

The Ubuntu servers are preconfigured in such a way that the passwords expire after 90 days. After the user password expires, you have 30 days to change your password. If you don't change your password within the 30 days, your account becomes inactive and it is no longer possible to log in with SSH even if you are using SSH-keys. For more information, see [Protecting a virtual server](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-protect_vs).



 Retrieving information in the UI 



1. To select the Hyper Protect Virtual Servers resource, either:



* Go to the [Resource list](https://cloud.ibm.com/resources), then look for your virtual server instance under the Services entry in the Name column.
* From the IBM Cloud dashboard or the IBM Cloud Navigation Menu, select View all within the Resource summary area to open the Resource list. The column Location displays the data center where your instance was created. Use the filter to search for virtual server instances in certain regions or data centers. See also Figure 2 from [Provisioning a virtual server](https://cloud.ibm.com/docs/services/hp-virtual-servers?topic=hp-virtual-servers-provision).



2. Click your virtual server instance to open the Hyper Protect Virtual Servers dashboard.



In this dashboard:



* The Locate map shows you in which region your instance was created.
* You can find the public IP address, which you use to connect to the virtual server.



You must use the internal IP address when you connect to a virtual server from another virtual server, which is in the same virtual LAN (VLAN). VLANs span across all data centers within their region.

You must also work with the internal IP addresses, when you connect to other IBM Cloud Cloud services that are located within the same data center.

Zoom

!