vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Learn more](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iamservice).



For each access group, define a policy for each resource group that specifies the permissions granted to work with the resource group, the permissions to manage instances of the IBM Cloud Activity Tracker service in that resource group, and the permissions to run IBM Cloud Activity Tracker tasks.



Table 3. Roles per access group policy

 Access group Policy 

 Administrators Grant a policy for the resource group with resource group access administrator. Select the IBM Cloud Activity Tracker service, and select the platform role administrator, and the service role manager. 
 Managers Grant a policy for the resource group with platform role editor. Select the IBM Cloud Activity Tracker service, and select the platform role editor, and the service role manager. 
 Advanced service users Grant a policy for the resource group with platform role viewer. Select the IBM Cloud Activity Tracker service, and select the platform role viewer, and the service role standard member. 
 Users Grant a policy for the resource group with platform role viewer. Select the IBM Cloud Activity Tracker service, and select the platform role viewer, and the service role reader. 



Every user that requires permissions to work with the IBM Cloud Activity Tracker service in your account must be assigned a resource group policy that includes the permissions for the IBM Cloud Activity Tracker service.

You can assign a single policy to the access group instead of assigning the same access multiple times per individual user or service ID.

Add users and service IDs to an access group. Grant permissions to these users and service IDs through the access group.

For more information, see [Granting administration permissions to a user or service ID](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-iam_manage_events).







 Configure the account settings for authentication into your account 

Multi-factor authentication (MFA) adds an extra layer of security to your account by requiring all users to authenticate by using an additional authentication method beyond an ID and password. This is also commonly known as two-factor authentication (2FA).
Infrastructure credentials for user name <1234567_name@email.com> set for resource group <resource_group_name>.

Example output if credentials are not set to use a different account. In this case, the API key owner that you retrieved in the previous step has the infrastructure credentials that are used for the region and resource group.

FAILED
No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051)



2. [Get the CIDRs and IPs of the subnets that your worker nodes are attached to](https://cloud.ibm.com/docs/containers?topic=containers-firewalliam_cidr_ip).
3. Get the [control plane CIDRs of the region where your cluster is located](https://github.com/IBM-Cloud/kube-samples/tree/master/iam-firewall-ips).
4. Log in to the [IBM Cloud console](https://cloud.ibm.com/).
5. From the menu bar, click Manage > Access (IAM), and select Users.
6. Select the user that you found in step 1 from the list.
7. From the User details page, go to the IP address restrictions section.
8. Enter the subnet CIDRs and IPs, and the control plane CIDRs of the region where your cluster is located.
9. Click Apply.





 Getting your Kubernetes Service subnet IP addresses 

Follow the steps to obtain the correct subnet IP addresses to add to your IAM allowlist.



 Getting your subnet IP addresses in the console 



1. From the IBM Cloud console [resource list](https://cloud.ibm.com/resources), click on your cluster.
2. Click Worker nodes.
3. Note each Public VLAN used by the worker nodes in your cluster. Multiple worker nodes may use the same public VLAN.
4. From the [IBM Cloud console](https://cloud.ibm.com/) menu !
2. From the Dashboard, select Manage > Access (IAM), and then select Users.
3. Select Service IDs.
4. Look for a service ID that has the following name: auto-generated-serviceId-<ID that is part of the iam_apikey_name value>.
5. Select the service ID. Then, in Access policies, click Writer.
6. In the Resource type field enter bucket.
7. In the Resource ID field enter the name of your bucket.
8. Click Save.



If you leave the Resource Type or Resource fields blank, the policy that is created is an instance-level policy.





 Step 6. Select the endpoint 

An endpoint defines where to look for a bucket. There are different endpoints depending on the region and type of resiliency. For more information, see [Select regions and endpoints](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints).

Complete the following steps to obtain the endpoint for your bucket:



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

After you log, the IBM Cloud Dashboard opens.
2. From the Dashboard, select the IBM Cloud Object Storage instance where you plan to create the bucket.
3. Select Buckets. Then, select the bucket that you created where you want to archive logs.
4. Select Configuration.
5. Copy one of the private endpoints.







 Step 7. Grant IAM policies to a user to archive logs 

The following table lists the policies that a user must have to configure archiving of logs from the IBM Log Analysis web UI into a bucket in an IBM Cloud Object Storage instance:



Table 2. IAM policies

 Service Role Permission granted 

 IBM Log Analysis Platform role: Viewer Allows the user to view the list of service instances in the Observability Logging dashboard. 
 IBM Log Analysis Service role: Manager Allows the user to launch the web UI and view logs in the web UI.
For example, you might have an application that is running on Kubernetes Service where the application needs to read and write from IBM Cloudant and read and write to a Cloud Object Storage Dedicated IBM Managed bucket. Both the IBM Cloudant and Cloud Object Storage Dedicated IBM Managed instances would be in the same resource group and the trusted profile would be assigned Reader or Writer roles.



Using trusted profiles is a best practice for applications running on IBM Cloud compute resources to gain access to IAM-enabled resources.







 Compare access groups and trusted profiles 

Access groups are best used for granting access for a user's day-to-day work, while trusted profiles are suited for granting federated users the level of access they need to complete a specialized and specific set of tasks within a limited time period. These are usually critical tasks that you would want to avoid doing unintentionally in daily work. With trusted profiles, federated users don't need to onboard to IBM Cloud, they are granted access to IBM Cloud resources in an account by way of the trust relationship. If a federated user leaves your company, you can simply delete their corporate identity in your directory, which then also removes access to IBM Cloud. Time-based access with trusted profiles allows frequent authentication checks for reduced security risks.

Use the following table to understand the differences between using access groups and trusted profiles to make the best decision for your use case.



Table 1. Compare access groups and trusted profiles

 Access group Trusted profile 

 IAM access control Yes Yes 
 Inviting users to the IBM Cloud account required Yes No 
 Access can be defined before user is added to the account Yes, by using dynamic rules Yes 
 Federated users Yes Yes 
 Non-federated users Yes No 
 Service ID Yes No 
 Compute resource identities No Yes 
 User management is primarily done in IBM Cloud account Corporate user directory 



Access groups and trusted profiles can be used separately or hand-in-hand for user and access management, depending on your organization's needs.

For example, for the CustApp project, you might choose to create an IAM Admin trusted profile with the following policies:



* Administrator for access groups CustApp-Dev/Test/Prod. This way, the administrator can grant and revoke access to users by adding them to and removing them from access groups.
Managing users 

Access to IBM® Db2® on Cloud service instances for users in your account is controlled by [Identity and access management (IAM) on IBM Cloud](https://cloud.ibm.com/docs/Db2onCloud?topic=Db2onCloud-iam) and database access is provided by standard access controls provided by the database.

For more information about IAM, see [What is IBM Cloud Identity and Access Management?](https://cloud.ibm.com/docs/account?topic=account-iamoverview).



 User types 



 Database users 

These are the users that are used to access the database. Traditionally, these are the OS users in a typical Db2 deployment, although, in the cloud, a user registry is used. Db2 understands these users as native to the database. The database privileges for the users can be granted or revoked as can roles that are created by the user.

Database users are not granted any service-level functions. For example, a database administrator who has access to the data does not have the ability to change the configuration of the system outside of the database privileges that they were given.





 IAM users 

IAM is only integrated with high-level service access, which governs privileges and operations available in the Db2 on Cloud console and database. Access to the database by these IAM users is provided by allowing an IAM user or service ID access to a specific Db2 user, as mentioned earlier.







 Roles and access 

Users can use JDBC or any Db2 client to connect to their database. There are two ways that users can access the database:



* Use their database user name and password associated with their account
* Use the IAM token (or APIKey, which gets the token) that is mapped to the associated database user



IAM authentication is performed as the authentication mechanism. Permissions are not controlled by IAM. Permissions are controlled by database level privileges of the associated user.



 Console access 

Console access is controlled by IAM. An IAM user can be assigned access by the IAM interface to all Db2 service instances, all Db2 service instances in a resource group, or a specific service instance.
To get this ID from the command line, run ibmcloud account show.

curl -L -X POST 'https://iam.cloud.ibm.com/v1/profiles' -H 'Accept: application/json' -H 'Authorization: Bearer <access_token>' -H 'Content-Type: application/json' --data-raw '{
"name": "<profile_name>",
"description": "<description>",
"account_id": "<account_id>"
}'



2. Link the IAM trusted profile to a Kubernetes namespace in your IBM Cloud Kubernetes Service cluster.



1. Get your <profile-id> from the output of the first step. Or, you can run the following API command.

curl -L -X GET 'https://iam.cloud.ibm.com/v1/profiles/?account_id=<account_id>' -H 'Accept: application/json' -H 'Authorization: <access_token>' -H 'Content-Type: application/json'
2. Get your cluster name and CRN by running the following API command.

curl --location --request GET 'https://containers.cloud.ibm.com/global/v1/clusters' --header 'Authorization: <access_token>'
3. Link the IAM trusted profile to your cluster.



* For <link_name>, enter a name for the link between the trusted profile and the cluster.
* Replace <profile-id>, <access_token>, <cluster_crn>, and <cluster_name> with the values that you previously retrieved.
* For <ns>, enter the namespace in your cluster. You can list namespaces by logging in to the cluster and running kubectl get ns. The Kubernetes namespace that you enter does not have to exist already. Any future namespace with this name can establish trust.
You can run the command ibmcloud iam access-groups to get the list of names and corresponding GUIDs in the account.

And use the following JSON file.

{
"type": "access",
"subjects": [
{
"attributes":
{
"name": "access_group_id",
"value": "AccessGroupGuid"
}
]
}
],
"roles" : [
{
"role_id" : "crn:v1:bluemix:public:iam::::serviceRole:Reader"
}
],
"resources": [
{
"attributes":
{
"name": "accountId",
"value": "accountGuid"
},
{
"name": "serviceName",
"value": "logdnaat"
},
{
"name": "serviceInstance",
"value": "instanceGuid"
},
{
"name": "logGroup",
"value": "group1"
}
]
}
]
}
Show more





 Add permissions through the UI 

Complete the following steps to assign a policy to an access group through the UI:



1. From the menu bar, click Manage > Access (IAM), and select Access Groups.
2. Select the name of the group that you want to assign access to.
3. Click Access policies > Assign access > Assign access to resources.
4. Select IAM services.
5. In the section What type of access do you want to assign?, select IBM Log Analysis.
6. In the section Which services do you want to assign access to?, complete the following steps:



1. Select Services based on attributes to refine the scope of the policy. Choose 1 of the following options:

Option 1: Set the scope to 1 instance in a resource group.
It is the only user that is initially granted access to all the settings and configuration that is found in the Admin tab in the management UI.





 Service Credential Users 

Users that you [create through the Service Credentials panel](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-connection-stringsfrom-_service-credentials_) are given full permissions to configure, write, and read on the default Virtual Host.

They are also automatically tagged with the "monitoring" tag, allowing users to access the management plug-in and see all connections, channels, and node-related information. These users given a limited view of the Admin tab and the functions that are found there.

If you need users that are created from Service Credentials to have more privileges, you can log in with the admin user and grant them.





 CLI and the API Users 

Users that you create through the Cloud Databases API and the CloudDatabases CLI are given the same permissions as Service Credential users. They have full permissions on the default Virtual Host and are tagged with the "monitoring" tag. If you need them to have more privileges, you can grant them while logged in with the admin user.

Users that are created directly from the API and CLI do not appear in Service Credentials, but you can [add them](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-connection-stringsadding-users-to-_service-credentials_) if you choose.





 RabbitMQ Users 

You can bypass creating users in Service Credentials and create users directly in RabbitMQ. The RabbitMQ Management plug-in UI has a tab for user creation and management available to the admin user on your deployment.

Users who are created directly in RabbitMQ do not appear in Service Credentials, but you can [add them there](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-connection-stringsadding-users-to-_service-credentials_) if you choose.
Bare Metal Server is.bare-metal-server.disk.update Disk on a bare metal server was updated 
 Bare Metal Server is.bare-metal-server.initialization.read Bare metal server's initialization data was retrieved 
 Bare Metal Server is.bare-metal-server.network-interface.read One or more network interfaces on a bare metal server was retrieved 
 Bare Metal Server is.bare-metal-server.network-interface.create Network interface was created on a bare metal server 
 Bare Metal Server is.bare-metal-server.network-interface.update Network interface on a bare metal server was updated 
 Bare Metal Server is.bare-metal-server.network-interface.delete Network interface on a bare metal server was deleted 
 Bare Metal Server is.bare-metal-server.network-interface-floating-ip.read One or more floating IPs associated with a network interface was retrieved 
 Bare Metal Server is.bare-metal-server.network-interface-floating-ip.attach Floating IP was associated with a network interface 
 Bare Metal Server is.bare-metal-server.network-interface-floating-ip.detach Floating IP was disassociated from a network interface 
 Bare Metal Server is.bare-metal-server.bare-metal-server-profile.read One or more bare metal server profiles was retrieved 







 Key events 



Table 16. Actions that generate events for Key

 Resource Action Description 

 key is.key.key.create Key was created 
 key is.key.key.delete Key was deleted 
 key is.key.key.update Key was updated 
 key is.key.key.read One or more keys was retrieved 







 Dedicated host events 



Table 17. Actions that generate events for Dedicated Host

 Resource Action Description 

 dedicated-host is.dedicated-host.dedicated-host.create Dedicated host was created 
 dedicated-host is.dedicated-host.dedicated-host.update Dedicated host or host disk was updated 
 dedicated-host is.dedicated-host.dedicated-host.delete Dedicated host was deleted 
 dedicated-host is.dedicated-host.dedicated-host.read One or more dedicated hosts or host disks were retrieved 







 Dedicated host group events 



Table 18. Actions that generate events for Dedicated Host Group

 Resource Action Description
Provisioning an IBM Analytics Engine serverless instance 

You can create a serverless IBM Analytics Engine service instance:



* [Using the IBM Cloud console](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-provisioning-serverlessconsole-provisioning)
* [Using the IBM Cloud command-line interface](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-provisioning-serverlesscli-provisioning)
* [Using the Resource Controller REST API](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-provisioning-serverlessrest-api-provisioning)



Note that you are not able to define certain limitation and quota settings while provisioning a serverless instance. These values are predefined. See [Limits and quotas for Analytics Engine instances](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-limits) for a list of these settings and their values.

You must have access to either the IBM Cloud® us-south (Dallas) or the eu-de (Frankurt) region.



 Creating a service instance from the IBM Cloud console 

You can create an instance using the IBM Cloud console. To understand the concepts behind provisioning settings in the UI, see [Architecture and concepts in serverless instances](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-serverless-architecture-concepts).

To create an IBM Analytics Engine instance:



1. Log into the [IBM Cloud® console](https://cloud.ibm.com/catalog).
2. Click Sevices and select the category Analytics.
3. Search for Analytics Engine and then click on the tile to open the service instance creation page.
4. Choose the location in which you want the service instance to be deployed. Currently, us-south and eu-de are the only supported regions.
5. Select a plan. Currently, Standard Serverless for Apache Spark is the only supported serverless plan.
6.
See this document on how to [use resource reclamation](https://cloud.ibm.com/docs/account?topic=account-resource-reclamation).





 Related content 



* [Serverless Computing](https://www.ibm.com/cloud/learn/serverless)
* [Serverless: Code patterns](https://developer.ibm.com/depmodels/serverless/patterns/)
* [Getting started with IBM Cloud Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started)
Getting started tutorial 

IBM Analytics Engine Serverless instance is allocated to compute and memory resources on demand when Spark workloads are deployed. When an application is not in running state, no computing resources are allocated to the IBM Analytics Engine instance. Pricing is based on the actual amount of resources consumed by the instance, billed on a per second basis.



* [Serverless instance architecture and concepts](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-serverless-architecture-concepts)
* [Provisioning a serverless instance](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-provisioning-serverless)





 Getting started using serverless IBM Analytics Engine instances 

The IBM Analytics Engine Standard Serverless plan for Apache Spark offers the ability to spin up IBM Analytics Engine serverless instances within seconds, customize them with library packages of your choice, and run your Spark workloads.

Currently, you can create IBM Analytics Engine serverless instances only in the US South region.





 Before you begin 

To start running Spark applications in IBM Analytics Engine, you need:



* An IBM Cloud® account.
* Instance home storage in IBM Cloud Object Storage that is referenced from the IBM Analytics Engine instance. This storage is used to store Spark History events, which are created by your applications and any custom library sets, which need to be made available to your Spark applications.
* An IBM Analytics Engine serverless instance.







 Provision an instance and create a cluster 

To provision an IBM Analytics Engine instance:



1. Get a basic understanding of the architecture and key concepts. See [Serverless instance architecture and concepts](https://cloud.ibm.com/docs/analyticsengine?-serverless-architecture-concepts).
2. [Provision a serverless instance](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-provisioning-serverless)







 Run applications 

To run Spark applications in a serverless IBM Analytics Engine instance:



1. Optionally, give users access to the provisioned instance to enable collaboration.
FAQs 



 What is IBM Analytics Engine serverless? 

The IBM Analytics Engine Standard serverless plan for Apache Spark offers a new consumption model using Apache Spark. An Analytics Engine serverless instance does not consume any resources when no workloads are running. When you submit Spark applications, Spark clusters are created in seconds and are spun down as soon as the applications finish running. You can develop and deploy Spark SQL, data transformation, data science, or machine learning jobs using the Spark application API.





 What are the advantages of IBM Analytics Engine serverless instances? 

With IBM Analytics Engine serverless, compute and memory resources are allocated on demand when Spark workloads are deployed. When an application is not in running state, no computing resources are allocated to the IBM Analytics Engine serverless instance. Pricing is based on the actual amount of resources consumed by the instance, billed on a per second basis.





 Does the IBM Analytics Engine Standard serverless plan for Apache Spark support Hadoop? 

No, currently, the IBM Analytics Engine Standard serverless plan for Apache Spark only supports Apache Spark.





 Can I change the instance home storage of a serverless instance? 

No, you can't. After an instance home storage is associated with an IBM Analytics Engine serverless instance, it cannot be changed because instance home contains all instance relevant data, such as the Spark events and custom libraries. Changing instance home would result in the loss of the Spark history data and custom libraries.





 How is user management and access control managed in a serverless instance? 

User management and access control of an IBM Analytics Engine serverless instance and its APIs is done through IBM Cloud® Identity and Access Management (IAM). You use IAM access policies to invite users to collaborate on your instance and grant them the necessary privileges. See [Granting permissions to users](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-grant-permissions-serverless).





 How do I define the size of the cluster to run my Spark application? 

You can specify the size of the cluster either at the time the instance is created or when submitting Spark applications.