vania-janet/multiturn-rag-retrieval-data huggingface dataset:
I created secrets that reference the default Ingress certificate, but I have not created and registered a Secrets Manager instance. How do I manage my secrets?
: If you don't register a Secrets Manager instance, IBM Cloud Kubernetes Service only automatically updates the default Ingress secret. You are responsible for managing any other secrets by using kubectl commands or another rotation method. If you have any secrets that reference the default Ingress certificate, you should remove them by using ibmcloud ks ingress secret rm.

What is the difference between the ibmcloud ks ingress instance CLI commands and the ibmcloud ks ingress secret CLI commands?
: There are two sets of CLI commands that work directly with Secrets Manager instances in IBM Cloud Kubernetes Service: the ibmcloud ks ingress secret commands and the ibmcloud ks ingress instance commands. The ibmcloud ks ingress instance commands are used to manage your Secrets Manager instances. The ibmcloud ks ingress secret commands are used to manage your Ingress secrets that are stored in a Secrets Manager instance or secrets that are written directly to the cluster.





 Setting up your Secrets Manager instance 

Follow the steps to set up Secrets Manager in your cluster.



 Enable service-to-service communication 

Integrating Secrets Manager with your IBM Cloud Kubernetes Service cluster requires service-to-service communication authorization. Follow the steps to set up the authorization. For additional info, see [Integrations for Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-integrationscreate-authorization).



1. In the IBM Cloud console, click Manage > Access (IAM).
2. Click Authorizations.
3. Click Create.
4. In the Source service list, select Kubernetes Service.
5. Select the option to scope the access to All resources.
6. In the Target service list, select Secrets Manager.
7. Select the option to scope the access to All resources.
8. In the Service access section, check the Manager option.
9. Click Authorize.







 Create a Secrets Manager instance
Managing access for toolchains in resource groups 

Toolchains that you create in your account might not be visible to other users by default. Access to toolchains in resource groups for users in your account is controlled by [IBM Cloud Identity and Access Management (IAM)](https://cloud.ibm.com/docs/services/account?topic=account-iamoverview). You can assign access to [new users](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-toolchains-iam-securitytoolchains-access-new-users) and [existing users](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-toolchains-iam-securitytoolchains-access-existing-users) in your account.

User access for Continuous Delivery service instances is managed separately. For more information about managing user access to Continuous Delivery service instances in resource groups, see [Managing user access to Continuous Delivery with Identity and Access Management](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-cd-iam-security).

Every user that accesses toolchains in your account must be assigned an IAM access policy. The policy determines which toolchains the user can access and what actions the user is allowed to take.

Policies enable access to be granted at different levels or scopes, including, but not limited to:



* Access across all toolchains in your account
* Access across all toolchains in a resource group in your account
* Access to a specific toolchain in your account



After you define the scope of the access policy, you assign a role. The role defines which actions the user is allowed to take. The following table lists the IAM platform access roles and the available toolchain actions for each role.



Table 1. IAM platform roles

 Platform Role Description of Actions Example Actions 

 Viewer View toolchains and delivery pipelines. <br><br> * Click a toolchain to open its Overview page.<br><br><br>
The chip can perform a limited set of cryptographic operations and is loaded with custom software. In the Management Utilities, the Smart Card Utility Program loads custom software on the smart card to create two types of smart cards:



* Certificate authority smart cards

The Certificate authority smart cards establish a set of smart cards that can work together, called a smart card zone.
* EP11 smart cards

Enterprise PKCS #11 (EP11) smart cards hold an administrator signature key and up to 85 master key parts. The custom software on an EP11 smart card includes functions for signing a command by using a private signature key that is stored on the smart card and for encrypting a master key part for delivery to a crypto unit.



Smart cards are protected by a personal identification number (PIN) that must be entered on a smart card reader PIN pad before the smart card performs the operations. The EP11 smart card has a single PIN. The certificate authority smart card has two PINs and both must be entered to enable operations.

When you use smart cards, consider the following recommendations:



* Create each master key part on a separate EP11 smart card and assign each master key part to a different person. Create backup copies of all smart cards and store them in a safe place.
* Order 10 or 12 smart cards and configure them this way:



* Create a certificate authority smart card and a backup certificate authority smart card.

A backup certificate authority smart card can be created by using the Smart Card Utility Program. Select CA Smart Card > Backup CA smart card from the menu, and follow the prompts.
* Create four EP11 smart cards to store administrator signature keys. Generate administrator signature keys separately on two EP11 smart cards and copy them to other two backup smart cards.

The contents of an EP11 smart card can be copied to another EP11 smart card that was created in the same smart card zone by using the Trusted Key Entry application. On the Smart card tab, click Copy smart card, and follow the prompts.
* Create four or six EP11 smart cards to store master key parts. Generate EP11 master key parts separately on two or three smart cards, depending on the number of key parts when you load your master key. Copy each key part value to a backup EP11 smart card.
* UI
* API







 Managing data encryption 

In IBM Cloud®, you can secure your resources with your own root keys. You can rotate your root keys regularly or manually as needed. You can verify key rotation by viewing Activity Tracker events. You can disable or delete root keys that are compromised or that you no longer need. You can restore root keys that were deleted within 30 days of their deletion.



 Manage root keys 

Manage your root keys by taking the following actions:



* View the association of root keys to the resources that they protect by [viewing root key registrations](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managing&interface=uibyok-root-key-registration).
* View key rotation information by looking at [root key registration](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managing&interface=uibyok-root-key-verify-rotation) in the KMS instance.
* [Rotate your root keys](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-key-rotation) at regular intervals or manually rotate imported root keys. Shortening the crypto period of a key reduces the possibility of a security breach.
* Decide whether importing your own HSM root key or generating a root key by the KMS is preferable. If you want to set up a rotation policy for automatic key rotation, you must use KMS-generated root keys.
* See what happens to your [root key state](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managing&interface=uibyok-root-key-states) when you take certain actions, such as disabling the key.
Editor As an editor, you can perform all platform actions except for managing the account and assigning access policies. 
 Operator As an operator, you can perform platform actions required to configure and operate service instances, such as viewing a service's dashboard. 
 Viewer As a viewer, you can view service instances, but you can't modify them. 







 Auto Scale for VPC 

Review the available platform and service roles and the actions mapped to each to help you assign access. If you're using the CLI or API to assign access, use is.instance-group for the service name.

Platform roles

Actions



Table 91. Platform roles - Auto Scale for VPC
Use the tab buttons to change the context of the table. This table has row and column headers. The row headers provide the platform role name and the column headers identify the specific information available about each role.

 Role Description 

 Administrator As an administrator, you can perform all platform actions based on the resource this role is being assigned, including assigning access policies to other users. 
 Editor As an editor, you can perform all platform actions except for managing the account and assigning access policies. 
 Operator As an operator, you can perform platform actions required to configure and operate service instances, such as viewing a service's dashboard. 
 Viewer As a viewer, you can view service instances, but you can't modify them. 







 SSH Key for VPC 

Review the available platform and service roles and the actions mapped to each to help you assign access. If you're using the CLI or API to assign access, use is.key for the service name.

Platform roles

Actions



Table 92. Platform roles - SSH Key for VPC
Use the tab buttons to change the context of the table. This table has row and column headers. The row headers provide the platform role name and the column headers identify the specific information available about each role.

 Role Description 

 Administrator As an administrator, you can perform all platform actions based on the resource this role is being assigned, including assigning access policies to other users. 
 Editor As an editor, you can perform all platform actions except for managing the account and assigning access policies.
[The task flow of service instance initialization with smart cards and the Management Utilities](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/hs-crypto//images/hsm-initialization-flow-smartcard.svg)

Figure 1. Task flow of service instance initialization with smart cards and the Management Utilities



 Step 1: Order smart cards and smart card readers 

Before you can configure smart cards, you need to first order [smart cards](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptssmart-card-concept) and [smart card readers](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptssmart-card-reader-concept) online.



 Ordering smart cards 

Complete the following steps to order smart cards:



1. Determine the quantity of smart cards that are required.

A minimum of two smart cards are needed to use the Management Utilities:



* A certificate authority smart card to define a smart card zone, which is a set of smart cards that can work together.
* An Enterprise PKCS #11 (EP11) smart card to hold a signature key and one or more master key parts that are used to configure service instances. Currently, the Management Utilities support two or three master key parts to be loaded.



For added security, the two or three master key parts that are used to configure a service instance can be generated on separate EP11 smart cards that are assigned to different people. The signature key that is used to sign commands to the crypto module can be generated on a separate EP11 smart card. Three or four EP11 smart cards are then needed to configure a service instance.
[CIS Proxy Toggle ON](https://cloud.ibm.com/docs-content/v1/content/cbb80bf851fb762a838129cba09d5674f8bfffda/Registry/includes/solution-tutorials/includes/solution-tutorials/images/solution32-multi-region-k8s-cis/cis-proxy.png)

CIS Proxy Toggle ON



Your GLB is now protected. An immediate benefit is that the origin IP addresses of your clusters will be hidden from the clients. If CIS detects a threat for an upcoming request, the user may see a screen like this one before being redirected to your application:

Zoom

![Verifying - DDoS protection](https://cloud.ibm.com/docs-content/v1/content/cbb80bf851fb762a838129cba09d5674f8bfffda/Registry/includes/solution-tutorials/includes/solution-tutorials/images/solution32-multi-region-k8s-cis/cis-DDoS.png)

Verifying - DDoS protection

In addition, you can now control what content gets cached by CIS and how long it stays cached. Go to Performance > Caching to define the global caching level and the browser expiration. You can customize the global security and caching rules with Page Rules. Page Rules enable fine-grained configuration using specific domain paths. As example with Page Rules, you could decide to cache all contents under /assets for 3 days:

Zoom

![Page Rules](https://cloud.ibm.com/docs-content/v1/content/cbb80bf851fb762a838129cba09d5674f8bfffda/Registry/includes/solution-tutorials/includes/solution-tutorials/images/solution32-multi-region-k8s-cis/cis-pagerules.png)

Page Rules







 Step 5: Remove resources 



 Remove Kubernetes Cluster resources 



1.
* Updating page rules settings using the CIS plugin for IBM Cloud CLI might result in an error if the page rule ID is not included in the JSON string or JSON file for the update. To work around this, submit the update using a complete JSON configuration file for the page rule, including the ID.
* Removing page rule settings using the CIS UI might not remove the setting, even though the UI reports a successful update. To work around this problem, use the CIS plugin for IBM Cloud CLI to remove the setting and include the page rule ID in the JSON update document:

$> ibmcloud cis page-rule-update <domain-id> <rule-id> -j <file>

The JSON file should include the complete page rule configuration, including ID, with the necessary updates.







 Edge functions 

Before changing your CIS instance from an Enterprise plan to a Standard plan, you must remove all edge function actions and triggers first. Any edge function actions and triggers brought from an Enterprise plan to a Standard plan are not editable, which might cause damage to the normal datapath behavior on your domain. After your plan downgrade is complete, you can recreate the edge functions actions and triggers in the new plan.
Understanding Kubernetes Security Posture Management (KSPM) 

IBM Cloud® Security and Compliance Center Workload Protection implements Kubernetes security posture management (KSPM). You need to understand KSPM and how it applies to monitoring your Kubernetes environment.

Cloud security posture management, or CSPM, uses automation to detect and remediate security and compliance issues in the cloud.

The relationship between Kubernetes security posture management and cloud security posture management is subjective. You can argue that KSPM is one component of CSPM, given that Kubernetes environments often run in the cloud.

Or, you can view KSPM as a distinct domain, because Kubernetes doesn’t always run in the cloud. That is, it can be deployed in on-premises environments as well. Also, the types of resources and configurations that KSPM validates, such as Kubernetes RBAC policies, are different from the resources that CSPM can protect. CSPM can protect cloud IAM policies, cloud networking configurations, and so on.

Regardless of how you choose to think about the relationship between KSPM and CSPM, what is important is understanding that KSPM addresses the security and compliance risks of Kubernetes. CSPM helps manage risks in other types of cloud-native environments. If you use Kubernetes, you need a security tool that offers specific KSPM functions such as IBM Cloud Security and Compliance Center Workload Protection.



 What is Kubernetes security posture management? 

Kubernetes security posture management, or KSPM, is the use of security automation tools to discover and fix security and compliance issues within a Kubernetes component.

For example, KSPM can detect misconfigurations in a Kubernetes RBAC role definition that grants users permissions that they should not have. For example, the ability to create new pods. Or, a KSPM tool can alert you to an insecure Kubernetes network configuration that allows communication between pods in different namespaces. Communication between pods in different namespaces would not be a typical setting.





 Why is Kubernetes security posture management important? 

As part of a broader Kubernetes security strategy, KSPM addresses several important security considerations.
After an origin server is marked unhealthy, multi-region failover reroutes traffic to the next available server in failover order.
* Load balancer monitors use the following HTTP user-agent: "Mozilla/5.0 (compatible; Cloudflare-Traffic-Manager/1.0; +https://www.cloudflare.com/traffic-manager/; pool-id: $poolid)". The $poolid contains the first 16 characters of the load balancer pool that is the target of the health check.
* To prevent health checks from failing, and to secure user infrastructure against spoofed checks from bad actors, it is recommended that you do the following:



* Only accept connections to hosts listed in the CIS IP ranges in your firewall or web-server.
* Use the CIS user agent to reject HTTP requests that don't come from these ranges.
* Ensure that your firewall or web server does not block or rate limit CIS health checks.









 Health check events 

Health Check Events are status changes from pools with connected health checks and their associated origin servers. If an origin's status degrades, a new item appears in a table, with the event's description.
When you deploy the machine learning model, you select the version of it that you want to deploy.





 Procedure 

To deploy a machine learning model, complete the following steps:



1. Log in as a Knowledge Studio administrator or project manager, and select your workspace.
2. Select Machine Learning Model > Versions.
3. Choose the version of the model that you want to deploy.

If there is only one working version of the model, create a snapshot of the current model. This versions the model, which enables you to deploy one version, while you continue to improve the current version. The option to deploy does not appear until you create at least one version.

Each version can be deployed to any number of service instances. Each deployed instance of a model version is given a unique Model ID, but is identical in all other ways.
4. Click Deploy, choose to deploy it to Discovery, and then click Next.
5. Select the IBM Cloud space and instance. If necessary, select a different region.
6. Click Deploy.
7. The deployment process might take a few minutes. To check the status of the deployment, click Status on the Versions tab next to the version that you deployed.

If the model is still being deployed, the status indicates "deploying". After deployment completes, the status changes to "available" or "deployed" if the deployment was successful, or "error" if problems occurred.

Once available, make a note of the model ID (model_id).







 What to do next 

To use the model, you must export the model, and then import it into Discovery.



1. Select Machine Learning Model > Versions.
2. Click Export current model.

If you have a Lite plan subscription, no export option is available.

The model is saved as a ZIP file, and you are prompted to download the file.
3. Download the file to your local system.
4. From the Discovery service, follow the steps to create a Machine Learning enrichment, which include uploading the ZIP file.
2. Click Algorithm Version.
3. Choose a version.



The latest and previous versions have date labels such as Latest (01-Jun-2022) or Previous (01-Jan-2022). See the [Watson Assistant release notes](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-watson-assistant-release-notes) for details about each algorithm version release.

Algorithm version choices are currently available for Arabic, Chinese (Simplified), Chinese (Traditional), Czech, Dutch, English, French, German, Japanese, Korean, Italian, Portuguese, and Spanish. The universal language model uses a default algorithm.



 Automatic retraining 

IBM Cloud

Watson Assistant was released as a service in July 2016. Since then, users have been creating and updating skills to meet their virtual assistant needs. Behind the scenes, Watson Assistant creates machine learning (ML) models to perform a variety of tasks on the user's behalf.

The primary ML models deal with action recognition, intent classification, and entity detection. For example, the model might detect what a user intends when saying I want to open a checking account, and what type of account the user is talking about.

These ML models rely on a sophisticated infrastructure. There are many intricate components that are responsible for analyzing what the user has said, breaking down the user's input, and processing it so the ML model can more easily predict what the user is asking.

Since Watson Assistant was first released, the product team has been making continuous updates to the algorithms that generate these sophisticated ML models. Older models have continued to function while running in the context of newer algorithms. Historically, the behavior of these existing ML model did not change unless the skill was updated, at which point the skill was retrained and a new model generated to replace the older one. This meant that many older models never benefited from improvements in our ML algorithms.

Watson Assistant uses continuous retraining. The Watson Assistant service continually monitors all ML models, and automatically retrains those models that have not been retrained in the previous 6 months. Watson Assistant retrains using the selected algorithm version.
If you have custom language or custom acoustic models that are based on the model, you must upgrade your existing custom models to take advantage of the updates by using the following methods:



* POST /v1/customizations/{customization_id}/upgrade_model
* POST /v1/acoustic_customizations/{customization_id}/upgrade_model



For more information, see [Upgrading custom models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-custom-upgrade).





 10 May 2019 

Updates to Spanish models for improved speech recognition
: The Spanish language models have been updated for improved speech recognition:



* es-ES_BroadbandModel
* es-ES_NarrowbandModel



By default, the service automatically uses the updated models for all speech recognition requests. If you have custom language or custom acoustic models that are based on the models, you must upgrade your existing custom models to take advantage of the updates by using the following methods:



* POST /v1/customizations/{customization_id}/upgrade_model
* POST /v1/acoustic_customizations/{customization_id}/upgrade_model



For more information, see [Upgrading custom models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-custom-upgrade).





 19 April 2019 

New strict parameter for custom model training now available
: The training methods of the customization interface now include a strict query parameter that indicates whether training is to proceed if a custom model contains a mix of valid and invalid resources. By default, training fails if a custom model contains one or more invalid resources. Set the parameter to false to allow training to proceed as long as the model contains at least one valid resource. The service excludes invalid resources from the training.