vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Allowable actions for each role change based on the service that is being accessed because each service defines how that role maps to the use of the service. For more information, see [IAM roles and actions](https://cloud.ibm.com/docs/account?topic=account-iam-service-roles-actions).





 Access management system 

The IBM Cloud IAM control system allows or denies actions by users or service IDs within the context of a service based on their assigned access policies. By default, every user and service ID has no access. Each access policy that is added enables the user or service ID to perform an action within the account based on the specified target and role that is selected in the access policy. When a user tries to complete a specific action, the control system uses the attributes that are defined in the policy to determine whether the user has permission to perform that task. For more information, see [How IBM Cloud IAM works](https://cloud.ibm.com/docs/account?topic=account-iamoverview).



 What is ABAC and RBAC? 

There are two common types of IAM systems in cloud providers and understanding each of these models can help you gain a better understanding of how IAM works in IBM Cloud.



* Attribute-based access control (ABAC) uses attributes from identities, such as users and service IDs, environments, and resources. These attributes are used by an access decision engine to determine whether an access request should be permitted or denied. ABAC provides more flexibility, control, and features than role-based access control systems. ABAC is typically used when fine-grained access control is needed, or if a wide variety of access control use cases needs to be solved by the same decision engine. ABAC helps reduce security risks by providing fine-grained access control and is typically more complex, especially during initial setup.
* Role-based access control (RBAC) uses a mapping from an identity, such as a user or service ID, to a role. The RBAC role defines the type of access that an identity with the RBAC role can take against a resource. Typically access can be granted for a resource type or a grouping of resources. RBAC roles are usually defined based on job responsibilities within an organization.
In addition to the [data source requirements](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-sourcespublic-requirements) for all managed deployments, your SharePoint Online data source must meet the following requirements:



* The Site Collection that you connect to must be one that was created with an Enterprise plan. It cannot be a collection that was created with a frontline worker plan.
* You must have an Azure Active Directory user ID with permission to read all of the objects that you want to crawl. For example, <admin_user>@.onmicrosoft.com. The user ID does not need SiteCollection Administrator permission.



You can choose how to authenticate with the external Microsoft SharePoint account from the following options:

Open Authentication (OAuth v2)
: Authenticates with the external data source by using a token so that your user credentials do not need to be shared. With this authentication method, you can log in to your Microsoft account directly to generate a token that is used by Discovery to connect to your data.

The Sign in with Microsoft option that uses Open Authentication v2 to authenticate with the external data source is a beta feature.

Before anyone can create connectors that use this authentication method, a user with the Global Administrator role must complete a one-time [prerequisite steps](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-connector-sharepoint-online-cloudconnector-sharepoint-online-cloud-oauth-prereq) to authorize the connection for all projects in the Discovery service instance.

Security Assertion Markup Language (SAML)
: An older mechanism for authentication and authorization that requires user credentials to be shared with the Discovery service.

If you choose to use this authentication method, your Microsoft SharePoint account must meet the following requirements:



* Unless you created your SharePoint Online account before January 2020, two-factor authentication is enabled for the account by default. You must disable two-factor authentication.
You can override this access at the lower levels by assigning the user to a different role. For example, if you only want the user to have Edit access in a particular space, assign the user to the Reader role for the provider organization, and then assign the user to a role with Edit access on the selected space. The user will still have only Reader access to the catalog owning the space, to all other spaces within the same catalog, and to alwildcard l other catalogs and spaces owned by the provider organization.

At a minimum, each user must be assigned at least Reader role on the Reserved instance and on each provider organization that they are allowed to view. Then you can decide what additional roles each should be be assigned to on the provider organization and to each of the catalogs and spaces within it.

Complete the following tasks to grant members of your IBM Cloud account the appropriate access to resources in your Reserved instance.



 Creating provider organizations 

You can create a single provider organization (for example, in a small company) or create multiple provider organizations (for example, different departments in a large company). Some users might belong to multiple provider organizations, and might receive different levels of access with each.



 Decide how many provider organizations you need 

In API Connect Reserved, all of the members of a provider organization receive the same level of access to API Connect. Review the members of your company's IBM Cloud account and the descriptions of [who does what in API Connect](https://cloud.ibm.com/docs/apiconnect?topic=apiconnect-ri-user-overwhodoeswhat_ri-user-over), and determine how many provider organizations you need to create.





 Create your provider organizations in API Connect 

Use the API Connect administration console to create a provider organization and map it to the new IAM access group.



1. Open the API Connect Reserved instance's administration console.

a. [Log in](https://cloud.ibm.com/login/) to IBM Cloud.

b. On the Dashboard, click !
Configuring a Cloud Object Storage target 

A target is an IBM Cloud resource where you can collect auditing events. Use this tutorial to learn how to configure a Cloud Object Storage target in the account.

This tutorial uses the IBM Cloud® Activity Tracker Event Routing v2 API.



 Scenarios 

You can define a Cloud Object Storage bucket as a target in any of the following situations:



* You need a solution to monitor the activity in your account that must be Financial Services Validated.
* You want to collect and store auditing events in a Cloud Object Storage bucket. You can have the bucket in the account that generates the events or in a different account from the one that generates auditing events.







 Prerequisites 



* Learn about Activity Tracker Event Routing. For more information, see [About](https://cloud.ibm.com/docs/atracker?topic=atracker-atracker-resources).
* Install the IBM Cloud CLI. For more information, see [Installing the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli).
* Install the latest Activity Tracker Event Routing CLI V2 plugin in your local system. See [Installing the Activity Tracker Event Routing CLI](https://cloud.ibm.com/docs/atracker?topic=atracker-atracker-cli-config&interface=cli).
* You need a user ID that is a member, or an owner of, an IBM Cloud account. To get an IBM Cloud user ID, go to: [Create an account](https://cloud.ibm.com/login).
* Every user that manages the Activity Tracker Event Routing configuration in your account must be assigned an access policy. The policy determines what actions the user can perform. The allowable actions are customized and defined by Activity Tracker Event Routing as operations that are allowed to be performed on the service. The actions are then mapped to IAM user roles.
Configuring a logdna target 

A target is an IBM Cloud resource where you can collect auditing events. Use this tutorial to learn how to configure an Activity Tracker Event Routing hosted event search target in the account.

This tutorial uses the IBM Cloud® Activity Tracker Event Routing v2 API.



 Scenarios 

You can define an Activity Tracker event search target in any of the following situations:



* You need a solution to monitor the activity in your account through the UI.
* You want to collect and store auditing events in an Activity Tracker hosted event search instance. You also want to choose the instance or instances where to collect and manage those events.







 Prerequisites 



* You need a user ID that is a member, or an owner of, an IBM Cloud account. To get an IBM Cloud user ID, go to: [Create an account](https://cloud.ibm.com/login).
* Your user ID needs administrator platform permissions to manage the IBM Cloud Activity Tracker service. Contact the account owner. The account owner can grant another user access to the account for the purposes of managing user access, and managing account resources. [Learn more](https://cloud.ibm.com/docs/account?topic=account-userroles).
* Learn about Activity Tracker Event Routing. For more information, see [About](https://cloud.ibm.com/docs/atracker?topic=atracker-atracker-resources).
* Install the IBM Cloud CLI. For more information, see [Installing the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli).
* Install the latest Activity Tracker Event Routing CLI V2 plugin in your local system. See [Installing the Activity Tracker Event Routing CLI](https://cloud.ibm.com/docs/atracker?topic=atracker-atracker-cli-config&interface=cli).







 Step 1: Manage the type of endpoints
* [Create a custom service ID with access permissions for Code Engine service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccessbind-auto-servid-access-custom).
* [Configure your project to use the custom service ID](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccessbind-custom-servid-project).





 Creating a custom service ID with access permissions for Code Engine service bindings 

When you are using a custom service ID, you must give the custom service ID Operator platform access so that this service ID can create the service credentials for service bindings.

For example, suppose you want to create a service binding to bind a Code Engine workload to an IBM Cloudant service instance. Yet, you do not want to give the user Administrator access for all All Identity and Access enabled services within a resource group. However, you want to give the user access to a specific instance of IBM Cloudant.

The following steps describe one way to setup a custom service ID with the required access permissions so that Code Engine can create service bindings for my-user. The account owner for the service instance completes the following steps to create a custom service ID.



1. [Create an IAM resource group](https://cloud.ibm.com/docs/account?topic=account-rgs&interface=uicreate_rgs) for users who create Code Engine service bindings.



1. Launch [Access (IAM) Overview](https://cloud.ibm.com/iam/overview).
2. Select Manage > Account > Resource Groups > Create resource group.
3. Create a resource group; for example, CodeEngine_servicebindings_resourcegroup.



2. Create the service instances that you want to bind to in the same resource group. For this example, create an IBM Cloudant service instance in the CodeEngine_servicebindings_resource group resource group.
3.
The worker-add action succeeds because the user is authorized and the API key is set correctly. You don't need to edit the user's IBM Cloud infrastructure permissions.

To audit the actions that users in your account run, you can use [Activity Tracker](https://cloud.ibm.com/docs/containers?topic=containers-at_events) to view all cluster-related events.





 What if I don't want to assign the API key owner or credentials owner the Super User infrastructure role? 

For compliance, security, or billing reasons, you might not want to give the Super User infrastructure role to the user who sets the API key or whose credentials are set with the ibmcloud ks credential set command. However, if this user doesn't have the Super User role, then infrastructure-related actions, such as creating a cluster or reloading a worker node, can fail. Instead of using IBM Cloud IAM platform access roles to control users' infrastructure access, you must [set specific IBM Cloud infrastructure permissions](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access) for users.





 What happens if the user who set up the API key for a region and resource group leaves the company? 

If the user is leaving your organization, the IBM Cloud account owner can remove that user's permissions. However, before you remove a user's specific access permissions or remove a user from your account completely, you must reset the API key with another user's infrastructure credentials. Otherwise, the other users in the account might lose access to the IBM Cloud infrastructure portal and infrastructure-related commands might fail. For more information, see [Removing user permissions](https://cloud.ibm.com/docs/containers?topic=containers-usersremoving).

Consider using a functional ID user for the API key owner instead of a personal user. In case the person leaves the team, the functional ID user remains the API key owner. Keep in mind that you can't use a service ID to set the API key.





 How can I lock down my cluster if my API key becomes compromised?
Validating tokens 

Token validation is an important part of modern app development. By validating tokens, you can protect your app or APIs from unauthorized users. IBM Cloud® App ID uses access and identity tokens to ensure that a user or app is authenticated before they are granted access. If you're using one of the SDKs provided by App ID, both obtaining and validating your tokens is done for you!

For more information about how tokens are used in App ID, see [Understanding tokens](https://cloud.ibm.com/docs/appid?topic=appid-tokens).

Tokens are used to verify that a person is who they say that they are. They confirm any access permissions that the user might hold, for a specified length of time. When a user signs in to your application and is issued a token, your app must validate the user before they are given access.

What if I'm working in a language that App ID doesn't have an SDK for?

Don't worry! You have three options:



* Work with the App ID APIs
* Implement your own validation logic
* Use any OIDC-compliant open source SDK





 Using the App ID APIs 

By using introspection, you can use App ID to validate your tokens.



1. Send a POST request to the [/introspect](https://us-south.appid.cloud.ibm.com/swagger-ui//Authorization%20Server%20-%20Authorization%20Server%20V4/oauth-server.introspect) API endpoint to validate your token. The request must provide the token and a basic authorization header that contains the client ID and secret.

Example request:

POST /oauth/v4/<tenantID>/introspect HTTP/1.1
Host: us-south.appid.cloud.ibm.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic jdFlUaGlZUzAwTW0Tjk15TmpFMw==
Cache-Control: no-cache
Windows users only: If git does not create the symbolic link on your Windows computer it is required to copy the file contents to the team folders:

cp variables.tf terraform.tfvars admin
cp variables.tf terraform.tfvars network
cp variables.tf terraform.tfvars shared
cp variables.tf terraform.tfvars application1





 A Note about becoming a team member 

It is possible to populate each team's access group with users. But rather than creating users, this tutorial will create a service ID in each team's access group. You are the administrator and will become a member of the different access groups by using the api key for the service ID for the team. The service ID names are ${basename}-x where x is network, shared, application1 and application2. Later you will populate a local.env file in each team's directory with contents similar to this:

export TF_VAR_ibmcloud_api_key=0thisIsNotARealKeyALX0vkLNSUFC7rMLEWYpVtyZaS9

In each step when you cd into a team directory you will be reminded to execute: source local.env

Terraform will be used to create the resources. Open admin/main.tf and notice the provider ibm clause and the reference to the ibmcloud_api_key initialized from the environment variable:

provider ibm {
ibmcloud_api_key = var.ibmcloud_api_key initialized with the TF_VAR_ibmcloud_api_key
}

If you need to use the ibmcloud cli as a team member:

ibmcloud login --apikey $TF_VAR_ibmcloud_api_key







 Step 2: Create the IAM-enabled resources (Admin Team) 

The admin team will need to have Admin access to the IAM-enabled resources in the account used in this tutorial. See [How do I assign a user full access as an account administrator?]
Adding tags to a snapshot from the CLI 

You can add tags to a snapshot from the CLI.

Specify a snapshot-update command with the --tags option to add user tags to a volume.

Use the same option to add tags to a volume when you create a snapshot by using ibmcloud is snapshot-create.

The following example adds user tags env:test and env:prod to a volume that is identified by its ID.

cloudshell:$ ibmcloud is snapshot-update r138-e6664842-b370-496a-9ae7-da3fb647707c --name snappy-snap-snap --tags env:test,env:prod
Updating snapshot r138-e6664842-b370-496a-9ae7-da3fb647707c under account Test Account as user test.user@ibm.com...

ID r138-e6664842-b370-496a-9ae7-da3fb647707c
Name snappy-snap-snap
CRN crn:v1:bluemix:public:is:eu-de:a/a10d63fa66daffc9b9b5286ce1533080::snapshot:r138-e6664842-b370-496a-9ae7-da3fb647707c
Status stable
Clones Zone Available Created
eu-de-3 true 2023-02-17T20:28:53+00:00
eu-de-1 true 2023-02-17T18:53:57+00:00

Source volume ID Name
r010-df8ffd90-f2e5-470b-83d7-76e64995a1aa vicky-block-test1

Bootable false
Encryption provider_managed
Encryption key -
Minimum capacity(GB) 20
Size(GB) 1
Resource group ID Name
As an IBM Log Analysis service administrator, you must have permissions to run the following actions:



* Grant other account members access to work with the service
* Provision a service instance
* Delete a service instance
* View details of a service instance
* Create a service ID



Therefore, to grant a user administrator role to manage instances within a resource group in the account, the user must have an IAM policy for the IBM Log Analysis service with the platform role Administrator within the context of the resource group.

Complete the following steps to assign a user administrator role to the IBM Log Analysis service within the context of a resource group:



1. From the menu bar, click Manage > Access (IAM), and then select Users.
2. From the row for the user that you want to assign access, select the Actions menu, and then click Assign access.
3. Select Assign access within a resource group.
4. Select a resource group.
5. If the user does not have a role that is already granted for the selected resource group, choose a role for the Assign access to a resource group field.

Depending on the role that you select, the user can view the resource group on their dashboard, edit the resource group name, or manage user access to the group.

You can select No access, if you want the user to have access only to the IBM Log Analysis service in the resource group.
6. Select IBM Log Analysis.
7. Select the platform role Administrator.
8. Click Assign.







 Granting permissions to a DevOps user to manage the service in the IBM Cloud account 

As a DevOps user, you must have permissions to run the following actions:



* Provision a service instance
* Delete a service instance
* View details of a service instance
* Create a service ID



Therefore, you need to have an IAM policy for the IBM Log Analysis service with the platform role Editor.

Complete the following steps to assign a user editor role to the IBM Log Analysis service in the account:



1. From the menu bar, click Manage > Access (IAM), and then select Users.
2.
Review [roles and permissions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-access) to learn how IBM Cloud IAM roles map to Hyper Protect Crypto Services actions.

To assign access to a key ring with the console, complete the following steps:



1. From the menu bar, click Manage > Access (IAM), and select Users to browse the existing users in your account.
2. Select the user that you want to assign access to in the table, and click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/icons/action-menu-icon.svg)to open a list of options for that user.
3. From the options menu, click Assign access.
4. Click Access policy.
5. Under Service, select Hyper Protect Crypto Services and click Next.
6. Under Resources, select Specific resources.
7. Select the Service Instance ID attribute type and enter the ID of the instance where the key ring resides.
8. Click Add a condition, select the Key Ring ID attribute to enter the ID associated with the key ring, and click Next.
9. Under Roles and actions, choose a combination of [platform and service access roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessroles) to assign access for the user and click Next.
10. (Optional) Under Conditions (optional), click Review to check the access policy.
11. After confirmation, click Add > Assign.

You must assign the user must at least Reader access to the entire instance in order for them to list, create, and delete key rings within the instance.







 Listing key rings 

You can browse the key rings that are managed in your provisioned instance of Hyper Protect Crypto Services with the console or the key management KPI.



 Listing key rings with the console
You can upgrade a user ID to a role with greater permissions, but you cannot downgrade a user with an Admin or Project Manager role to the Human Annotator role.









 Lesson 2: Creating a workspace 

In this lesson, you will learn how to create a workspace within Knowledge Studio.



 About this task 

A workspace defines all the resources that are required to create a machine learning model, including training documents, the type system, dictionaries, and annotations that are added by human annotators. For more information about workspace creation, see [Creating a workspace](https://cloud.ibm.com/docs/watson-knowledge-studio-data?topic=watson-knowledge-studio-data-create-project).





 Procedure 



1. {: hide-dashboard} As a Knowledge Studio administrator, from your IBM Cloud [resources](https://cloud.ibm.com/resources) page, click the Knowledge Studio service instance under Services.
2. Click Launch tool from the Manage page.
3. Click Create Workspace.
4. Specify the details for the new workspace:



* In the Workspace name field, type My workspace.
* In the Workspace description field, type Watson Knowledge Studio tutorial workspace.
* In the Language of documents field, use the default value, English. The sample files you will be using for this tutorial are in English.



5. Click Create.







 Results 

The workspace is created and opens automatically.





 What to do next 

You can now start configuring the workspace resources, such as the type system.







 Lesson 3: Creating a type system 

In this lesson, you will learn how to upload and modify a type system within Knowledge Studio. You must create or upload a type system before you begin any annotation tasks.



 About this task 

For more information about type systems, see [Type systems](https://cloud.ibm.com/docs/watson-knowledge-studio-data?topic=watson-knowledge-studio-data-typesystemwks_typesystem).





 Procedure 



1.