vania-janet/multiturn-rag-retrieval-data huggingface dataset:
When the invited user makes the [API request](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-byok-cross-acct-key-filebyok-cross-key-acct-create-API) to create the encrypted file share in their own account, they can specify the CRN of the root key of the first account in the encryption_key property.





 Restrictions 

You must use the API to see the encryption keys that are used between accounts, and to create the IAM policy. You can use the UI to access your accounts and see the [IAM authorization](https://cloud.ibm.com/docs/account?topic=account-serviceauthserviceauth). However, the UI does not show the encryption keys that belong to another account even if they are used across accounts. Users of the account that owns the root keys can use the UI to verify the resources that are associated with their encryption keys.

The cross-account authorization is one-way and specific to key and service. When Account A authorizes their key to be used by Account B's file service, Account B can use Account A's CRK to encrypt Account B's shares. However, Account A cannot use Account B's root keys to encrypt Account A's shares.

For Account A to use Account B's CRK to encrypt shares, Account B must invite Account A's user. Then, Account B must create an IAM policy that allows Account A's specific service to use Account B's CRK.





 Create an IAM policy to establish authorization between accounts 

Before file share can be created and encrypted with a root key from another account, the key-owner account must create an IAM policy to authorize the second account to use the CRK.

To create the IAM policy, Account A must make a POST /policies call to the IAM API. In the following example,



* Account A, which owns the CRK, grants AuthorizationDelegator and Reader roles to Account B's file service that is to create the encrypted file share.
With the service, you can control user access to manage keys by [assigning different IAM roles](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessmanage-access-roles). For example, you can grant read-only access to users who need to view key creation information without viewing the key material. Similarly, users can be assigned the "Manager" role over only a single key, if needed. 
 You want to perform envelope encryption as you move data into the cloud. You need to bring your own master encryption keys, so you can manage and protect other keys that encrypt your data at rest. With Key Protect, you can [wrap (encrypt) your data encryption keys with a highly secure root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption) and also unwrap that key when needed. You can bring your own root keys or create them in the service. 



Key Protect is a cloud-based key management system that provides the best of cost, security, and scale. If you are looking for a dedicated key management solution that supports customer-controlled, cloud-based HSMs [IBM Cloud Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) integrates with Key Protect to enable Keep Your Own Keys (KYOK) for IBM Cloud, so your organization has more control and authority over its data. Check out the [Hyper Protect Crypto Services offering details page](https://cloud.ibm.com/catalog/services/hyper-protect-crypto-services) to learn more.





 How Key Protect works 

IBM Key Protect helps you manage encryption keys throughout your organization by aligning with IBM Cloud IAM roles.

An IT or security admin might need advanced permissions to your instance, keys, or key rings that other users, including auditors, might not. For this reason, Key Protect maps to established IAM roles to allow fine-grained access for each user as needed.
Customer workload connectivity to public takes place through NSX-T edge routers that are managed by the customer through a restricted VMware Cloud Director interface. Customer workload connectivity to private takes place through IBM-managed NSX-T edge routers that are configured to limit connectivity to well-known IBM Cloud private services. 





 Data protection 

Client metadata is associated with the VMware as a Service instances that the client creates. When the instance is deleted by the client, the metadata is maintained in the database where the instance state is set to Deleted. Client metadata is maintained in the database unless the client requests that the data is removed through an IBM Support ticket.

Client metadata is stored in IBM Cloud databases (ICD) that encrypts all data both in transit and at rest.

The credentials that are used to access the underlay IaaS and VMware components are also stored in the database. They are stored with a second layer of envelope encryption in addition to the DB encryption by using [IBM Cloud Key Protect](https://cloud.ibm.com/catalog/services/key-protect) Root Key with wrapped Data Encryption Key (DEK). The unwrapped DEK is to encrypt and decrypt the final data.

Envelope encryption uses a unique Key Protect instance per region with unique root key and DEK per microservice in the VMware as a Service solution across all customer instances.





 Data and data protection for client-owned data 

Client-owned data is hosted only in the user's workload domain instance data plane.

Data at rest is stored either on network attached storage or on dedicated disks that are associated with managed bare metal servers. IBM provides storage policies for these data stores that offer vSphere encryption and customers can choose to apply these policies to their workloads so that VMs are protected by vSphere encryption.

The use of vSphere encryption is not enforced by IBM because it is not desirable in every instance. There are unique scenarios for each customer deployment and it's a customer selectable option to enable disk encryption for workloads.

VMs encrypted by vSphere encryption are protected by an IBM-owned Key Protect instance with unique Key Protect instance, unique root key, and unique data encryption key per instance.
[After you designate a root key in Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys) and [grant access between your services](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-servicesgrant-access), you can enable envelope encryption for a specified storage bucket by using the IBM Cloud Object Storage GUI.

To enable encryption with your custom key by using the Key Protect service, [create a root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys) and create an [authorization](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-servicesgrant-access) between your COS instance and the Key Protect instance. Notice that the COS bucket and the Key Protect instance need to be available in the same region.





 Naming 

If you add PII information in the name of a bucket, you might be disclosing sensitive data to others in the same account.

When you define your bucket name, do not add sensitive information in the name or in the description.





 IAM resources to configure archiving 

To configure archiving, you need the following IAM policies:



* An IAM policy with minimum platform role Viewer and service role Manager for the IBM Cloud Activity Tracker service: This policy is required to access the UI, and configure archiving of the auditing instance.
* An IAM policy with minimum platform role Administrator and service role Manager for the COS service: The administrator role is required to define the service ID, with its associated API key, that is used by the IBM Cloud Activity Tracker instance to authenticate and access the IBM Cloud Object Storage instance. The manager role is required to create and configure a bucket.



You also need a service ID. A service ID identifies a service similar to how a user ID identifies a user. Service IDs are not tied to a specific user. If the user that creates the service ID leaves your organization and is deleted from the account, the service ID remains.
Information security 

IBM is committed to providing our clients and partners with innovative data privacy, security, and governance solutions.

IBM Cloud

IBM Cloud only

This information applies only to managed deployments.

Notice: Clients are responsible for ensuring their own compliance with various laws and regulations, including the European Union General Data Protection Regulation. Clients are solely responsible for obtaining advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulations that may affect the clients' business and any actions the clients may need to take to comply with such laws and regulations.

The products, services, and other capabilities that are described herein are not suitable for all client situations and might have restricted availability. IBM does not provide legal, accounting, or auditing advice or represent or warrant that its services or products ensure that clients are in compliance with any law or regulation.

If you need to request GDPR support for IBM Cloud® Watson resources that are created, see [GDPR Subject Access Request](https://cloud.ibm.com/docs/watson?topic=watson-gdpr-sar).



 European Union General Data Protection Regulation (GDPR) 

IBM is committed to providing our clients and partners with innovative data privacy, security, and governance solutions to assist them on their journey to GDPR compliance.

Learn more about IBM's own GDPR readiness journey and our GDPR capabilities and offerings to support your compliance journey [here](https://www.ibm.com/data-responsibility/gdpr/).





 Labeling and deleting data in Discovery 

Discovery includes an API to label data per call. For more information about how to label data by using either the API or from the Discovery product user interface, see [Labeling data](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-information-securitylabeling).

Customer data can be deleted by using the API. For more information about deleting customer data, see [Deleting labeled data](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-information-securitydeletingdata).
You certainly can, and it is probably advisable to run the same (or at least similar) code in order to eliminate corner cases that might emerge if substantially different code is being run against the same data.

However, consider a scenario in which the various organizations on a channel are all executing transactions against a set of data but have substantially different roles. In this scenario:



* Org A: an individual who wants to place an advertisement.
* Org B: the owner of the place where advertisements are posted.



Org A should, logically, be allowed to request an ad be placed, and also to query ads. Since their identity would lack the proper permissions to create an ad, why should the smart contract they install on their peer contain the relevant code for creating an ad? It’s just unnecessary waste and clutter.

Similarly, Org B would logically be able to query ads and to create them. But they would have no use for the ability to request an ad be placed since they already have the ability to create them.

A hypothetical third Org might only need the ability to verify information without actually needing the ability to query or create information of its own, a popular use case for government entities or other kinds of regulators.

While the desire to reduce unnecessary code clutter is always worthwhile on its own, this ability for different organizations to have different smart contracts is particularly useful in scenarios when the code to perform certain actions might contain sensitive information (the location of a server where ads are created, for example).

While the “old” lifecycle did include ways to separate roles through a permissions structure, the ability for different orgs to have different packages is a more secure and holistic approach to the separation of concerns central to blockchain networks, and should be taken in account when developing smart contracts to run using the new lifecycle.

In any case, it is a best practice for smart contracts to be tested extensively (preferably on a test channel dedicated to this purpose) to ensure that all smart contract packages produce the same result, regardless of the underlying code generating that result. However, keep in mind that as long as an errant result is not reached by enough peers to satisfy the endorsement policy of a smart contract, the integrity of ledger data will be maintained.
After the network access policy is set to private-only, you cannot access your instance from the public network and cannot view or manage keys with the IBM Cloud console. However, you can still adjust the network setting later using the API or CLI. 



A successful request returns an HTTP 204 No Content response, which indicates that your Hyper Protect Crypto Services instance now enforces a network access policy. API requests to the service are restricted to the policy that you set.

This policy applies to Hyper Protect Crypto Services instances only. The network access policy does not apply to specific keys.
3. Optional: Verify that the network access policy is created by browsing the policies that are available for your Hyper Protect Crypto Services instance.

$ curl -X GET "https://api.<region>.hs-crypto.cloud.ibm.com/api/v2/instance/policies?policy=allowedNetwork"   -H "accept: application/vnd.ibm.kms.policy+json"   -H "authorization: Bearer <IAM_token>"   -H "bluemix-instance: <instance_ID>"







 Updating the network access policy for your Hyper Protect Crypto Services instance with the CLI 

You can also update the network access policy for your Hyper Protect Crypto Services instance using the CLI. For more information, see [the CLI reference](https://cloud.ibm.com/docs/key-protect?topic=key-protect-cli-plugin-key-protect-cli-referencekp-instance-policy-update-allowed).





 Disabling the network access policy for your Hyper Protect Crypto Services instance with the key management service API 

As a security administrator, disable a network access policy for a Hyper Protect Crypto Services instance by making a PUT call to the following endpoint. See these API references to [set](https://cloud.ibm.com/apidocs/hs-cryptoputinstancepolicy) and [list](https://cloud.ibm.com/apidocs/hs-cryptogetinstancepolicy) instance policies.
* [list_objects_v2](https://ibm.github.io/ibm-cos-sdk-python/reference/services/s3.htmlS3.Client.list_objects_v2)











 Using Key Protect 

Key Protect can be added to a storage bucket to encrypt sensitive data at rest in the cloud.



 Before You Begin 

The following items are necessary in order to create a bucket with Key-Protect enabled:



* A Key Protect service [provisioned](https://cloud.ibm.com/docs/key-protect?topic=key-protect-provision)
* A Root key available (either [generated](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys) or [imported](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-root-keys))







 Retrieving the Root Key CRN 



1. Retrieve the [instance ID](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-instance-ID) for your Key Protect service
2. Use the [Key Protect API](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-up-api) to retrieve all your [available keys](https://cloud.ibm.com/apidocs/key-protect)



* You can either use curl commands or an API REST Client such as [Postman](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-postman) to access the [Key Protect API](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-up-api).



3. Retrieve the CRN of the root key you use to enabled Key Protect on your bucket. The CRN looks similar to below:
* UI
* API







 Viewing a list of keys 

IBM® Key Protect for IBM Cloud® provides a centralized system to view, manage, and audit your encryption keys. Audit your keys and access restrictions to keys to ensure the security of your resources.

While you can [assign fine-grained access to a single key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-grant-access-keysgrant-access-key-level), note that calling the [list keys API](https://cloud.ibm.com/apidocs/key-protectgetkeys) will not return keys that you have assigned individual access to (that only you can access, in other words). Calling this API will however return the keys in key rings you have access to (if you have access to all of the keys in an instance, you will see all keys). You can, however, see the keys that only you have access to by following the instructions in [Viewing fine-grain access keys through IAM](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keysfilter-key-state-gui-iams) to view the key through IAM or by using the API to pass the specific key ID.

It is a good practice to audit your key configuration regularly:



* Examine when keys were created and determine whether it's time to rotate the key.
* [Monitor API calls to Key Protect with Activity Tracker](https://cloud.ibm.com/docs/key-protect?topic=key-protect-at-events).
* Inspect which users have access to keys and if the level of access is appropriate.



For more information about auditing access to your resources, see [Managing user access](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-access).



 Viewing keys in the console 

If you prefer to inspect the keys in your service by using a graphical interface, you can use the Key Protect dashboard.
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? 

Review your options to remove your information from IBM Cloud Kubernetes Service.

Removing personal and sensitive information is permanent and not reversible. Make sure that you want to permanently remove your information before you proceed.

Is my data removed when I remove the cluster?
: Deleting a cluster does not remove all information from IBM Cloud Kubernetes Service. When you delete a cluster, cluster-specific information is removed from the etcd instance that is managed by IBM. However, your information still exists in the IBM Cloud Object Storage backup and can still be accessed by the IBM service team by using the account-specific customer root key in IBM Key Protect that IBM owns and manages.

What options do I have to permanently remove my data?
: To remove that data that IBM stores, choose between the following options. Note that removing your personal and sensitive information requires all your clusters to be deleted as well. Make sure that you backed up your app data before your proceed.



* Open an IBM Cloud support case: Contact IBM Support to remove your personal and sensitive information from IBM Cloud Kubernetes Service. For more information, see [Getting support](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar).
* End your IBM Cloud subscription: After you end your IBM Cloud subscription, IBM Cloud Kubernetes Service removes the customer root key in IBM Key Protect that IBM created and managed for you as well as all the personal and sensitive information from the etcd data store and Object Storage backup.
[After you designate a root key in Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys) and [grant access between your services](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-servicesgrant-access), you can enable envelope encryption for a specified storage bucket by using the IBM Cloud Object Storage GUI.

To enable encryption with your custom key by using the Key Protect service, [create a root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys) and create an [authorization](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-servicesgrant-access) between your COS instance and the Key Protect instance. Notice that the COS bucket and the Key Protect instance need to be available in the same region.





 Naming 

If you add PII information in the name of a bucket, you might be disclosing sensitive data to others in the same account.

When you define your bucket name, do not add sensitive information in the name or in the description.





 IAM resources to configure archiving 

To configure archiving, you need the following IAM policies:



* An IAM policy with minimum platform role Viewer and service role Manager for the IBM Log Analysis service: This policy is required to access the logging web UI, and configure archiving of the logging instance.
* An IAM policy with minimum platform role Administrator and service role Manager for the COS service: The administrator role is required to define the service ID, with its associated API key, that is used by the IBM Log Analysis instance to authenticate and access the IBM Cloud Object Storage instance. The manager role is required to create and configure a bucket.



You also need a service ID. A service ID identifies a service similar to how a user ID identifies a user. Service IDs are not tied to a specific user. If the user that creates the service ID leaves your organization and is deleted from the account, the service ID remains.
With that, access to the sample Key Protect instance might only be allowed from, e.g., a specific Object Storage instance, a well-known range of IP addresses, and only via the private endpoint.

Network zones can be used for the definition of multiple rules. Rules have an enforcement mode which is one of disabled, report-only, or enabled.

At the moment, not all cloud services support the report-only mode. Moreover, these service also do not generate any CBR-related log entries when enabled. Check the individual service documentation for details.

Zoom

![Context-based restrictions](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution67-cbr-enhanced-security/CBR-diagram.svg)

A diagram that shows how context-based restrictions work





 Step 3: Create zone and rule 

For evaluating the impact of context-based restrictions, you are going to create a rule governing the access to a namespace in Container Registry. You start by creating that namespace, then a network zone to identify a VPC as traffic source.



1. Go to the [Container Registry namespaces](https://cloud.ibm.com/registry/namespaces) and select the region you want to work with. Click Create and enter YOUR_INITIALS-e2esec as Name. Use your initials or something else to make sure the namespace is unique within the region. Last, Create the new namespace.
2. In the [IBM Cloud](https://cloud.ibm.com/) console, click on the Manage menu and select [Context-based restrictions](https://cloud.ibm.com/context-based-restrictions). In the overview page, click on Create a network zone.
3. Enter VPCzone as name. Under Allowed VPCs, select the one with your Kubernetes Service cluster. Click Next to review, then Create the zone.
4.