vania-janet/multiturn-rag-retrieval-data huggingface dataset:
But when it comes to enterprise applications, avoid registries that you don't know or don't trust to protect your cluster from malicious images. Keep your images in a private registry, like the one provided in IBM Cloud Container Registry and make sure to control access to the registry and the image content that can be pushed.

Why is it important to check images against vulnerabilities?
: Research shows that most malicious attacks leverage known software vulnerabilities and weak system configurations. When you deploy a container from an image, the container spins up with the OS and extra binaries that you described in the image. Just like you protect your virtual or physical machine, you must eliminate known vulnerabilities in the OS and binaries that you use inside the container to protect your app from being accessed by unauthorized users.

To protect your apps, consider to address the following areas:



1. Automate the build process and limit permissions: Automate the process to build your container image from your source code to eliminate source code variations and defects. By integrating the build process into your CI/CD pipeline, you can ensure that your image is scanned and built only if the image passes the security checks that you specified. To avoid that developers apply hot fixes to sensitive images, limit the number of people in your organization who have access to the build process.
2. Scan images before they deploy into production: Make sure to scan every image before you deploy a container from it. For example, if you use IBM Cloud Container Registry, all images are automatically scanned for vulnerabilities when you push the image to your namespace. If vulnerabilities are found, consider eliminating the vulnerabilities or block deployment for those images. Find a person or team in your organization who is responsible for monitoring and removing vulnerabilities. Depending on your organizational structure, this person might be part of a security, operations, or deployment team. Enable [content trust](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent) so that images must be approved by a trusted signer before they can be pushed to the container registry.
Instead, organizations can describe the interface characteristics between those interconnecting systems in their respective security plans. If interconnecting systems have different authorizing officials within the same organization, organizations can either develop Interconnection Security Agreements or describe the interface characteristics between systems in the security plans for the respective systems. Organizations may also incorporate Interconnection Security Agreement information into formal contracts, especially for interconnections established between federal agencies and nonfederal (i.e., private sector) organizations. Risk considerations also include information systems sharing the same networks. For certain technologies (e.g., space, unmanned aerial vehicles, and medical devices), there may be specialized connections in place during preoperational testing. Such connections may require Interconnection Security Agreements and be subject to additional security controls.
* [What compliance standards does the service meet?](https://cloud.ibm.com/docs/satellite?topic=satellite-compliancecompliance-standards)
* [Which areas of security compliance am I responsible for?](https://cloud.ibm.com/docs/satellite?topic=satellite-compliancecompliance-responsibilities)
* [What are the security compliance responsibilities of Satellite-enabled IBM Cloud services?](https://cloud.ibm.com/docs/satellite?topic=satellite-compliancecompliance-services)





[Securing your connection](https://cloud.ibm.com/docs/satellite?topic=satellite-service-connectionservice-connection)



* [Access to resources that run in your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-service-connectionuser-access)



* [Service-instance clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-service-connectionuser-access-service)
* [IBM private network access with Satellite Link](https://cloud.ibm.com/docs/satellite?topic=satellite-service-connectionuser-access-loc-ep)
* [Application workloads that run in clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-service-connectionuser-access-apps)



* [IBM Cloud access to your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-service-connectionibm-cloud-access)



[Securing your data](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitydata-security)



* [What information is stored with IBM when using Satellite?](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat-sensitive-data)



* [Stored information when you create a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat-sensitive-data-default)
"encryptedNonce": "<encrypted_nonce>",
"iv": "<iv>"
}'

Replace the variables in the example request according to the following table.





Table 3. Describes the variables that are needed to rotate a key that has an import token.

 Variable Description 

 region Required. The region abbreviation, such as us-south or eu-gb, that represents the geographic area where your Key Protect instance residesS. <br> <br>For more information, see [Regional service endpoints](https://cloud.ibm.com/docs/key-protect?topic=key-protect-regionsservice-endpoints). 
 keyID_or_alias Required. The unique identifier or alias for the key that you want to rotate. 
 IAM_token Required. Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the curl request. <br> <br>For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Key Protect service instance. <br> <br>For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-instance-ID). 
 key_alias Required. A unique, human-readable name for easy identification of your key. To protect your privacy, do not store your personal data as metadata for your key. 
 key_description Optional.An extended description of your key. To protect your privacy, do not store your personal data as metadata for your key. 
 encrypted_key Required. The encrypted key material that you want to store and manage in the service. The value must be base64 encoded.
NIST supplemental guidance 

Information is represented internally within information systems using abstractions known as data structures. Internal data structures can represent different types of entities, both active and passive. Active entities, also known as subjects, are typically associated with individuals, devices, or processes acting on behalf of individuals. Passive entities, also known as objects, are typically associated with data structures such as records, buffers, tables, files, inter-process pipes, and communications ports. Security attributes, a form of metadata, are abstractions representing the basic properties or characteristics of active and passive entities with respect to safeguarding information. These attributes may be associated with active entities (i.e., subjects) that have the potential to send or receive information, to cause information to flow among objects, or to change the information system state. These attributes may also be associated with passive entities (i.e., objects) that contain or receive information. The association of security attributes to subjects and objects is referred to as binding and is typically inclusive of setting the attribute value and the attribute type. Security attributes when bound to data/information, enables the enforcement of information security policies for access control and information flow control, either through organizational processes or information system functions or mechanisms. The content or assigned values of security attributes can directly affect the ability of individuals to access organizational information. Organizations can define the types of attributes needed for selected information systems to support missions/business functions. There is potentially a wide range of values that can be assigned to any given security attribute. Release markings could include, for example, US only, NATO, or NOFORN (not releasable to foreign nationals). By specifying permitted attribute ranges and values, organizations can ensure that the security attribute values are meaningful and relevant. The term security labeling refers to the association of security attributes with subjects and objects represented by internal data structures within organizational information systems, to enable information system-based enforcement of information security policies. Security labels include, for example, access authorizations, data life cycle protection (i.e., encryption and data expiration), nationality, affiliation as contractor, and classification of information in accordance with legal and compliance requirements. The term security marking refers to the association of security attributes with objects in a human-readable form, to enable organizational process-based enforcement of information security policies.
Plan ahead for encrypting your key material 

If you choose to encrypt your key material by using an import token, determine a method for running RSA encryption on the key material. You must use the RSAES_OAEP_SHA_256 encryption scheme as specified by the

[PKCS #1 v2.1 standard for RSA encryption](https://tools.ietf.org/html/rfc3447).

Review the capabilities of your internal key management system or on-premises HSM to determine your options, or check out the [secure import tutorial](https://cloud.ibm.com/docs/key-protect?topic=key-protect-tutorial-import-keystutorial-import-encrypt-key) for examples.





 Plan ahead for encrypting the nonce 

If you choose to encrypt your key material by using an import token, you must also determine a method for running AES-GCM encryption on the nonce that is distributed by Key Protect.

The nonce serves as a session token that checks the originality of a request to protect against malicious attacks and unauthorized calls.

Review the capabilities of your internal key management system or on-premises HSM to determine your options, or check out the [secure import tutorial](https://cloud.ibm.com/docs/key-protect?topic=key-protect-tutorial-import-keystutorial-import-encrypt-nonce) for examples.





 Manage the lifecycle of imported key material 

After you import key material into the service, keep in mind that you are responsible for managing the complete lifecycle of your key. By using the Key Protect API, you can set an expiration date for the key when you decide to upload it into the service.

However, if you want to [rotate an imported root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-rotate-keys), you must generate and provide new key material to retire and replace the existing key.







 Using import tokens
Rapid response 

Rapid response allows security teams connect to a remote shell within your environment to start troubleshooting and investigating an event by using the commands that they are already accustomed to. Security tools can be run directly from the event alert.

IBM Cloud Security and Compliance Center Workload Protection implements Sysdig Secure functionality. Information that is provided by the Sysdig Secure documentation applies to Workload Protection as well.

For more information, see [Rapid response](https://docs.sysdig.com/en/docs/sysdig-secure/investigate/rapid-response/)
Security 

Learn about the security features provided with IBM MQ on Cloud.



 Default Security Features 

![Image showing security features](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_qm_security.png)



1. MQ channels provide the option to encrypt data in transit from applications and administrators using TLS connections. There is some configuration for the customer to apply to enable the TLS capability
2. A default TLS server certificate is configured for the queue manager signed by a public Certificate Authority such as Let's Encrypt
3. Queue manager channels are configured by default with username/password authentication, which is backed by the IBM Cloud® Identity and Access Management (IAM) service for user and application management
4. All persisted queue manager data including messages, configuration and logs, is encrypted at rest using full disk encryption on storage volumes.
5. IBM MQ provides extensive features for providing fine grained access control to specific resources such as queues/topics within the queue manager, which can be leveraged in the same way as for on-premises customer deployments







 Default MQ Security Configuration 



 Users 

To provide administrative access to queue managers in a service instance, a user must be added to the "User permissions" list by following the steps provided [here](https://cloud.ibm.com/docs/mqcloud?topic=mqcloud-tutorial-configure-admin-access).

Any user with administrative access has the capability to view and modify any MQ configuration and to write and access message data. For these reasons, administrative access should be limited wherever possible.

By giving a user permissions they become a member of the mqm group for each queue manager in that service instance.

By default MQ "BLOCKUSER" rules are defined so members of mqm group can only connect to the queue manager using the CLOUD.ADMIN.SVRCONN channel.
* How can I secure a workspace by setting an environment variable?

Currently, the IBM Cloud Schematics service team is working to enable secure environment variables and support for passing credentials for modules. It is planned in the future roadmap. However, here is a sample code block to secure a workspace.


Example input file get workspace:
"env_values": [{
"name": "GIT_ASKPASS",
"value": "./git-askpass-helper.sh",
"secure": false,
"hidden": false
},
{
"name": "GIT_PASSWORD",
"value": "plain text token",
"secure": false,
"hidden": false
}
]

* How can I create ibm_function_trigger with Terraform that connects to an Event Stream?

The sample code block allows to create the resources of the same type in a sequential order. For more information, about creating a trigger that listens to an Event Streams instance block, see [Event Streams_trigger](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-pkg_event_streamseventstreams_trigger).

 {: codeblock}
resource "ibm_function_trigger" "trigger" {
name = "event - trigger"
namespace = "ns01"
user_defined_annotations = jsonencode([])
user_defined_parameters = jsonencode([])
feed {
name = "/whisk.system/messaging / messageHubFeed"
parameters = jsonencode([])
}
}

* How do I associate a public gateway while creating multiple zones with a Subnet for each zone?


{

"StatusCode": 400,
"Headers": {

"Cache-Control": ["max-age=0, no-cache, no-store, must-revalidate"],
"Cf-Cache-Status": ["DYNAMIC"],
Data security and compliance 

App Configuration service has data security strategies in place to meet your compliance needs and ensure that your data remains secure and protected in the cloud.



  Security readiness 

App Configuration ensures security readiness by adhering to IBM best practices for systems, networking, and secure engineering.

To learn more about security controls across IBM Cloud, see [How do I know that my data is safe?](https://cloud.ibm.com/docs/overview?topic=overview-securitysecurity).

To learn more about how your data is secured in App Configuration, see [securing your data in App Configuration](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-securing-your-data).



  Data encryption 

Access to App Configuration takes place over HTTPS and uses Transport Layer Security (TLS) to encrypt data in transit.

For more information on supported TLS ciphers, see [TLS cipher support](https://cloud.ibm.com/docs/app-configuration?topic=app-configuration-ac-cipher-support).

If you attempt to use a cipher that is not on this list, you may experience connectivity issues. Update your client to use one of the supported ciphers. If you are using openssl, you can use the command openssl ciphers -v at the command line (or, for some installations of openssl, use the -s -v options) to show a verbose list of what ciphers your client supports.







  Compliance readiness 

App Configuration meets controls for global, industry, and regional compliance standards, including ISO 27001/27017/27018/27701, and others.

For a complete listing of IBM Cloud compliance certifications, see [Compliance on the IBM Cloud](https://ibm.com/cloud/compliance).



  ISO 27001, 27017, 27018, 27701 

App Configuration is ISO 27001, 27017, 27018, and 27701 certified. You can view compliance certifications by visiting [Compliance on the IBM Cloud](https://ibm.com/cloud/compliance).







  Secrets management 

By integrating App Configuration with Secrets Manager, you can store your secrets securely in Secrets Manager and use the secrets in your application through App Configuration. App Configuration stores metadata of Secrets Manager instance instead of storing the secrets. This metadata is called as a secret reference as part of the Properties type in App Configuration.
Based on the anomalies found in the data, you can configure the policies and actions for user-defined conditions. These actions might include selecting the job type, configuring Boolean conditions for the Anomaly score, and defining the action when the condition is true. For example,



* Job: "Caveo Logs" Anomaly score is > 90 then Mark asset for quarantine and send notification to slack Channel.
* Job: "Caveo Network" Anomaly score is > 95 then quarantine the asset and send email notification and also send UI notification.





* Dashboards - The dashboards, through role-based access, provide the ability for a service provider, such as an IT department, to allocate IT assets to tenants or business units. Business units then assign these IT assets to applications. These applications match business and IT services, are subject to a Business Impact Assessment, and subject to a compliance regime such as: NIST, NESA, PCI, ISO, and HIPAA. These applications are then subject to a number of scans such as vulnerability, NSX flows, software, and log data. These scans allow visibility into what is running, and the cyberrisk and compliance risk associated with the applications. Drilling down through these dashboards, compliance and security users, can see a prioritized list of actions to mitigate and enable automatable enforcement actions in the Predict and Act modules. RiskForesight provides both a unified dashboard to identify assets in the hybrid cloud and a heat map analysis for cyberrisks, compliance configuration risks, key trends, and metrics of security operation. It enables users to quickly determine the nature and location of risks and what actions to take that use an intuitive and powerful visualization tool.



These dashboards provide the following functions.



* A prioritized view of cyberrisk and compliance risks across hybrid cloud with Detect, Predict, Act dashboard views.
* The ability for a user to visually interact with data to quickly identify assets at risk, based on risk priorities.
* Easy-to-use graphs, metrics, and filters to develop insight into the identified risks.
* Interactive drill downs for greater depth of information on application data flows, vulnerabilities or configuration issues across locations, organizations, applications, and assets.
Sensitive information <br><br> * The TLS certificate and secret that is used for the assigned Ingress subdomain.<br> * The certificate authority that is used for the TLS certificate.<br> * The certificate authority, private keys, and TLS certificates for the Kubernetes master components, including the Kubernetes API server, etcd data store, and VPN.<br> * A customer root key in IBM Key Protect for each IBM Cloud account that is used to encrypt personal and sensitive information.<br><br><br> 







 How is my information stored and encrypted? 

All information is stored in an etcd database and backed up every 8 hours to IBM Cloud Object Storage. The etcd database and Object Storage service instance are owned and managed by the IBM Cloud SRE team. For each IBM Cloud account, a customer root key in IBM Key Protect is created that is managed by the IBM Cloud Kubernetes Service service team. This root key is used to encrypt all personal and sensitive information in etcd and in Object Storage.





 Where is my information stored? 

The location where your information is stored depends on the location your cluster is in. By default, your data is stored in the IBM Cloud Kubernetes Service multizone metro area that is closest to your cluster. However, IBM Cloud Kubernetes Service might decide to store your data in a different multizone metro area to optimize the utilization of available compute resources. If you create your cluster in a non-multizone metro area, your data is still stored in the closest multizone metro area. This location might be in a different country than the one where you created your cluster. Make sure that your information can reside in a different country before you create your cluster in a non-multizone metro area.

The data that you create and own is always stored in the same location as the cluster. For more information about what data you can create in your cluster, how this data is encrypted, and how you can protect this data, see [Protecting sensitive information in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-encryption).





 How can I remove my information?
A unique, human-readable name for easy identification of your key. To protect your privacy, do not store your personal data as metadata for your key. 
 key_description Optional.An extended description of your key. To protect your privacy, do not store your personal data as metadata for your key. 
 encrypted_key Required. The encrypted key material that you want to store and manage in the service. The value must be base64 encoded. Ensure that the key material meets the following requirements: <br> <br>The key must be 128, 192, or 256 bits.The bytes of data, for example 32 bytes for 256 bits, must be encoded by using base64 encoding. 
 key_type OptionalA boolean value that determines whether the key material can leave the service. <br> <br>When you set the extractable attribute to false, the service designates the key as a root key that you can use for wrap or unwrap operations. 
 encrypted_nonce Required. The AES-GCM encrypted nonce that ensures that the bits you send as part of a request are exactly the same as what we receive. The nonce validates the key that you are restoring. <br> <br>To learn more, see [Tutorial: Creating and importing encryption keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-tutorial-import-keystutorial-import-encrypt-nonce). 
 iv Required. The initialization vector (IV) that is generated by the AES-GCM algorithm when you encrypt a nonce. This value is used to decode the key for storage in the Key Protect system. <br> <br>To learn more, see [Tutorial: Creating and importing encryption keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-tutorial-import-keystutorial-import-encrypt-nonce). 



A successful rotation request returns an HTTP 204 No Content response, which indicates that your root key was replaced by new key material.





 Optional: Verify import token key rotation