vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information about setting up a virtual private endpoint gateway, check out [About virtual private endpoint gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpe).





 19 May 2021 

Upcoming updates to supported cipher suites
: On 29 May 2021, Secrets Manager will deliver changes to the cipher suites that it supports for TLS connections to the service. This update is being implemented to enhance the security of IBM Cloud users and protect user data.



* What's changing? Beginning 29 May 2021, Secrets Manager API endpoints will allow only the following cipher suites:



* ECDHE-ECDSA-AES128-GCM-SHA256
* ECDHE-ECDSA-CHACHA20-POLY1305
* ECDHE-ECDSA-AES256-GCM-SHA384
* ECDHE-RSA-AES128-GCM-SHA256
* ECDHE-RSA-CHACHA20-POLY1305
* ECDHE-RSA-AES256-GCM-SHA384



* How will this change impact my environment? This change impacts clients that are configured to use ciphers that are not included on this list. To avoid connectivity issues with Secrets Manager, make sure that your client is configured to use only the allowed list of ciphers in TLS connections to the service. Reach out to [IBM Cloud support](https://cloud.ibm.com/unifiedsupport/cases/form) with any questions.



Manage secrets in your Continuous Delivery toolchain
: You can now configure Secrets Manager to securely manage secrets that are part of your Continuous Delivery toolchain.

For more information, check out the [announcement blog](https://www.ibm.com/cloud/blog/manage-secrets-in-continuous-delivery-with-ibm-cloud-secrets-manager).





 22 March 2021 

Manage secrets over a private network connection
: You can now create a private instance of Secrets Manager so that you can manage application secrets over a private network connection.
Assigning access to Secrets Manager 

You can enable different levels of access to IBM Cloud® Secrets Manager resources in your IBM Cloud account by creating and modifying IBM Cloud IAM access policies.

As an account owner, determine an access policy type for users, service IDs, and access groups based on your internal access control requirements. For example, if you want to grant user access to Secrets Manager at the smallest scope available, you can [assign access to a secret group](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-assign-accessassign-access-secret-group) in an instance.

To learn more about suggested guidelines for assigning access to secrets, check out [Best practices for organizing secrets and assigning access](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-best-practices-organize-secrets).



 Before you begin 

Before you get started, be sure that you have [Administrator platform access](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesassign-new-access) so that you can further assign roles and customize access policies for others.





 Assigning access to a Secrets Manager instance 

To assign access to a Secrets Manager instance and its contained secrets or secret groups, you can use the Access (IAM) section of the IBM Cloud console.



1. [Create an access group](https://cloud.ibm.com/docs/account?topic=account-groupscreate_ag) for the users and service IDs that you want to give access to and add those users to the group.

For example, you might have a group of security admins that might need the same level of access.
2. After you create a group and add users, go to Manage > Access (IAM) > Access Groups.
3. Select a table row, and click the Actions menu !
Resource suspension 

Individual resources are suspended if a resource is suspected of malicious or fraudulent activity.

When an instance or bare metal server is suspended it is powered off. Changes cannot be made to an instance or bare metal server in this state.



  Restoring access 

In cases of a suspension, resources can be restored. For more information, visit [IBM Cloud Support Center](https://cloud.ibm.com/unifiedsupport/cases) to review your open abuse cases.
2. List the existing image pull secrets in the default Red Hat OpenShift project for IBM Cloud Container Registry.

oc get secrets -n default | grep icr-io

Example output

all-icr-io          kubernetes.io/dockerconfigjson        1         16d
3. Copy the all-icr-io image pull secret from the default project to the project of your choice. The new image pull secrets are named <project_name>-icr-<region>-io.

oc get secret all-icr-io -n default -o yaml | sed 's/default/<new-project>/g' | oc create -n <new-project> -f -
4. Verify that the secrets are created successfully.

oc get secrets -n <project_name> | grep icr-io
5. To deploy containers, [add the image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret) to each deployment or to the service account of the project so that any deployment in the project can pull images from the registry.







 Creating an image pull secret with different IAM API key credentials 

You can assign IBM Cloud IAM access policies to users or a service ID to restrict permissions to specific registry image namespaces or actions (such as push or pull). Then, create an API key and store these registry credentials in an image pull secret for your cluster.

For example, to access images in other IBM Cloud accounts, create an API key that stores the IBM Cloud Container Registry credentials of a user or service ID in that account. Then, in your cluster's account, save the API key credentials in an image pull secret for each cluster and cluster project.

The following steps create an API key that stores the credentials of an IBM Cloud IAM service ID. Instead of using a service ID, you might want to create an API key for a user ID that has an IBM Cloud IAM service access policy to IBM Cloud Container Registry. However, make sure that the user is a functional ID or have a plan in case the user leaves so that the cluster can still access the registry.
config-sync error 10.127.225.204:Sync[10.127.225.204]: Remote user vyatta not in secrets group
syncing configuration to remote-router 10.127.225.223 ..
config-sync error 10.127.225.223:Remote:10.127.225.223: Connect failed:Could not open socket to 10.127.225.223:830
: To fix this, make sure you add the following configuration so that config-sync continues to work:

set service netconf
set service ssh port 830
set system login group secrets
set system login user vyatta group secrets
: If you use a different user than vyatta for config-sync, be sure to add that user into the secrets group.





 Upgrading from 1912 to 2012 

You might encounter these common issues when upgrading from 1912 to 2012:

AES-NI must be enabled before updating to 2012
: By default, some old BIOS versions from 2014 disable AES-NI. IPsec issues, as well as VRRP and config-sync issues, can be the result of AES-NI being disabled. To fix this, run a firmware update using a cloud portal for the VRA's system board BIOS before upgrading to 2012.

IPsec tunnels either do not initiate after a reboot or failover
: The Vyatta 5400's run-transition-scripts command was deprecated as noted in 2012's [release notes](https://docs.vyatta.com/en/release-notes/earlier-releases/earlier-releases/vnos-release-notes-2012/featurestopic-8059). Instead, use the notify ipsec configuration line in the VRA configuration file that replaced that command for the Vyatta 5600.
: This issue can also be caused by AES-NI not being enabled, per the previous issue.
: This example illustrates the old version:

set interfaces bonding dp0bond1 vrrp vrrp-group 1 run-transition-scripts backup /config/scripts/ipsec-stop
func getAttributes(accessTokenString: String, completionHandler: @escaping(Error?, [String:Any]?) -> Void)

func deleteAttribute(key: String, completionHandler: @escaping(Error?, [String:Any]?) -> Void)
func deleteAttribute(key: String, accessTokenString: String, completionHandler: @escaping(Error?, [String:Any]?) -> Void)

//Server-side Swift example

func getAllAttributes(accessToken: String, completionHandler: (Swift.Error?, [String: Any]?) -> Void)
func getAttribute(accessToken: String, attributeName: String, completionHandler: (Swift.Error?, [String: Any]?) -> Void)
func setAttribute(accessToken: String, attributeName: String, attributeValue : "abc", completionHandler: (Swift.Error?, [String: Any]?) -> Void)
func deleteAllAttributes(accessToken: String, completionHandler: (Swift.Error?, [String: Any]?) -> Void)







 Setting custom attributes 

You can add information about your users to their profile such as a role or preference, by setting a custom attribute. To set custom attributes before a user signs in to your application, see [preregistering future users](https://cloud.ibm.com/docs/appid?topic=appid-preregister).

By default, custom attributes are modifiable and can be updated by using an App ID access token from a client application. Without taking proper precautions, either the user or the application can update custom attributes immediately following the first user sign-in, if they have an access token. Doing so can potentially lead to unintended consequences. For example, a user might change their role from user to admin, which might expose administrative privileges to malicious users.



1. Go to the User profiles > Settings tab of the App ID dashboard.
Write secure Java web apps 

IBM® Cloud Foundry is deprecated and no longer supported as of 1 June 2023. For more information, see the [deprecation details](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecationdep_details).

All web apps and their runtime environments must be designed and coded with security in mind to avoid introducing severe security vulnerabilities. Review [Securing Liberty and its apps](https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_sec.html) to learn about implementing security best practices such as password encryption, authentication, and enabling secure communications.

IBM Cloud® provides a secure starter app to help you write more secure Liberty Java code and avoid most of the Cross-Site Scripting (XSS) issues. You may download this [secure starter app](https://github.com/IBM-Cloud/java-secure-app), build it and deploy it locally and on IBM Cloud.



 Why write secure web apps 

A security vulnerability can be exploited by various security attacks. An attack might steal credentials, cause loss of data and function, disrupt services, and damage the reputation and revenue of a business. Cross-Site-Scripting, XSS, is one of the common security vulnerabilities found in most web apps that must be avoided.

Instead of learning the theory of XSS attacks and remedial techniques before you start web app development, you can use this [secure starter app](https://github.com/IBM-Cloud/java-secure-app). The secure starter app includes coding examples of key secure coding practices that prevent XSS so you can start developing while you learn and apply XSS prevention techniques.





 How to use the secure sample app 

You can use the [secure starter app](https://github.com/IBM-Cloud/java-secure-app) as a starting point for new Liberty app development. Start by learning the XSS countermeasure code in the app and then apply it to the operations of the app API.
You can make the sync-map as specific, or as general as you want.

The next three lines designate the remote router's config-sync user and password, IP, and which sync-map to push. Any changes that match the rules for TEST, go to remote-router 192.168.1.22, using this login information. Note that for version 1801zf and earlier, a REST call is made to perform this using the VRA API. As a result, the HTTPS server must be running (and unblocked) on the remote router. Version 1908/1912 rewrites config-sync to use netconf instead of HTTPS to address performance issues in previous releases. The following lines are required, along with an allow in the firewall rules for each Vyatta, to make connections to each other on port 830:

set service netconf
set service ssh port 830
set service ssh port 22

To synchronize the configuration of a password, such as a pre-shared-secret for an IPsec VPN, the standby system must have the secrets group configured and the config-sync user must be in that group.

set system login group secrets
set system login user vyatta authentication plaintext-password ''
set system login user vyatta group secrets

Config-sync happens whenever you commit a change. Watch for error messages that come from the remote device. If the configuration is out of sync, you must fix it on the remote device to make it operational again.

You can also see configuration differences using the command show config-sync difference.
For example, you can import a secret from Secrets Manager into your cluster by running the following command. Specify the TLS certificate's CRN with the --cert-crn command option.

To import the secret with the ibmcloud ks ingress secret create command, you must have a default [Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr) instance registered to your cluster. If you do not have a Secrets Manager instance and your secrets are instead written directly to your cluster, your secrets do not have the required CRN value and you must manually copy them with kubectl commands.

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









 Managing non-TLS secrets 

To manage non-TLS secrets, you can use the ibmcloud ks ingress secret commands.

There are 4 types of non-TLS secrets:



* Arbitrary secrets hold one string value.
* IAM credentials hold an IAM API key.
* Username and password secrets hold a username and password as two separate values.
* Key values hold JSON values.



Learn how you can centrally manage your non-TLS secrets with [IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr). With Secrets Manager, you can create managed Kubernetes secrets, update your secrets automatically, create secret groups that control who has access to the secrets in your cluster, and more.



 Creating a non-TLS secret in your cluster 

Create a non-TLS secret by specifying the --type Opaque option in the ibmcloud ks ingress secret create command. With the Opaque type, you can include multiple non-certificate CRN values. If the --type option is not specified, TLS is applied by default.
Secrets Manager CLI version 1 

You can use the IBM Cloud® Secrets Manager command-line interface (CLI) to manage secrets in your Secrets Manager instance.

Current version: 0.1.25



 Prerequisites 



* Install the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).
* Install the Secrets Manager CLI by running the following command:

ibmcloud plugin install secrets-manager -v 0.1.25

You're notified on the command line when updates to the IBM Cloud CLI and plug-ins are available. Be sure to keep your CLI up to date so that you can use the latest commands. You can view the current version of all installed plug-ins by running ibmcloud plugin list.
* Export an environment variable with your Secrets Manager service endpoint URL.

To target an instance for operations, export the following variable.

export SECRETS_MANAGER_URL=https://{instance_ID}.{region}.secrets-manager.appdomain.cloud

Replace {instance_ID} and {region} with the values that apply to your Secrets Manager service instance. To find the endpoint URL that is specific to your instance, you can copy it from the Endpoints page in the Secrets Manager UI. For more information, see [Viewing your endpoint URLs](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-endpointsview-endpoint-urls)

Need to override the URL? You can also specify the endpoint at the command-level by using the --service-url INSTANCE flag. For example, ibmcloud secrets-manager secrets --service-url https://{instance_ID}.{region}.secrets-manager.appdomain.cloud.







 Secret groups 

Control who on your team has access to secrets by creating and managing groups.



 ibmcloud secrets-manager secret-group-create 

Create a secret group that you can use to organize secrets and control who on your team has access to them.
With Secrets Manager, you can use secret groups to control who has access to the secrets in your cluster. A secret group can be assigned to an IAM access group so that only select users or service IDs can access the secrets within the secret group. For more information, see [Organizing your secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups&interface=ui).





 Registering a Secrets Manager instance when creating a cluster 

If you are [creating a new Classic or VPC cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=cli), you can register an existing Secrets Manager instance and secret group to the cluster during creation. Secrets in the cluster are stored in the Secrets Manager instance and applied to the secret group.

The Secrets Manager instance registered during cluster create does not automatically become the default Secrets Manager instance. You must still [set the default instance](https://cloud.ibm.com/docs/openshift?topic=openshift-secrets-mgrsecrets-mgr_setup_default) manually.

If you [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=cli) in the CLI with the [ibmcloud oc cluster create classic](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clics_cluster_create) or [ibmcloud oc cluster create vpc-gen2](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clicli_cluster-create-vpc-gen2), you can specify a Secrets Manager instance or secret group with the following command options:



* --sm-instance: Use this option to register a Secrets Manager instance to the cluster by specifying the instance CRN. To find the CRN of a Secrets Manager instance, run ibmcloud resource service-instance <name_of_instance> or navigate to your resource list in the UI and click on the instance.
With Secrets Manager, you can use secret groups to control who has access to the secrets in your cluster. A secret group can be assigned to an IAM access group so that only select users or service IDs can access the secrets within the secret group. For more information, see [Organizing your secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-secret-groups&interface=ui).





 Registering a Secrets Manager instance when creating a cluster 

If you are [creating a new Classic or VPC cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=cli), you can register an existing Secrets Manager instance and secret group to the cluster during creation. Secrets in the cluster are stored in the Secrets Manager instance and applied to the secret group.

The Secrets Manager instance registered during cluster create does not automatically become the default Secrets Manager instance. You must still [set the default instance](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgrsecrets-mgr_setup_default) manually.

If you [create a cluster](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=cli) in the CLI with the [ibmcloud ks cluster create classic](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clics_cluster_create) or [ibmcloud ks cluster create vpc-gen2](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli&interface=clicli_cluster-create-vpc-gen2), you can specify a Secrets Manager instance or secret group with the following command options:



* --sm-instance: Use this option to register a Secrets Manager instance to the cluster by specifying the instance CRN. To find the CRN of a Secrets Manager instance, run ibmcloud resource service-instance <name_of_instance> or navigate to your resource list in the UI and click on the instance.
For now, [use an API key or secret to authorize a project to deploy an architecture](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-authorize-project). For more information, see [Known issues and limitations for projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-known-issuesauth-known-issue).

You can deploy an architecture in your own account or in another account by using trusted profiles. Depending on your organization, deploying an architecture might require access to another account by using a trusted profile and coordinating with administrators in multiple accounts. If the IBM Cloud Projects service in another account needs access to your account to deploy an architecture, use trusted profiles and service IDs to authorize deployments in your account. For more information about creating a trusted profile for your project, see [Using trusted profiles to authorize a project to deploy an architecture](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-tp-project).





 Using IBM Cloud® Secrets Manager 

When deploying Infrastructure as Code (IaC), there are often secrets that are required to configure the infrastructure, like API keys, SSH keys, and SSL certificates. In these cases, it's recommended to store these secrets within a [Secrets Manager](https://cloud.ibm.com/catalog/services/secrets-managerabout) instance. Storing secrets directly in the configuration of a project is not recommended as they are exposed to any user with access to the project. Projects directly support referencing API keys that are stored in Secrets Manager as an input to a deployable architecture.

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

There are a few different secret types that you can create. Use an arbitrary secret instance to store API Keys for your project.
To work with Secrets Manager and Event Notifications, you need to create instances of both services in your IBM Cloud account.

Already have instances of both services in your account? Verify that you have Manager service access or higher on both services so that you can update settings in your instances.



1. Log in to the IBM Cloud console.
2. Go to the [IBM Cloud catalog](https://cloud.ibm.com/catalog).
3. [Create a Secrets Manager service instance](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-create-instance).
4. [Create an Event Notifications service instance](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-create-en-instance).







 Step 2: Connect your Secrets Manager and Event Notifications instances 

Start by connecting your Event Notifications and Secrets Manager instances to enable lifecycle notifications for Secrets Manager. You can use the Settings > Event Notifications section in the Secrets Manager UI to connect the services.

Zoom

![The image shows the Event Notifications screen in the Secrets Manager UI.](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/secrets-manager/images/event-notifications.svg)

Figure 1. Connecting to Event Notifications





 Step 3: Create a test webhook URL 

Now that your services are connected, you can prepare a workflow for your generated notifications.

Before you can forward alerts to GitHub and Slack, you need a delivery channel that can receive and process your incoming notification data. Event Notifications supports delivery to webhooks. With a webhook, you can build simple workflows that help you to receive and process HTTP requests between different sets of APIs. For example, a webhook can receive the contents of a Secrets Manager event notification, which you can then consume programmatically and pass to the GitHub and Slack APIs.